Anbindung Modbus / Nibe

[shadow18]

Also ich wäre zu allem bereit hehe

[WegiMa]

Hallo Thorsten,

ich besitze eine Nibe 1145 die ich gerne in meine Hausautomatisierung integrieren möchte. Zur Steuerung und Visualisierung verwende ich IP Symcon auf einem 24/7 PC.

Ich würde mich freuen, wenn Du mir das entschlüsselte Protokoll und eine Empfehlung für die benötigte Hardware zum Auslesen der Daten zukommen lassen könntest.

Mittels IP Symcon würde ich dann ein Script (php) schreiben, das die Daten auswertet und visualisiert.

Vielen Dank bereits im Voraus.

MfG
WegiMa

[ctr]

Um das alte Thema hier mal aufzugreifen und auch meine eigenen Rechercheergebnisse zu dokumentieren:

Es gibt Nibe Wärmepumpen die als Zubehör *direkt* eine RCU (RCU10/11/20) unterstützen (z.B. F1120, F1130, F1135, F1140, F1220, F1230, F1235, F1240, F1250, F1320, F1330) dabei handelt es sich um ein Gateway zu Ethernet/GSM/Modem welchen Modbus über RS-485 mit der Nibe spricht, kostet aber ordentlich und kann eigentlich nichts. In dem Fall ist die Nibe (genauer: die Steuerkarte) Modbus Master und man kann folglich nur Modbus Slaves anschließen. Die Parameter dafür betragen: 19200,9,N,1
Abgegriffen werden kann Modbus per RJ45 entweder auf der CPU-Karte oder Communication Board, jedenfalls wo halt ein freier Sockel ist.
Belegung:

1 - D- 
2 - D+ 
3 - +12V 
4 - +12V 
5 - +5V 
6 - +5V 
7 - GND 
8 - GND

Hier gibt es einen Thread für ein Windowsprogramm in der Entwicklung welches wohl derzeit nur zum Loggen genutzt werden kann:
Nibe Fighter 1240 - HaustechnikDialog (so ab Seite 20 glaube ich)

Dann gibt es noch Nibe Wärmepumpen, die *keinen direkten* Anschluß einer RCU erlauben (z.B. F1345/F1245/F1145/F750/F470/F370), für diese gibt es ein Modbus Modul "Modbus 40" welches "irgendwie" (anscheinend auch RS485, aber wohl kein Modbus) an die Anlage angeschlossen wird. Anschließend fällt hinten Modbus raus, wobei der Modbus 40 dann Slave ist und man einen Modbus-Master braucht. Die Parameter dafür betragen:9600,8,N,1
Ohne "Modbus 40" kann das Signal i.d.R. auf der CPU Karte an einem Header abgegriffen werden, hier gibt es kein RJ45.
EDIT: Hier:
NibeHeatPumpBinding - openhab - Documentation of the Nibe Heatpump binding Bundle - empowering the smart home - Google Project Hosting
hat sich mal jemand daran versucht, bis jetzt read-only (nur register lesen, keine schreiben)

Und dann gibt es da leider noch die Nibe Split (*sigh* die habe ich) die weder RCU noch Modbus-Modul unterstützt und laut Nibe gar nichts kann.
Nach intensiver Recherche, vermute ich jedoch, dass diese weitestgehend baugleich mit der Fighter 1250 ist (außer Wasser/Luft vs. Wasser/Sole) und ich werde mal mein Glück mit Modbus versuchen... Ergebnisse dann in ein paar Wochen/Monaten/Jahren hier ;-)


EDIT: Das wichtigste fast vergessen:
Die Register sind für bestimmte Anlagen sehr gut dokumentiert:
http://www.nibe.se/Pages/42625/RCU_P...F1135_1235.pdf
http://www.varmepumpsforum.com/vpfor...0;attach=15720
http://www.nibe.se/Pages/42625/Exemp...r-Modbus40.pdf

[ctr]

Nach etwas mehr Forschung hab ich herausgefunden, dass einiges von dem was ich oben geschriebe habe falsch es. Anscheinend benutzt Nibe bei allen o.g. Geräten zwischen der eigentlichen Wärmepumpe und den Kommunikationsmodulen (RCU/ModBus40) ein proprietäres Protokoll. Modbus kann mann mit der Anlage wohl tatsächlich nur über ein RCU/Modbus Gerät sprechen, dann aber ModBus over TCP.

