Anbindung Modbus / Nibe

[ctr]

brauchst meises wissens nur die .json ergänzen

Woher nimmst Du diese Erkenntnis? Die Schnittstellen werden mit komplett unterschiedlichen Port-Settings und Befehlen angesteuert.

[zinnik]

Hallo

Echt schade das da Nibe auch nichts anbietet wenn schon Schnittstellenvorhanden sind.
Ist man denn schon weitergekommen mit der ACVM270 Wärmepumpe?
Kann man diese mittlerweile über openhab anbinden. Hab leider keinerlei Programmierkenntnisse um hier aktiv mitwirken zu können.

Lg zinnik

[funkymo]

https://partner.gira.de/service/down...type=D&id=4488

Hat damit jemand Erfahrung, wir haben die SMO S40 von NIBE verbaut...

Danke&Gruß

[timbba80]

Hello! Apologies writing in English! Thought to share over here in case someone is interested (and to give the credits to you guys for being able to make this happen!).

I've combined the information which has been available on this discussion for the older Nibe split heat pumps which do not have modbus, and which can collect data using logger function. Big thanks to eddso and ctr for their excellent work earlier on with the original python script and with collecting the register data etc.

Basis of that information I've utilized openai chatgpt for creating a python script which collects the data and utilizes mqtt for sending the data further on. Personally I have an old raspberry pi 1 dedicated for this purpose (as it has been unused for multiple years without no purpose).. It is now running Raspberry OS lite and connected to the heat pump with rs483-usb adapter. The python script is running in that system and sending the data via mqtt.

In case someone is interested, you can find the code from here: https://github.com/timbba80/nibe

[uzi10]

Hello! Apologies writing in English! Thought to share over here in case someone is interested (and to give the credits to you guys for being able to make this happen!).

I've combined the information which has been available on this discussion for the older Nibe split heat pumps which do not have modbus, and which can collect data using logger function. Big thanks to eddso and ctr for their excellent work earlier on with the original python script and with collecting the register data etc.

Basis of that information I've utilized openai chatgpt for creating a python script which collects the data and utilizes mqtt for sending the data further on. Personally I have an old raspberry pi 1 dedicated for this purpose (as it has been unused for multiple years without no purpose).. It is now running Raspberry OS lite and connected to the heat pump with rs483-usb adapter. The python script is running in that system and sending the data via mqtt.

In case someone is interested, you can find the code from here: https://github.com/timbba80/nibe

Which heat pump types are supported?

[timbba80]

Which heat pump types are supported?

I'm using it with Mitsubishi Hydrolution HMA100v, which basically is same device than Nibe ACVM270.

Technically I believe that any model with logger function will be compatible, but they most likely have different registers (https://github.com/ctr49/nibe-knx-gw/tree/master) and thus the initial handshake for connection might not work, and the register entries for sensors might vary.

[vitalic66]

Hallo,

das Thema ist zwar schon alt, aber da wir auch eine ACVM270 haben und diese etwas smarter werden soll, hole ich es wieder hoch. Hat es schon jemand geschafft, Daten an die Split zu senden?

Dank dem script von timbba80 und der Vorarbeit von ctr und eddso kann ich den Bus abhören und bekomme bereits Daten in den Homeassistant.

Bislang konnte ich die Tasten für (+ - Home Enter) ebenfalls mMn identifizieren:

Wenn man eine Taste drückt am Bedienfeld (F9) kommt eine Enquiry (05) welches Acknowledged (06) wird. Danach kommt die Taste selbst

40 00 F9 04 01 8a 03 ff CA -> +
40 00 F9 04 02 8a 03 ff C9 -> -
40 00 F9 04 04 8a 03 ff CF -> Enter
40 00 F9 04 20 8a 03 ff EB -> Home

Habt ihr eventuell weitere Erkenntnisse?

Edit, Uhrzeit und Datum werden so nach Änderung am Bedienfeld übergeben:

D0 00 59 07 25 02 09 16 10 00 01 A7

D0 00 59 | länge | Jahr | Monat | Tag | Stunde | Minute | Sekunde? | Ende (Müll?) | Checksum

Leider gelingt es mir nicht in die Bus hinein zu schreiben. Ich versuche es mit Docklight, aber egal ob es nach eine Sequenz sendet oder zufällig, keine Reaktion auf die Änderung der Uhrzeit oder Tastendruck zurück zum Hauptmenü z.B..

[ctr]

Ich habe noch nichts gesendet, dazu aber in https://knx-user-forum.de/forum/öffe...166#post519166 erwähnt, dass man ziemlich low-level mit der Parität "schummeln" muss. Hattest Du das schon implementiert?

[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.

[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]

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]

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]

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.

[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]

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