Mein Forum
Registrieren
Neu hier?
Baukonstruktionen
Fertighaus
Fenster
Dämmung
Dichtheit
Passivhaus
Schimmel
Energieausweis
Heizung
Pellets
Erdwärme
Warmwasser
Stromsparen
Solaranlagen
Photovoltaik
Lüftungsanlagen
Energiespartipps
Berechnungen
|
|
||
|
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 |
||
|
||
|
That's also a reason why it's recommended to use not only a pi |
||
|
||
|
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 |
||
|
||
|
Also könnte man jetzt bedarfsorientiert je nach offenen Heizkreisen oder Verteiler den Volumenstrom verstellen 💪 |
||
|
||
|
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 |
||
|
||
|
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. |
||
|
||
|
heatpump.js does not handle those type correctly. I have fixed this in 1.1. 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. 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. |
||
|
||
|
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. |
||
|
||
|
Hi, 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 I use your image that starts mosquitto on the same Pi and connects to it. Does this count as external? Nice! This would be great. I know. Remember, usually I'm living in the C and Assembler (!) world... but I can adapt to everything. It just needs time. 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). 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? 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 |
||
|
||
|
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 |
||
|
||
|
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> 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). 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 |
||
|
||
|
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. |
||
|
||
|
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 already an approach like this one? 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: 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 |
||
|
||
|
Hi again, 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 ) 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 Greetings, Jan |
||
|
||
|
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. |
||
|
||
|
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. |
||
|
||
|
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. 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 |
||
|
||
|
No, the code for Arduino and the C code for Pi are linked here: https://www.openhab.org/addons/bindings/nibeheatpump/ |
||
|
||
|
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 |
||
|
||
|
Hallo, nur mal ein kleiner Zwischenbericht für die Interessierten am Projekt (ohne neue technische Details): Ich habe jetzt eine Echtzeit-AZ-Anzeige 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 |
||
|
||
|
Live-AZ fetzt Wie erfasst du eigentlich den Pumpenstrom? Halte uns am Laufen! Vg Maik |
Beitrag schreiben oder Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]