Der Bus, der zwischen WP und Kommunikationsmodul läuft, ist aber auch RS485 (dazu passen auch die Kommunikationsparameter 19200), allerdings hat Nibe sich hier wohl einen "Trick" einfallen lassen:
Das Paritätsbit wird benutzt um neue Frames zu markieren, d.h. man kann weder mit Parity Even/Odd arbeiten, sondern muß eigentlich "space" (Parität=0) setzen nur um dann beim Anfang eines neuen Frames die Geräteadresse (2bytes) mit Parity "mark" (Parität=1) zu ergänzen. Das ist ziemlich strange...

"Lesen" kann ich aber auf diesem Bus schonmal, ich sehe die Ausgaben des Displays (zB in regelmäßigen Abständen "Brauchwassertemperatur xx,x", die Uhrzeit usw). Zum Schreiben muß man hier wohl ziemlich low-level einsteigen, vor allen weiß ich nicht, wie ich bei Antworten das Hintergrundrauschen (d.h. was so zwischen CPU und Displaykarte ausgetauscht wird) von der eigentlichen Antwort unterscheiden soll...

[eddso]

Hallo,
ctr hast du paar mehr Informationen über deinen Test. Ich habe die gleiche WP und möchte diese auch auslesen. Wie du schon sagtest bietet NIBE nichts dazu an. Hast du den Bus zwischen CPU Platine und Anzeige abgehört? Welche Informationen kontest du auslesen nur die welche im Display angezeigt werden oder andere auch?

[ctr]

Ich habe hier einen Riesendatenwust den ich mangels Registerbeschreibung nicht annähernd vollständig zuordnen kann. Insgesamt wird man nie mehr bekommen als im Display angezeigt wird (allerdings gibt das Display im "Expertenmodus" eigentlich auch alles her).

Ich habe ca. 10 Register die sich einfach nachvollziehen lassen zuordnen können (diverse Temperaturen wie Außen, Vorlauf, Nachlauf etc) und kann diese Werte dann auch auf den KNX schreiben, aber alles bis jetzt Nibe-seitig alles nur lesend. Durch die lustige Mark/Space-Parity habe ich mich noch nicht getraut in Richtung Nibe zu schreiben.

Bisherige Versuche sind in C mit libftdi. Ist etwas komfortabler als termio und erlaubt zumindestens in der Theorie auch ausgefallene Parity Settings.

[eddso]

habe endlich Zeit gefunden mich an den internen Bus der Heizung zu hängen. Das lesen habe ich testweise unter Linux einfach mit cat </dev/ttyS0 gemacht. meine Einstellungen der seriellen Schnittstelle habe ich auf 19200 8N1 gestellt. Bekomme irgendwelche Daten die ich aber nicht interpretieren kann. ctr könntest du mir bitte mehr Infos geben mit welcher Schnittstellen Parametern du arbeitest, wie konntest du in den Daten was bekanntes sehen? im Klartext?

[ctr]

Klartext ist da leider gar nichts, 19200 ist schonmal nicht schlecht, aber wie gesagt mit Parity "mark" (nicht none).
Interessant ist erstmal sich das ganze in Hex anzugucken und dann nach wiederkehrenden Mustern zu schauen, da erkennt man oft schon oft Baudrate und auch Polarität stimmen (bei RS485 bekommt man auch bei vertauschter Polarität Daten, nur eben invertiert...)
Als nächstes versucht man die Frames zu erkennen, in die diversen Foren (leider hauptsächlich in schwedisch) ist das gut beschrieben.
Ich gucke nach den 0x51 - 0x55 als Startmuster (und anschließend mehr als 6 bytes), alles was darüber hinaus geht braucht dann schon etwas mehr Know-how über die Register. Da die Heizperiode jetzt vorbei ist, werde ich auch mal etwas experimentieren und meine "nibegw" Sourcen mal irgendwo hochladen...

[eddso]

Danke dir für deine Infos. Dein Source würde mich auch sehr interessieren. Momentan habe ich noch kleines Problem: beim lesen von dem Bus der Heizung resetet scheinbar die Steuerung, nach dem lesen steht im Display immer die Auswahl der Sprache. Scheinbar sende ich noch was ohne es zu wissen, oder es koppelt sich was ein.

[ctr]

Welche NIBE hast Du denn? Meine Forschungen sind ausschließlich für die Split gültig, für die anderen gelten andere Spielregeln.
Bei mir zeigt er bei konfigurierten aber nicht verbundenen RS485 immer einen Komm-Error, aber man auch einstellen (Experten-Menü), dass er trotzdem normal weiter macht, "hakt" nur etwas wenn man durchs Menü geht...

