DIY Alternative zu Nibe Modbus Modul

Question

« Heizung, Lüftung, Klima |

▾ Forenübersicht
Hausbau-, Sanierung Bauplan & Grundriss Fenster & Türen Elektrotechnik & Smarthome Heizung, Lüftung, Klima Bad & Sanitärtechnik Innenausbau & Einrichtung Küche & Küchengeräte Fertighaus Baurecht Photovoltaik / PV E-Auto Finanzierung Pflanzen- & Garten Forum für Sonstiges Offtopic Ich suche...Ich biete...

DIY Alternative zu Nibe Modbus Modul

#nibepi

Zusammenfassung anzeigen (Beta)

< 1 2 ... 3 ... 9 10 11 12 ... 13 ... 49 50 51 >

Weil es hier immer wieder zu Diskussionen zum Thema Modbus-Anbindung der Nibe kommt, wollte ich hier mal kurz meine Erfahrungen mit dem Nachbau einer DiY Lösung, auf Basis von im Netz vorhandener Infos, teilen. Für mich war es eine Spielerei und Zeitvertreib der letzten Tage. Der Post dient vor allem als Speicherort für meine gesammelten Infos und evt. dem Austausch von Leuten, die das so oder so ähnlich bei sich installiert haben. Ich kann und will hier keine Empfehlung abgeben, sowas selbst zu machen!

Die Lösung basiert im Wesentlichen auf den Nibe Bindings von openHAB (https://www.openhab.org/addons/bindings/nibeheatpump/), das eine Umsetzung Modbus auf UDP macht. Infos zur Funktionsweise findet man auf der openHAB Seite bzw. dem entsprechenden github Repo.

Die grobe Vorgangsweise war folgend:
1) Auf einen Arduino mit Ethernet Shield und RS485 Adapter die NibeGW Software (Teil des Bindings) installieren. Der Ardunio Code muss dabei an die eigenen Netzwerkeinstellungen angepasst werden.

2) Den Arduino an die Wärmepumpe und ans LAN anschließen.

3) Die Nibe Modbus Manager Software auf einem Rechner installieren und bis zu 20 Register auswählen, die periodisch von der Wärmepumpe exportiert werden sollen. Diese Konfig muss gespeichert und per USB-Stick auf die WP WP [Wärmepumpe] übertragen werden.

4) Das Modbus Modul in der WP WP [Wärmepumpe] aktivieren. Wenn alles geklappt hat, bleibt die Wärmepumpe im Normalbetrieb. Falls irgendwas bei der Kommunikation mit dem Arduino schief geht, wird eine Fehlermeldung am Display ausgegeben und die WP WP [Wärmepumpe] geht in einen Alarmmodus.

5) Das nibeopenhab Binding in openHAB installieren und konfigurieren.

zu 1) Man könnte dazu auch einen Raspberry Pi mit RS485 Adapter verwenden, auf dem dann auch openHAB selbst läuft. Das finde ich aber nicht optimal. Ein Pi wäre mir da nicht robust genug. Selbst ein einfacher Neustart des Pis würde zu einem Fehler der WP WP [Wärmepumpe] führen und ein SD-Kartenfehler wäre sowieso ungemütlich.

zu 5) Da ich derzeit noch nicht weiß ob es openHAB oder was anderes wird - über Erfahrungen bzw. Empfehlungen würde ich mich freuen(!) - habe ich das Binding so adaptiert, das es ohne openHAB läuft. Derzeit verwende ich die Log-Dateien dieses "Stand-Alone Bindings" zur Speicherung der Werte. Eine Erweiterung für "richtige" Ausgabeformate bzw. Kanäle (Umsetzung auf KNX wurde hier mal in einem anderen Thread diskutiert) wäre aber von hier weg leicht machbar.

von energiesparhaus

chrismo

