« Heizung, Lüftung, Klima  |

DIY Alternative zu Nibe Modbus Modul

Teilen: facebook    whatsapp    email
 
Zusammenfassung anzeigen (Beta)
 1  2 ... 3 ... 5  6  7  8 ... 9 ... 49  50  51 
  •  chrismo
  •   Gold-Award
29.1.2019 - 25.4.2024
1.009 Antworten | 62 Autoren 1009
127
1136
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 WPWP [Wärmepumpe] übertragen werden.

4) Das Modbus Modul in der WPWP [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 WPWP [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 WPWP [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

  •  JanRi
  •   Gold-Award
29.11.2019  (#121)
Hi,

GND is not connected as it is usually not needed by RS485.

However, during the night I experienced two modbus alarms. Nibepi automatically resets those, therefore it has no impact, but this should not happen.

Maybe GND is really an issue, but actually I see two other possible reasons:

First, Uplink was still connected. Now, I disconnected the network in order to find out if this was the reason.

Second, I still have an USB stick connected in logging mode. As the same LOG.SET applies both to USB log and modbus, there might be a connection. I will try removing the USB stick if Uplink was not the reason.

Greetings,

Jan

1
  •  SMiak
  •   Bronze-Award
29.11.2019  (#122)

zitat..
JanRi schrieb: However, during the night I experienced two modbus alarms. Nibepi automatically resets those, therefore it has no impact, but this should not happen.

That's also a reason why it's recommended to use not only a pi emoji


1
  •  JanRi
  •   Gold-Award
29.11.2019  (#123)
Hi,

Uplink was not the cause. Now USB stick is removed - lets see what happens now.

The Pi is running with readonly file system and executes only necessary software...

Greetings,

Jan

1
  •  uzi10
  •   Gold-Award
29.11.2019  (#124)
Also könnte man jetzt bedarfsorientiert je nach offenen Heizkreisen oder Verteiler den Volumenstrom verstellen 💪

1
  •  JanRi
  •   Gold-Award
29.11.2019  (#125)
Hi,

ja... könnte man. Dazu muss man aber noch einiges bedenken... dazu schreibe ich nachher noch was.

@NibePi: Even without USB stick I got alarms quite often. I started heatpump.js on the console in order to see the output (here the last two alarms):

Got alarm status. Resetting.
Sending data: 45171 : 1
Sending message: [ 192, 107, 6, 115, 176, 1, 0, 0, 0, 111 ]
Still resetting, attempt (1)
Alarm has been reset
Got alarm status. Resetting.
Sending data: 45171 : 1
Sending message: [ 192, 107, 6, 115, 176, 1, 0, 0, 0, 111 ]
Still resetting, attempt (1)
Still resetting, attempt (2)
Still resetting, attempt (3)
Still resetting, attempt (4)
Got alarm status. Resetting.
Sending data: 45171 : 1
Sending message: [ 192, 107, 6, 115, 176, 1, 0, 0, 0, 111 ]
Alarm has been reset

Unfortunately, this does not help with respect to the root cause. I even started node.js with nice level -15 in order to increase responsibility.

Do you see similar alarms at your system or the others in your forum? Just to estimate... here I expect something like 10-20 alarms per day. This is with just 20 favorite registers, no additional register (except 45001 polled by heatpump.js) and without Node Red - I just run heatpump.js and mosquitto.

While the alarms are not relevant with respect to functionality, I'm afraid that we will run into serious problems with durability of storage on the heatpump. If this is some kind of flash for the alarm log, we produce a large amount of write requests (every alarm logs some data and if we look at 20 years, we will have 75000-150000 alarms which might be far beyond the lifetime of the storage system on the heat pump).

Greetings,

Jan

1
  •  chrismo
  •   Gold-Award
29.11.2019  (#126)
What about investing another 5-10 Eur to buy an Arduino (clone) and a USB cable. Modbus communication can be handled (very reliably) by the Arduino, while the Pi can do the node.js stuff, logging, etc. The Arduino and the Pi can communicate using the USB serial connection. Would only need to slightly change the Nibe Binding for openHAB to use serial instead of UDP communication.

1
  •  nibepi
29.11.2019  (#127)

zitat..
JanRi schrieb: I ran into some problems with data types (esp. on s32 and u32) but I guess this is due to my non-existing JavaScript skills so I will solve that later.

 heatpump.js does not handle those type correctly. I have fixed this in 1.1.

zitat..
JanRi schrieb: However, there is one problem that seems to be related to NibePi: I have register 43514 (relay state in order to see if hot water is running) defined as part of my favorites. It is logged to USB (so LOG.SET worked) but it is not published by NibePi.

I got a workaround in heatpump.js to verify the data in the long buffer. For this workaround to work it cant get more than 19 registers. Maybe 43514 is your number 20?
In 1.1 I dont need that workaround because the communication is so much more stable.


zitat..
JanRi schrieb: @NibePi: Have I understood you correctly (Posting from 11/22 at 9:53) that requesting a single read of a register (not part of favorite) is not yet implemented but will come in 1.1? 

I think it's working with nibe/modbus/40033/get
It will publish the answer on nibe/modbus/40033
But I dont remember, this will be working in 1.1

Generally about the instable communication. heatpump.js does not handle the communication well. In the same script it executes every other function like, decoding, pub/sub mqtt. If you are using it with external mqtt broker it is probably a bug that makes the application run wild. If you only use the broker which connects automatically at startup its more stable.

But again 1.1 is a real fixer. The important communication with the heatpump is handled by one backend.js script which has full priority. Then a worker.js script runs all the decoding and pub/sub making the core solid.

I can share that with you in the coming week, it's a real game changer.
You can access the data with a simple request in nodejs script like.

reqData("40004", function(data) {
   console.log(data)
})

setData("43005", "-100", function(result) {
   if(result===true) console.log('Data written succesfully');
})

Remember, if you just started with NodeJS coding, everything is asynchronously. It's not like python. You need data callbacks. Like above.

And for all the others, it will just work with the mqtt pub/sub.

All stability issues will be resolved in 1.1.


1
  •  nibepi
29.11.2019  (#128)

zitat..
chrismo schrieb: What about investing another 5-10 Eur to buy an Arduino (clone) and a USB cable. Modbus communication can be handled (very reliably) by the Arduino, while the Pi can do the node.js stuff, logging, etc. The Arduino and the Pi can communicate using the USB serial connection. Would only need to slightly change the Nibe Binding for openHAB to use serial instead of UDP communication.

That's an option. But my nibepi executes important weather automations and other automations. I want the automation to run as close to the heatpump as possible so if there are problems we can revert all data to normal state. In 1.1 the communication will be stable on a Raspberry pi so no need for an extra hardware.

1
  •  JanRi
  •   Gold-Award
29.11.2019  (#129)
Hi,

zitat..
nibepi schrieb: I think it's working with nibe/modbus/40033/get
It will publish the answer on nibe/modbus/40033


Actually, not in 1.0.6. incomingMQTT does not deal with such messages. But this does not matter if it is fixed in 1.1

zitat..
nibepi schrieb: If you only use the broker which connects automatically at startup its more stable.


I use your image that starts mosquitto on the same Pi and connects to it. Does this count as external?

zitat..
nibepi schrieb: But again 1.1 is a real fixer.


Nice!

zitat..
nibepi schrieb: I can share that with you in the coming week, it's a real game changer.


This would be great.

zitat..
nibepi schrieb: Remember, if you just started with NodeJS coding, everything is asynchronously. It's not like python. You need data callbacks. Like above.


I know. Remember, usually I'm living in the C and Assembler (!) world... but I can adapt to everything. It just needs time.

zitat..
nibepi schrieb: And for all the others, it will just work with the mqtt pub/sub.


Actually, after playing with the mqtt pub/sub, I like it and will continue to use it as it offers a lot of great features.

Do you change the pub/sub interface (topics etc) in 1.1? If not, my dashboard/logger client should continue working because it just connects to the mosquitto broker running on the nibepi (with your image, I only disabled NodeRed).

zitat..
nibepi schrieb: For this workaround to work it cant get more than 19 registers. Maybe 43514 is your number 20?


In the list it is number 17. Number 20 is "alarm" which works. But: Maybe the heat pump sends them in different order (but subscriber gets exactly the order from LOG.set just without that single register).

With respect to alarm: According to my experiments and my understanding of the code, 1.0.6 handles alarm (45001) only if it is requested seperately. If it is contained in the favorites, it will be published but not analyzed in heatpump.js (which relys on the seperate reading so 45001 actually comes twice - as part of favorites and by the seperate read). After disabling the alarm mechanism at all (by moving it into my client which resets the alarm based on the favorites), it looks like heatpump.js runs more smoothly (with respect to publication rate). It is still unclear if this reduces alarms as I did it some minutes ago, but nevertheless... I guess this is no longer an issue with 1.1, right?

zitat..
chrismo schrieb: What about investing another 5-10 Eur to buy an Arduino (clone) and a USB cable. Modbus communication can be handled (very reliably) by the Arduino, while the Pi can do the node.js stuff, logging, etc.


I think this is a completely different approach. The nice thing with NibePi is that it can be considered a black box offering a real powerful pub/sub interface to the heat pump. 

If I would go the Arduino way, I would probably implement a very simple UDP interface in a way that the Modbus-Arduino just sends everything on UDP some and receives write commands also on UDP. If this is done using multicast, it would offer even some of the nice NibePi features.

But now... lets look forward to 1.1.

Greetings,

Jan



1
  •  JanRi
  •   Gold-Award
29.11.2019  (#130)
Hi,

just found another issue (that might not apply on the Pi zero): The Raspian image runs the RPi2 that I use using the "ondemand" cpufreq governor. This way, the CPU speed can jump between 600 and 900 MHz. This may lead to problems with predictability. 

Therefore, I just switched to performance:

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

(the same for cpu1..3 on a quad core Pi2)

Now we have stable 900 Mhz (I guess that even stable 600 MHz is better than jumping between the two)... lets see if this affects reliability of nibepi 1.0.6.

With respect to controlling values on the heat pump, I'm just wondering if we can really do that. My use case is controlling the pumps put your weather controller also changes configuration options on the heat pump. The question that I ask myself is the same as with the alarm log: Can we really change configuration values as often as we want? As these values change options in a way that it "survices" a power cycle of the heat pump, it must be saved in flash, EEPROM or battery-buffered RAM. Except the latter, these memories have limits on cycles. If I change, e.g., supply pump speed 50 times a day on 100 days in a year, we end up with 100000 changes in 20 years for one parameter. 

As we have some users here with good connections to Nibe, I will made this question a separate thread in the forum.

Greetings,

Jan

1
  •  chrismo
  •   Gold-Award
29.11.2019  (#131)

zitat..
JanRi schrieb: If I would go the Arduino way, I would probably implement a very simple UDP interface in a way that the Modbus-Arduino just sends everything on UDP some and receives write commands also on UDP. If this is done using multicast, it would offer even some of the nice NibePi features.


That is exactly what the Nibe openHAB binding is doing. But actually the communication technology is not the issue here but it is the reliability of the SW module that ACKs all the data to the Nibe. And my concern is that some JS script on a RPi is not stable, or predictable enough (no real-time) to handle the needed ACKs with 99.999...% reliability. And your issues with the CPU governor somehow prove this issue. So, keep all the pub/sub stuff, which apparently makes NibePi useful, but let an Arduino do the Modbus part. In the end the only difference would be that you read (already acked data) from /dev/USB0 instead of /dev/<whatever the modbus module's address is>

zitat..
nibepi schrieb: But my nibepi executes important weather automations and other automations. I want the automation to run as close to the heatpump as possible so if there are problems we can revert all data to normal state.

The Arduino is probably the most stable thing in the entire system. I dont know how many parallel processes are running on the Pi that could cause troubles for your automation scripts. But I can tell you the number for the Arduinio: there is exactly 1 ../images/em_wink.svg

As said above, using an Arduino would just make the read/write part more robust but does not change anything for the rest of the processing chain (pub/sub the data).

zitat..
JanRi schrieb: The question that I ask myself is the same as with the alarm log: Can we really change configuration values as often as we want?

That is a very valid point that should be considered carefully! You definitely don't want to break your heatpump because of some worn out flash memory chip. Buy a Tesla instead, if you want to face these kind of problems emoji

1
  •  nibepi
30.11.2019  (#132)

zitat..
chrismo schrieb: The Arduino is probably the most stable thing in the entire system. I dont know how many parallel processes are running on the Pi that could cause troubles for your automation scripts. But I can tell you the number for the Arduinio: there is exactly 1

 In 1.1 the core script which run the communication with the heatpump runs an own event loop and has dedicated access to the cpu. The application is not cpu intense so even if you overload the cpu there is still room for the script to run. 

Im sure the arduino is very stable to run. It only does one thing. The Pi can do that and a lot else in one system. Stable and secure. Decoding all the data and verify every register to the registerlist for all different heatpumps.

If the arduino losts contact with its other system all the value will be as they were when the communication was lost. Maybe the house will be too cold or hot when you realize the communication is down.

Jans problem with communication is because the old script does top much. The new scripts are devided for better access. 


1
  •  JanRi
  •   Gold-Award
30.11.2019  (#133)
Hi,

result of my nightly experiment with the old script:

After changing the governor to performance and hence the cpu speed to 900 Mhz and removing the perioding request of 45001 from heatpump.js, I got "only" 3 alarms in 12 hours. This is better than before... slightly at least, so predictability of the everything else on the Pi is definitely an issue.

Now, next idea: I added "isolcpus=2,3" to the kernel command line. This way, the linux kernel omits CPU 2 and 3 for all processes (except kernel processes). Then, I used taskset to move mosquitto to CPU2 and I manually started node heatpump.js with taskset to CPU3 and nice on level -20. Now, the JS program has (except kernel threads) a dedicated processor, the same applies to the MQTT broker.

Lets see whether this improves stability.

If yes, it might be also an option for 1.1 with the dedicated event loop (if we can figure out which of the many node.js processes is the right one). Or do you mean by

zitat..
nibepi schrieb: own event loop and has dedicated access to the cpu

already an approach like this one?


zitat..
nibepi schrieb: If the arduino losts contact with its other system all the value


I don't see this as a problem. If the arduino code is simple and reliable, we can consider it as part of the system we want to control. The remaining code (the Pi side) is then resonsible for keeping the communication up and running. Nevertheless, I see the arduiono solution as plan C if plan A (version 1.1 of nibepi) and plan B (a stripped down nibegw C-program on a dedicated core of a Pi) fail.
 
And:


zitat..
chrismo schrieb: You definitely don't want to break your heatpump because of some worn out flash memory chip.


This is acually my biggest problem. For logging and dashboard this does not matter once we reduce the problems of alarms to an acceptable minimum but as long as we have no clear answer (from Nibe) on that, I see writing to the heat pump as a configuration issue only (to change things remotely with no physical access to the heat pump) but NOT as an option for controlling whatever by writing to heat pump very often. Btw... the Tesla issue was the original inspiration of this question.

Greetings,

Jan


1
  •  JanRi
  •   Gold-Award
30.11.2019  (#134)
Hi again,

zitat..
nibepi schrieb: The application is not cpu intense so even if you overload the cpu there is still room for the script to run. 


It does not need much cpu time, but it needs some cpu time available in a rather short time frame in order to ack on time. On a heavy loaded CPU it might still get its small share of cpu time but the question is if this happens at the right moment or too late - a classical real time problem.

At work, we had a similar problem with a demonstration controller on a Pi 3. We improved the situation significantly (enough for the purpose of demonstration) by applying real time kernel patches, CPU isolation (see above) and some other minor tweaks with cpu affinity of the different parts of the application.

As our timing requirements are not that hard (the connection is running at 9600 bits/sec), I can image that your approach works as long as the load is not too high. CPU isolation could make that possible even on a heavy loaded multi-core Pi but the question is if we can figure out which thread of node.js corresponds to the critical event loop.

Regarding my experiment, I just reduced the number of threads on the Pi from 102 to 82 (still 81 more than on Chrismos Arduino emoji ) by stopping 12 services that are not necessary (three more would be possible with some investigation).

Another observation: Everything I did in the Pi (editing, starting/stopping services, even some more intensive tasks), NEVER produced an alarm although it puts much higher load on the Pi than the regular activities. Therefore, another option (besides some of the services doing whatever) would be some race condition in the 1.0.6 code... so lets hope for 1.1 emoji

Greetings,

Jan

1
  •  chrismo
  •   Gold-Award
30.11.2019  (#135)

zitat..
JanRi schrieb: I see the arduiono solution as plan C if plan A (version 1.1 of nibepi) and plan B (a stripped down nibegw C-program on a dedicated core of a Pi) fail.

I agree with that. If you can make the Pi (near) real-time capable than there is no need to add another component to the system. For option B you could start with the C-Version of nibeGW. Thus, efforts should be quite limited. 

1
  •  nibepi
30.11.2019  (#136)

zitat..
JanRi schrieb: Another observation: Everything I did in the Pi (editing, starting/stopping services, even some more intensive tasks), NEVER produced an alarm although it puts much higher load on the Pi than the regular activities. Therefore, another option (besides some of the services doing whatever) would be some race condition in the 1.0.6 code... so lets hope for 1.1

 The problem is the heatpump.js it does too much processing. My stripped down backend.js has no issues. 
The decodedata() is too heavy for example. 


1
  •  JanRi
  •   Gold-Award
30.11.2019  (#137)
Hi,

I just monitored something strange: Switching from heating to hot water produced two alarms. The same happened at first try but as an alarm stops hot water, I had first to adapt the alarm settings. Now, the start of hot water produced those two alarms and now everything runs smooth again.

In addition: My RS485 shield has to LEDs for RX and TX. Usually (with my version of heatpump.js that does not request any register and only reads the favorites) RX is on for a moment, then (much shorter) TX, then a break and then again RX. Thats obvious because the packet by the heat pump (RX from Pi perspective) is much larger than the ACK (TX). However, in the minutes after start of hot water this very regular pattern changed: It was no longer regular, sometimes there two interactions one after the other, then nothing and again. At the same time, the incoming data flow at my client was also kind of "jumpy". There were only two alarms but much more of these "jumpy" packets.

I have no idea how this is related to hot water production. Especially, now, few minutes later still producing hot water, everything is fine again.

Maybe a problem with electromagnetic interference with the hot water valve? My cable is appr. 1,5m long and the Pi sits just outside the heat pump. A, B and GND are conneced (I added GND yesterday). Maybe thats too long?

For the original modbus 40, the manual does not give a restriction in cable length. It is delivered with a wall mount so mounting it outside the heat pump seems to be okay. They recommend LiYY or EKKX or similar. I use KNX cable that should be "similar" and even has a shielding. Maybe I should connect the shield to GND? The recommended LiYY is usually NOT shielded and at 9600 Bit/s I do not expect problems.

zitat..
chrismo schrieb: For option B you could start with the C-Version of nibeGW.


I did not follow the development of nibeGW. Was there some forking of versions? If yes... what is the most promising and most developed version? (just do think about Plan B).

Plan A is still nibepi 1.1.

Greetings,

Jan

1
  •  chrismo
  •   Gold-Award
30.11.2019  (#138)

zitat..
JanRi schrieb: I did not follow the development of nibeGW. Was there some forking of versions?

No,  the code for Arduino and the C code for Pi are linked here: https://www.openhab.org/addons/bindings/nibeheatpump/

1
  •  JanRi
  •   Gold-Award
30.11.2019  (#139)
Hi,

thank you. This looks quite simple. If the problems with the alarms persit I will try nibegw (without any client, just to ACK the messages from heat pump) to figure out if my hardware works with this. If the hardware is the problem then nibepi 1.1 also has no chance.

Right now, the heat pump finished with hot water. This time, there was no alarm and alarm count is still at 2 (start of hot water).

Lets see how it runs the rest of the day...

Greetings,

Jan

1
  •  JanRi
  •   Gold-Award
30.11.2019  (#140)
Hallo,

nur mal ein kleiner Zwischenbericht für die Interessierten am Projekt (ohne neue technische Details):

Ich habe jetzt eine Echtzeit-AZ-Anzeige emoji

AT: 2.5 IT: 22.1
VL: 26.4 RL RL [Rücklauf]: 23.7 exVL: 26.3 VLsoll: 26.1
Kond.VL: 26.3 Heissgas: 47.1 Sauggas: 6.9
SoleEin: 4.4 SoleAus: 0.6
BWoben: 45.3 BWunten: 44.9
WQ: 7 % WT: 49 % WT: 14.8 l/min
Kompr. 38.9 Hz Relais: Starts:
-414.2 GM
Spreizung: 2.7 P_th: 2788 W
P_ko: 419.4 W P_pu: 29.8 P_el 449.3 AZ: 6.207

(dies ist die Ausgabe meines "Dashboard", sieht in Forenformatierung nicht so toll aus)

Stromwerte kommen inzwischen auch über MQTT, allerdings über einen anderen Broker wegen der Lastproblematik. Derzeit werden die Smartmeter nur einmal pro Minute ausgelesen, aber das kann ich problemlos noch steigern.

Viele Grüße,

Jan

1
  •  SMiak
  •   Bronze-Award
30.11.2019  (#141)
Live-AZ fetzt emoji

Wie erfasst du eigentlich den Pumpenstrom?

Halte uns am Laufen!

Vg Maik 

1


Beitrag schreiben oder Werbung ausblenden?
Einloggen

 Kostenlos registrieren [Mehr Infos]


next