Anbindung Modbus / Nibe

[vitalic66]

ctr kein Problem. Ich hab es nur nie geschafft aufzuräumen... Wollte mich aber auch nochmal dran setzen, um weiter an der direkten Manipulation zu arbeiten.

Vitalic66/nibe

acvm270_display.c liest die 4 Zeilen des Displaynachrichten aus
acvm270_keypress.c liest die aktuelle Stellung des Drehregler und wartet auf eine MQTT Nachricht, die dann wieder in den Bus eingeschleust wird, als ob man eine Taste vor Ort drückt
acvm270.py ist hier schon hinlänglich bekannt, um den logger zu simulieren

lordbauer hatte auch schon per PN gefragt. Vielleicht entwickelt sich ja nochmal was hieraus.

[ctr]

vitalic66 bist Du schon so weit, dass Du Deinen Code veröffentlichen würdest?
Ich würde gern nochmal etas mit der libftdi rumspielen. Die hatte ich damals mit Absicht genommen, weil man (recht schnell) die low-level parameter beeinflussen kann. Würde mich dann mit den von Dir gewonnen Erkenntnisse nochmal an einen Versuch wagen...

[ctr]

Wow, das sieht ja schon richtig aus, Glückwunsch zum Fortschritt!

[vitalic66]

Mittlerweile läuft mein virtuelles Display im Homeassistant...

Die Bedienknöpfe funktionieren nun alle via MQTT. Wenn ich in den Programmen aufgeräumt habe, werde ich das Projekt im Github veröffentlichen. Schön wäre halt noch die Werte direkt setzen zu können, statt am virtuellen Display einzustellen, aber es ist mehr als vorher.

Aktueller Haken, ich brauche einen Dongle um das Bedienfeld zu simulieren, einen Dongle um den Logger zu simulieren und einen RS485 HAT um per Bitbanging die Tasten zu simulieren.

grafik.png

Im zweiten Bild habe ich mal kurz alle möglichen Symbole eingeblendet:

grafik.png

Muss auch noch aufgehübscht werden:
grafik.png

[vitalic66]

Update.
Es ist mir gelungen, einen Tastendruck (Enter) zu simulieren. Heißt, ich kann mit meinem Programm "Enter" auslösen und im Display ändert sich die Anzeige.

Mittlerweile verstehe ich die Kommunikation immer besser.

Die Grundlagen stimmen, jedoch sind einige Annahmen falsch interpretiert.

06 - ACK - verstanden / bin noch da
05 - ENQ - ich habe etwas für dich
03 - ETX - Ende der Nachricht

Der Master sendet anfragen an die Slaves (00 F1, 00 F5, 00 F9).
Nun kommt es auf die Antwort des Slaves an.

06 - ich bin da
05 - ich habe etwas für dich (Master)

Je nach Rückmeldung vom Slave Antwortet der Master wieder.

Slave 06 -> Master 03 (ich habe nichts für dich (Slave))
Slave 06 -> Master "irgendeine Nachricht" -> Slave antwortet wieder mit 06 (Nachricht empfangen) -> Master 03 (Ende der Nachricht)

Slave 05 -> Master 06 (ich höre dir (Slave) zu) -> Slave sendet seine Nachricht -> Master 06 (habe es empfangen) -> Slave 03 (Ende der Nachricht)

Wenn der Slave etwas an den Master übertragen hat, muss die 03 vom Slave Space sein, nicht wie sonst Mark. Außerdem kommt danach erneut vom Master eine Anfrage an der Slave der gesendet hat. Diesmal antwortet der Slave aber direkt mit 06.

Mittleweile bin ich auf einen RS485 HAT umgestiegen und statt termios oder libftdi gehe ich mit der pigpio und Bitbanging in die Kommunikation. Es ist einfach wesentlich schneller, da mit dem USB Stack teilweise zu viel Zeit vorloren geht beim senden.

[vitalic66]

ctr welchen Adapter nutzt du für die Kommunikation? Ich verwende aktuell einen Waveshare RS232/485 zu USB Wandler.

Was mich die ganze Zeit schon wundert, Nachrichten die ich nur Mitlese sind invertiert zwischen A und B.

Sobald ich aber sende, sind A und B identisch, was nicht sein darf.

[vitalic66]