5.12.2019 (#208)

chrismo

8.12.2019 (#212)

< 1 2 ... 3 ... 9 10 11 12 ... 13 ... 49 50 51 >

Beitrag schreiben oder Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]

score 1 · Answer 1 · 2019-12-04T15:29:00Z

..
JanRi schrieb: With respect to your "too short" messages: Can you check if the affected messages are always "longer" messages (containing 5c5c)? For the examples you posted that is true but I guess you have much more. If yes, the problem seems to be related to that.

The affected messages were always 81 bytes long and included 5c5c. I found the problem yesterday.
Line 107 in backend.js
    let index = data.findIndex(index => index == 92);
    if(index!=-1) {
        data = data.slice(index, data.length);
        fs_start = true;
    }

I should have blocked this with if(fs_start===false)... If a new 5C is found then it will slice all the data before that and then concat the buffers. Thats why I'm getting shorts.

I rebuilded the backend to handle the buffer directly (instead of converting it to array)
And added the if(fs_start===false).
Now I have 0 errors during the last 18 hours.

I believe the problems of NibePi are solved :D
I'm gonna run some more testing but it looks really promising now.

Could'nt have done this without your help JanRi and the others who contributed.

Now NibePi handles all the communication with the pump directly and holds all the registers for every pump in the F series and automatically discovers them.

When all the communication troubles now hopefully are solved I can move on to make the NodeRED nodes complete.

score 1 · Answer 2 · 2019-12-04T19:01:00Z

Hi,

..
nibepi schrieb: Now I have 0 errors during the last 18 hours.

Great! That's how it should be.

..
nibepi schrieb: I'm gonna run some more testing but it looks really promising now.

Yes, thats looks good. The remaining question then is what happens in case of higher CPU load. If this leads to only one missed ACK from time to time I guess it will not raise an alarm. I have not yet figured out how many missed ACKs are still okay but appr. one second with no ACK seems to be no problem (stop nibegw, compile, start).

Btw... in my 100000 logged messages so far there was no double 5c5c, i.e., message length 82 (or 8 in case of type 106). Theoretically, this should be possible but very rare.

Greetings,

Jan

score 1 · Answer 3 · 2019-12-04T23:04:00Z

..
JanRi schrieb: Yes, thats looks good. The remaining question then is what happens in case of higher CPU load. If this leads to only one missed ACK from time to time I guess it will not raise an alarm. I have not yet figured out how many missed ACKs are still okay but appr. one second with no ACK seems to be no problem (stop nibegw, compile, start).

I have done some CPU stress testing and I see no errors.

..
JanRi schrieb: Btw... in my 100000 logged messages so far there was no double 5c5c, i.e., message length 82 (or 8 in case of type 106). Theoretically, this should be possible but very rare.

Yes I agree, NibePi should handle them well since it loops through the whole buffer.

score 1 · Answer 4 · 2019-12-05T08:24:00Z

Hi,

I got something very strange... my client side alarmcounter increased to 1 at night. It gets always increased if the previous value of register 45001 (part of favorites) was 0 and the current value != 0 (if it is 0xfb then error is reset - this is modbus error). However, there was no alarm at the heat pump, no alarm or info message in uplink, no error output from nibegw and, most curious, no message in the UDP log that contained a 45001 value that differed from zero.

I have to investigate that further but I'm afraid that was just some strange "glitch" at node.js side (running on server with ECC memory, so even this is out). If there are findings that are of interest beyond by setup, I will tell it here.

..
nibepi schrieb: I have done some CPU stress testing and I see no errors.

What type of stress test? I recommend running a multi threaded load that consumes a lot of CPU time as a worst case scenario to figure out the limits are. Example:

openssl speed -multi X

It needs some time to finish so its a good test. X is the number of threads. On your single core, I would go up to 8 or 10 or until problems occur. I'm quite sure that there will be problems once the load becomes too high but this would also apply to nibegw if run on a core that it shares with others.

So the goal should be to figure out how much load leads to some problems but no alarms and how much load leads to alarms. This is especially interesting to see how much workload can be put on the NodeReds in case of a single core Pi. If it runs perfectly with X=3...4 I would not expect problems for the purpose of NibePi. And, if there will be one error per month or so, this does not matter.

Greetings,

Jan

score 1 · Answer 5 · 2019-12-05T08:52:00Z

..
JanRi schrieb: What type of stress test? I recommend running a multi threaded load that consumes a lot of CPU time as a worst case scenario to figure out the limits are. Example:

openssl speed -multi X

It needs some time to finish so its a good test. X is the number of threads. On your single core, I would go up to 8 or 10 or until problems occur. I'm quite sure that there will be problems once the load becomes too high but this would also apply to nibegw if run on a core that it shares with others.

So the goal should be to figure out how much load leads to some problems but no alarms and how much load leads to alarms. This is especially interesting to see how much workload can be put on the NodeReds in case of a single core Pi. If it runs perfectly with X=3...4 I would not expect problems for the purpose of NibePi. And, if there will be one error per month or so, this does not matter.

This test.
https://core-electronics.com.au/tutorials/stress-testing-your-raspberry-pi.html
Probably not an accurate test, there were no issues, then I tested with creating an endless loop from NodeRED to my worker (index.js), I let it run for a couple of minutes and there no errors, even when the load was in my worker.

Now I'm running your test, seems like a good choice! How long does it run?

score 1 · Answer 6 · 2019-12-05T09:21:00Z

Hi,

..
nibepi schrieb: This test.

This put maximal thermal stress at the cpu. However, it does that with just one thread per core so at the useal 100...1000 Hz scheduler frequency that should be no problem. In our case, we do not want to stress the hardware but the os scheduler with many fully loaded threads.

..
nibepi schrieb: Now I'm running your test, seems like a good choice! How long does it run?

Basically, this is the speed test of openssl testing several crypto algorithms. It depends on CPU speed but it might run for several hours on a Pi. This is not necessary here! I would test this for each number of threads (so X=1...10) for appr. three to five minutes (Ctrl-C stops it). If there is a problem with scheduling, it will occur in this time. In order to save time, start with X=10. If this runs perfect for 5 minutes, smaller X (less threads) will also run (so there is no need to test that). If not, redude X until it runs stable.

I have not tested this for nibegw as my quad core Pi easily can reserve one core for nibegw - in this case the load on the other cores (more or less) does not matter. Obviously, this solution does not work on a single core Pi Zero.

openssl speed does not stress the IO subsystem but this is no issue here as you do not plan to stress that. Your SD is read-only so writing large amounts of data is out of scope and beside MQTT and some HTTP you do not do heavy network IO.

Greetings,

Jan

score 1 · Answer 7 · 2019-12-05T11:50:00Z

..
JanRi schrieb: Basically, this is the speed test of openssl testing several crypto algorithms. It depends on CPU speed but it might run for several hours on a Pi. This is not necessary here! I would test this for each number of threads (so X=1...10) for appr. three to five minutes (Ctrl-C stops it). If there is a problem with scheduling, it will occur in this time. In order to save time, start with X=10. If this runs perfect for 5 minutes, smaller X (less threads) will also run (so there is no need to test that). If not, redude X until it runs stable.

I am done testing. The test completes at 15 threads. Anything above the whole raspberry crashes.
During the test there are no errors and the modbus alarm never comes.
It was s good test and I'm very happy with the results.
Im also gonna try nibegw at 15 threads.

score 1 · Answer 8 · 2019-12-05T12:54:00Z

..
JanRi schrieb: In our case, we do not want to stress the hardware but the os scheduler with many fully loaded threads.

..
JanRi schrieb: on a single core Pi Zero.

@janri What about the preemptive real time Kernel Patches (Preempt-RT)? I guess they could bei useful to make the system more robust agsinst too high latencies caused by high system load.

score 1 · Answer 9 · 2019-12-05T13:22:00Z

The test with 15 threads was also succeded with nibegw.
I dont believe there are any timing issues running nibegw or nibepi on a raspberry pi which is being used for other causes.

score 1 · Answer 10 · 2019-12-05T20:42:00Z

Hi,

although I'm still think that there is the remote possibility of timing issues, I agree that this will not affect operation. Even if you miss two or three ACKs, this will not lead to an alarm (you stop and restart nibegw without alarm, even recompile inbetween).

Our usual 80 byte message is 87 byte long. At 9600 baud 8N1 this is 870 bit, appr. 90 ms. This is a lot of time for such a processor, even at high load.

I'm pretty sure that we CAN produce problems by writing very large files to very slow USB or SD devices. But thats not our intention so we can ignore that.

..
nibepi schrieb: Anything above the whole raspberry crashes.

This is most likely due to the fact that you run out of memory. You do not have swap and the Zero has not that much RAM. I guess that you might come a little bit further with nibegw as this requires less RAM that node.js.

..
chrismo schrieb: What about the preemptive real time Kernel Patches (Preempt-RT)? I guess they could bei useful to make the system more robust agsinst too high latencies caused by high system load.

It can help but also have issues. As I already told before, we had such a problem at work for a Pi-based demonstrator. Here, load and timing requirements were much, much harder. At the end, we could only make it stable enough (for demonstration purpose, not production use) by putting the controller isolated on one of the four cores of our Pi 3B (so significantly more CPU power than my Pi2 and miles ahead of a Pi Zero) AND had to use the Preempt-RT-patches. Here, the "other load" consisted of a full blown GUI and some other stuff.

Greetings,

Jan

score 1 · Answer 11 · 2019-12-08T11:30:00Z

Hallo zusammen,
ich werde demnächst versuchen meine 1255 mithilfe von SPS Wago 750-8212 aufzuschalten. Hat schon jemand es versucht oder plant so was zukünftig durchzuführen? Ein Programmcode für Standart-Modbus Kommunikation ist vorhanden, muss jetzt für Nibe Protokol angepasst werden. Danach können die Daten von WP WP [Wärmepumpe] weiterleiten bzw. speichern. (Cloud/KNX/Modbus-TCP/FTP/SD-CARD/ LON usw.)

score 1 · Answer 12 · 2019-12-08T11:41:00Z

Nein, eine SPS-Implementierung kenne ich nicht. Ist halt die Frage ob sich der Aufwand überhaupt auszahlt, nachdem andere Lösungen schon mehr oder weniger fertig verfügbar sind.

score 1 · Answer 13 · 2019-12-08T11:52:00Z

Hi,

"direkt anschliessen" halte ich für extrem aufwendig. Die Pakete müssen alle einzeln bestätigt werden. Das ganze ist zwar RS485, aber das Protokoll darauf ist ein Nibe-Eigengewächs. Du musst das also komplett von vorne bauen. Mit Modbus hat das nur insofern was zu tun, dass Modbus auch über RS485 geht und es von Nibe für extrem viel Geld das Modbus 40 gibt, das ein Adapter zwischen diesem Protokoll und Modbus ist.

Wenn, dann geh den Nibegw + Arduino-Weg. Das spuckt dann UDP-Pakete aus, die du auch ignorieren kannst, ohne dass das zu Problemen führt (was direkt auf dem Nibe-RS485 nicht gilt). Die müsstest du dann auf was auch immer umsetzen, das ist aber ziemlich einfach, wenn man diesen Thread liest und sich die hier gezeigten bzw. diskutierten Codeschnipsel anschaut.

Meine Lösung aus NibeGW auf RPI2 und selbstgebauter UDP<->MQTT-Translator (auf Server) und Logging/Anzeigeclient per MQTT läuft seit Anfang der Woche ohne jedes Problem 24/7.

Aktuell wird gerade WW WW [Warmwasser] gemacht:

AT: 8.5 IT: 21.9 AT_48h: 5.5
VL: 46.7 RL RL [Rücklauf]: 27.5 exVL: 23.1 VLsoll: 23.2
Kond.VL: 46.4 Heissgas: 68.4 Sauggas: 6.9
SoleEin: 4.0 SoleAus: 0.6
BWoben: 44.2 BWunten: 43.8
WQ: 27 % WT: 8 % WT: 4.0 l/min
Kompr. 55.0 Hz Relais: 15 Starts: 187
-345.2 GM
Spreizung: 19.2 P_th: 5359 W
P_ko: 876.2 W P_pu: 28.4 P_el 904.6 AZ: 5.924
EZ Kompressor: 2330.4 KWh EZ Pumpen: 392.7 KWh
WMZ Heizung: 13471.3 KWh WMZ WW WW [Warmwasser]: 662.4 KWh WMZ Kuehl: 0.0 KWh
Betriebsstunden: 5650 Betriebsstunden WW WW [Warmwasser]: 232
Alarmzaehler: 0 Alarm: 0 Nachrichten: 106534

Die Echtzeit-AZ stimmt bei WW WW [Warmwasser] nicht, weil der Durchflussmesser hier zuviel anzeigt. Real dürften es um 4000W und eine AZ um 4 sein.

Viele Grüße,

Jan

score 1 · Answer 14 · 2019-12-08T12:35:00Z

Hi,
die SPS Implementierung ist sehr ähnlich wie C oder C++ (alles irgendwie von C abgeleitet). Den vorhandenen Code für (Arduno/RPI) schaffe ich schon irgendwann auf ST anzupassen. Ist nur mit Zeitaufwand verbunden. Wago ist schon verbaut und steuert alles im Haus (KNX / Dali/ Modbus Raumbediengeräte), deswegen möchte ich direkt nutzen. Eine weitere SPS für Testen ohne Haus immer dunkel zu machen ist auch vorhanden. )) Ich berichte wenn es geklappt hat. Weinachten habe ich mehr Zeit dafür.
Gruß Niko