[eddso]

Ja ich habe auch die SPLIT. Angeschlossen habe ich mich an den freien RJ45 auf dem Display Modul. 2 meter Netzwerkkabel aus der Heizung und RS458 Transciever am Ende. Habe bis jetzt 2 ausprobiert 232 zu 485 und USB zu 485. Beide stören den Bus so dass das Display einfriert, belasten den wohl zu stark oder haben Busabschlusswiderstände integriert. Bin dabei es einzugrenzen, viele variablen zum testen: kabellänge, abschluswiderstände, abgrifspunkt ändern, anderen Transciever.

[ctr]

Ich habe den hier im Einsatz:
Modul USB 2.0 zu 2 x Seriell RS-232/422/485; EX-1333VIS, Art-Nr: 0198
Ich dokumentiere die Tage nochmal meine Verkabelung, das musste ich gegenüber der Doku im Schweden-Forum noch einmal drehen...

[HauCom]

Raspberry Pi

Würde auch mit RaspiComm Modul gehen, oder?
Da ich keinen PC in der Nähe habe, würde ich es lieber über Netzwerk loggen, etc..
Habe auch die Nibe Split 12

[ctr]

Wäre ich eher skeptisch, dort steht der RS485 wird "über eine API" verfügbar gemacht. Ob das dann auch funktioniert kann nicht nicht sagen.

In meiner Implementation bin ich übrigens von termios auf libftdi umgestiegen (was dementsprechend auch nur mit FTDI chips funktioniert), da ich nur dort 9M1 setzen konnte (CMSPAR hat bei mir nicht funktioniert)

[eddso]

Mit Raspi wird es auch gehen und nicht nur bei der SPLIT sondern auch bei F360P / F1135 / F1150 / F1235 / F1250 / ACVM 270 / VVM 300 / SMO 10, kurz gesagt an allen Heizungen wo man den RE 10 anschließen kann. Leider kann nur wirklich das ausgelesen werden was gerade im Display angezeigt wird. Damit mehr Daten gelesen werden können muss man auch Befehle senden. Und da bin ich noch nicht weiter.

Unter Linux (Raspi) kann man das lesen kurz testen mit:

stty -F /dev/ttyUSB0 19200 cs8 parenb -parmrk clocal -crtscts -cstopb -ixon -ixoff
cat < /dev/ttyUSB0

In der Ausgabe (Anhang) erkennt man nach min 3 sek was im Display angezeigt wird.

Über den Protokoll habe ich paar Tage gegrübelt. Folgend meine Interpretation der Daten:


Blau: Scheint die Adresse einer Komponente zu sein. F9 ist dabei das Bedienpanel und 05 wohl das Masterboard. Weiter gibt es noch F1 Und F5 entsprechen den zwei weiteren Boards in der Heizung.
Rot: Ist wohl ein Token der weitere anweisungen ankündigt.
Hellblau: Scheint die Registeradresse zu sein. Beim Display sind das 4 Zeilen jeweils mit der Adresse 0x50-0x53 (P,Q,R,S)
Grau: In den Antworten steht da immer die Slave Adresse drin.
Grün: Ist die Länge der folgenden Nachricht.
Violet: Ist die Nachricht selbst.
Gelb: Ist eine CRC die mit XOR gebaut wird und zwar über alle Bytes angefangen mit der Registeradresse (Hellblau).
Mit den 06 03 00 konnte ich noch nichts Anfangen, Frameanfang?

Es sieht so aus als ob der Master die Slaves permanent abfragt, das Bedienpanel zB mit 06 03 00 F9. Diese nachricht Trifft man sehr oft an. Beim Drücken einer Taste kommt nach der Abfrage sofort eine Antwort mit 05 06 ....

Meine Idee ist es einen RE10 zu simulieren. Dan kann ich die Heizung komplett bedienen/auslesen. Ich habe leider so ein Teil nicht um die Kommunikation mitzuloggen habe aber es im Menü mal Testweise aktiviert. Auf dem Bus sah ich Abfragen mit der Adresse FA. Logisch gesehen das zweite Display nach F9 ist FA.

Freue mich über Ergänzungen oder Berichtigungen.

@crt: Wie weit bist du mit schreiben ? Ich lese jetzt immer mit 8M1 kann nicht 9N1 um zu sehen ob das Parity sich ändert. Nach meinen Daten zu urteilen bleibt Parity stabil auf 1 (Mark).