Ich habe nochmal alles geändert auf die erwähnte libftdi. So schaut es dann aus, wenn ich die Pumpengeschwindigkeit am Bedienfeld manuell ändere:
grafik.png
Und so sieht es nach Änderung mit meine libftdi Lösungsansatz aus:
760059_ftdi6.png

Die Paritäten sind also kein Problem. Es scheint als hat Nibe da noch ein paar tricks eingebaut, wozu man nun leider wirklich die technische Doku bräuchte. Leider hat Nibe abgelehnt etwas heraus zu geben. Vermutlich werden wir also außer Datum/Uhrzeit nie etwas ändern können.

Auch mein anderer Lösungsansatz das Bedienfeld Nachzubauen schlägt fehl, da auch Tasten die ich sende ignoriert werden.

[vitalic66]

Wie bereits erwähnt, die Uhrzeit und das Datum kann ich dadurch wunderbar ändern. Jedoch passiert rein garnichts bei anderen Nachrichten.

Die Pumpengeschwindigkeit zB wäre

00 F5 06 76 00 59 03 05 64(100%) crc 06 03. So kommt es auch an, mit richtigem Mark und Space, aber passieren tut nichts. DIe Tasten Bedienfeld lassen sich leider auch nicht simmulieren.

Was ich beobachtet habe, es werden teilweise Enquiry Nachrichten gezeigt. Ich habe diese im Docklight mit init bezeichnet.

grafik.png
grafik.png
D4 kommt fast immer bevor das Display mit Zeile 1 bis 4 (50 bis 53) erscheint und enthält auch wieder Datum und Uhrzeit. Wenn ich es richtig interpretiere, schein die 59 der Speicher/Cache/Ram oder was auch immer zu sein, was abgefragt wird und wo ggf durch ein ENQ rein geschrieben wird. Aber alles nur Mutmaßungen.

[vitalic66]

grafik.png
So sieht die Eingabe aus, zB zum ändern von Uhrzeit und Datum.
grafik.png
Das kommt dann im Bus an. CRC wird errechnet und angehangen (8A). Die 06 hinter 00 F9 und nach 8A kommen von der Nibe als Antwort. Erst mit 03 endet die Nachricht.

Gesendet wird 00 F9 mit Mark, D0 00 59 07 25 03 07 16 32 00 01 8A mit Space, und die 03 wieder mit Mark.

Im LogicAnalyzter kommt es dabei so an. wenn in Klammern error steht, heist es parität space, sieht man auch vor dem Stoppbit schön, das graue Quadrat.

grafik.png
grafik.png
grafik.png

[ctr]

Das Paritätsbit wird für den ersten Frame einer Nachricht (!) als Markierung für den Start einer neuer Nachricht verwendet. Wenn Du 8M1 benutzt, wirst Du damit keine Nachrichten durchbekommen, die größer als ein Byte sind (weil die ja auf mehrere Frames verteilt werden muss und in den Folgeframes muss die Parity 0 sein, sonst wird es als NEUE Nachricht interpretiert, nicht als Rest der vorherigen).
D.h. Du musst low-level auf dem seriellen Protokoll arbeiten und kannst nicht einfach eine Verbindung mit 8M1 aufbauen. Deswegen hatte ich in meinem Beispielcode gleich mit der libftdi angefangen, da kommt man so tief rein - über das character device nicht, da geht nur lesen (weil man lesend logisch aus dem Nachrichtenaufbau Anfang/Ende interpretieren kann anstatt über die Parität).

Alternativ könnte man evtl. auch die Nachricht erst in Frames aufteilen und dann in der Verbindung für Nachrichtenteile > 1 die Parität der Verbindung ändern. (ungetestet)

[vitalic66]

Mittlerweile habe ich tatsächlich ein Programm auf c basierend, wodurch ich zuverläßig die Uhrzeit ändern kann, leider jedoch noch nicht Dinge wie die Pumpengeschwindigkeit.

Die Uhrzeit wird mit D0 00 59 ... geändert, andere Einstellungen gehen laut Beobachtung über 76 00 59.... Die Nachricht wird auch richtig empfangen, auch mit den dafür notwendigen Paritäten, jedoch nicht verarbeitet. Irgendwas muss da noch anders laufen.

[vitalic66]

ctr

Ich habe mich etwas tiefer mit der materie der Paritsbits beschäftigt und dank LogicAnalyzer kann ich deine Aussage bestätigen.