score 1 · Answer 15 · 2019-12-08T14:04:00Z

Wenn ich es richtig verstanden habe setzt die 1.1 auf node red
Von node red aus kannst du problemlos modbus tcp oder auch auf den KNX Bus schreiben und hast auch gleich ein tolles Werkzeug um allerhand iot geraffel anzubinden

Vielleicht gibt's auch direkt eine Integration, evtl. hilfreich das Wago für node red sogar einen Kurs anbietet
https://www.wago.com/de/events/seminar/iot-mit-e-cockpit-docker-node-red

score 1 · Answer 16 · 2019-12-08T14:15:00Z

Hi,

NibePi 1.1 wird auf NodeRed setzen - fertig ist das noch nicht, da baut der Entwickler noch dran. NibePi 1.1 braucht aber zwingend einen RPi, solange niemand ein UDP-Interface einbaut (dann könnte es auch auf irgendeinem Node.js-fähigen Server laufen und seine Daten via nibegw von einem Arduino oder RPi bekommen).

Wenn du da was für die Wago bastelst, würde ich über UDP gehen. Das würde dann einen Arduino + Kleinkram für ca. 20 Euro an der WP WP [Wärmepumpe] bedeuten (da läuft dann nibegw) und das bläst die Daten dann per UDP raus. Das wiederum müsstest du dann mit der Wago decodieren.

Ich denke nicht, dass das viel schwerer als der Weg über NodeRed ist... aber das kommt dann vor allem auf deine Programmiervorlieben an.

Oder du suchst einen Weg, über MQTT auf die Wago zu gehen.

Viele Grüße,

Jan

score 2 · Answer 17 · 2019-12-08T14:32:00Z

..
JanRi schrieb: NibePi 1.1 braucht aber zwingend einen RPi,

NibePi 1.1 funktioniert unter allen Linux-Betriebssystemen mit RS232-RS485. Wenn es fertig ist ...

1

score 1 · Answer 18 · 2019-12-08T17:31:00Z

Wago 8202 hätt ich auch zum Spass verbaut für Alarm, KWL, VSR, Heizungs, Pool, Energiemanagement usw Steuerung verbaut.
Mit RS485 Klemmen usw...
Wenn du was lauffähiges für E.Cockpit hättest, wäre ich interessiert :)...
Ansonsten obs aufn Linux BSP auf der SPS lauffähig is, ist fraglich.. wenn nicht Linuxserver oder Nas oder Rpi..
Udp Variante mit Node Red wäre auch interssanr

score 1 · Answer 19 · 2019-12-27T08:55:00Z

Found my old Raspberry B + and a cheap adapter too, but that should work?

Maybe you can already say something about the status of V1.1, I'm curious :)

score 2 · Answer 20 · 2019-12-27T09:12:00Z

Hi,

..
Klartext schrieb: but that should work?

It should work after changing the serial port from /dev/ttyAMA0 to /dev/ttyUSB0.

..
Klartext schrieb: Maybe you can already say something about the status of V1.1, I'm curious :)

There was nothing from the author after the last post but I guess he is busy finishing 1.1.

In the meantime, you can try your hardware with the old version or with nibegw and a small UDP server.

My code (UDP<->MQTT) is not "production ready", it is more a prove of concept that still has unfinished features, but it runs rock stable since appr. four weeks.

Since it gives less functionality than nibepi, I do not plan to publish it (yet) but I can imagine to give it somebody to continue development.

Greetings,

Jan

1

score 1 · Answer 21 · 2019-12-27T09:46:00Z

Danke gut zu hören, ich bau die Hardware jezt erst mal ein und schau dann weiter