Die Bytes 00, 03 und zb. A0,F1,F9,F5 (vermutlich angesprochener Slave bzw Funktion) müssen mit Mark (immer 1) versehen sein. Der Rest ist immer mit Space (0) versehen, unter anderem auch 06.

Ich habe bereits versucht in einem Pythoscript die Parität dynamschi zu änder und auch mit 2 RS485-USB Adapter zu sende. Einer ist dauerhaft Mark der andere Space.

Klappen tut das auch, jedoch dauert das umschalten zu lange, so dass die nachricht unvolständig übertragen wird und somit nicht durchläuft.

Evtl teste ich mal die Option über die GPIO vom pi zu gehen, da man dort wohl 9 Byte senden kann. Vielleicht gelingt es mir 9N1 einzustellen und irgendwie Bitweise zu übertragen.

[vitalic66]

Hier noch ein paar Erkenntisse zu den 55-messages:

BYTE 5
K 5 6 7 8 9 11 12
C2 1 1 0 0 0 0 1 0
82 1 0 0 0 0 0 1 0
E2 1 1 1 0 0 0 1 0
42 0 1 0 0 0 0 1 0
C0 1 1 0 0 0 0 0 0
C3 1 1 0 0 0 0 1 1
A2 1 0 1 0 0 0 1 0
AA 1 0 1 0 1 0 1 0
B2 1 0 1 1 0 0 1 0
DA 1 1 0 1 1 0 1 0
BA 1 0 1 1 1 0 1 0

K5 Mischventil

55 00 59 02 82 2A A6 -> K6 Heizventil aus (geschlossen)
55 00 59 02 C2 2A E6 -> K6 Heizventil an (offen)

55 00 59 02 E2 2A C6 -> K7 BW Ventil an (öffnen)
55 00 59 02 C2 2A E6 -> K7 BW Ventil aus (schließen)

BYTE 6
K 13 14 1 2 3 4
2A 0 0 1 0 1 0 1 0
22 0 0 1 0 0 0 1 0
2B 0 0 1 0 1 0 1 1
2E 0 0 1 0 1 1 1 0
28 0 0 1 0 1 0 0 0
0A 0 0 0 0 1 0 1 0
3A 0 0 1 1 1 0 1 0

55 00 59 02 C2 22 EE -> K1 Umwälzpumpe aus
55 00 59 02 C2 2A E6 -> K1 Umwälzpumpe an

55 00 59 02 C2 2E E2 -> K2 an
55 00 59 02 C2 2A E6 -> K2 aus

55 00 59 02 C2 28 E4 -> K3 an
55 00 59 02 C2 2A E6 -> K3 aus

55 00 59 02 C2 2B E7 -> K4 Mischventil an
55 00 59 02 C2 2A E6 -> K4 Mischventil aus

Es gibt noch andere Nachrichte, wo aus den bits eine Matrix zum Status gebildet werden kann.

Edit, mir zerhackt es immer die Formatierung...

[vitalic66]

Nur mal als Beispiel:
01.03.2025 18:34:04.721 [RX] - 00 F1 06 8C 00 59 02 04 80 53 06 03 BLOCK START 04
00 F1 06 A0 00 59 02 26 3E E3 06 03 A0-message
00 F9 06 03 display-check
00 F9 06 D0 00 59 07 25 02 28 09 28 00 01 A1 06 03 d0-message
00 F1 06 8B 00 59 14 80 10 D6 00 81 10 88 00 83 10 29 00 87 10 D6 00 11 00 00 00 73 06 03 8b-message

Ich nutze Docklight mit Lizenz, das macht es etwas einfacher zu decodieren.

Die d0-message ist wie oben bereits erwähnt Datum/Uhrzeit. Ich kann die Nachricht an der gewünschten Stelle schreiben, jedoch wird sie meistens ignoriert. Irgendwas muss noch erfüllt sein, damit sie akzeptiert wird. Was Parität, bzw allgemein die Kommunikation angeht, stehe ich noch ma Anfang der Lernkurve.

[vitalic66]

Mir gelingt es ab und zu mal die Uhrzeit zu ändern, allerdings ist das tatsächlich reiner zufall, ob es klappt oder nicht. Ich habe allerdings nur die Standard Parameter verwendet (8M1).

Ich verstehe aber mittlerweile immer mehr vom Protokoll und konnte noch so einiges entschlüsseln, bzw den ein oder anderen Fehler im bisherigen finden.

Ich weis halt nicht, ob es überhaupt noch jemand interessiert.