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
|
|
||
|
It's on facebook as a closed group. If you have facebook just search for NibePi. I have heard that burning an image to a SD card and putting it in a Rpi2/3 will work, but you need to modify the heatpump.js (/home/pi/.nibepi/heatpump.js) to work with the ttyUSB0 (Or whatever) instead of the standard port ttyAMA0. SSH credentials are pi / nibe. It should work without the GND since rs485 wont demand that. The user said it just worked after he changed the port. |
||
|
||
|
Unfortunally NibePi dosent start up as fast as the heatpump. Im still trying to trim down the startup time. But. the backend handles the alarm by asking every minute or so if there is a alarm 251. If it's it sends a reset on register 45171. And the alarm goes away. So the backend always resets the alarm. That's not the case of NibeGW. So it will be in alarm mode for about max a minute or so. Turning the modbus on and off is not neceserry. |
||
|
||
|
Hi, Good idea! This way, the only problem would be if the Pi for some reason does not boot at all. Here, your solution with read-only root file system on SD should improve the probability of a successful boot compared to the standard case of R/W (at work, we ran into several problems with SD cards on long running Pi). Yes, that was the idea. In order to improve performance here: Does it make sense to put the corresponding register into the list of 20 "favorite" registers (USB config file) that can be accessed faster? Greetings, Jan |
||
|
||
|
Hallo zusammen. Ich antworte jetzt mal für NibePi da seine maximale Anzahl an Beiträgen für heute aufgebraucht ist. (komische Spam Protection Naja...) Er hat mich gebeten zu antworten. (seine Antwort weiter zu geben) In the way the backend is programmed there would make no different because the backend wont decode the long buffer that holds the favorite registers. But. I can easily implement a startup reset. You can reset how many times you want. Even if there is no alarm. |
||
|
||
|
Hi, (an answer tomorrow is perfect... this is not urgent) According to the Modbus 40 documentation, reading a register that is not a favorite requires up to 2,1 seconds. Reading all 20 favorites together is only 0,5 seconds. Does that mean that you read all required registers (subscribed by the user) the slow way? My intention is to use NibePi (among other things such as controling hot water production and improving water pump control) as a replacement for USB logs (better: To implement a logger client that subscribes to the data published by NibePi). Therefore, it is important to have values that "fit together" with respect to age. The favorite registers seem to do that as the heat pump sends them twice a second to the modbus unit (or NibePi). Therefore, they reflect a "snapshot" of heat pump state (difference in age <0.5 seconds). If we read 20 registers one by one this takes 42 seconds. In order to log data every minute this is still enough but it is not a "snapshot" anymore because between the first and the last register read is a time difference of appr. 40 seconds. For my purpose, this might be a problem. Therefore, my plan for Modbus 40 (before I learned today that there is NibePi) was to configure the favorite registers in a way that they contain everything I want to log and to read this "long buffer" once a minute for logging purpose (or more often for control purpose during hot water production). If I understood you correctly, this is not possible with NibePi (or only in a way that one data set contains values with a difference in age of up to 40 seconds). Or did I misunderstood you? Greetings, Jan |
||
|
||
|
"He is right about the time delay to read a lot of registers, it takes 2,1 seconds to read one register. ( I just measured reading 40 registers ) NibePi however supports "Favorite registers" and will read them every 0,5 second and get them in a bunch and publish all of them at the same time on their respective registers, not in one big buffer. Then it's up to the application to just read them one time per minute. I guess nibepi works better than a regular modbus40 here. Can you even read multiple registers in one call on a modbus40?" |
||
|
||
|
Mmmh I'm also confused now. 😃 So NibePI (not the heatpump itself) does also have favorites right? (they differ from the 20 set via USB directly to the pump) They will be read in one call and also be returned in one call? And the favorites are not limited in size. I think I don't get it as well. 😂 And I got one more question. Does the Modbus answer contain the timestamp for the read value? It wouldn't matter how long the whole transfer process takes if the reading timestamp is sent along and gets pushed through MQTT as well. But I think it is quite important to be able to group all the readings for one point of time for logging purposes. Pretty difficult when there is no timestamp at all. Just relying on the point of time the mqtt client receives the message for the topic would not be enough. But I'm pretty sure I'm now misunderstanding how it works. I think you have to enlighten is even more about how the whole thing works correctly. |
||
|
||
|
Drawing the flow would help to understand the process. 😊 |
||
|
||
|
Sorry for the confusion. NibePi does not have it's own favorite register. I meant the usb log.set favorite register.  Here's an example of the NodeRED nodes that are coming. This is the request node, it request live data from the heatpump. And it takes 2,1 seconds per request node. But. If one of the registers is a part of the favorite registers, it will respond within 0,5 seconds. It will not make a "slow request" if the register is part of the favorites. In that 47011_raw section everything from the registerfile is included. It's a good idea with the timestamp. I will add a timestamp i that raw message. For example, the timestamp will be the same for the favorite registers , because I will set the timestamp when that long message arrives.  The Input node either adds the register you choose to the "Get regulary list" or gets the data from the favorite registers when data arrives every 0,5 second. I will add the timestamp. That's a very good idea.
|
||
|
||
|
Thank you for the explanation. So if I get that right a "request" node allows to request multiple registers. If all of the registers are not in the usb log set favorites, the whole request (for all of the registers) takes 2,1 seconds. If it is in the favorites it is 0,5s but only for the favorites. I try to understand the whole flow a bit better. 1) The "backend" node.js application just does the modbus communication with the heatpump 2) A second "worker" node.js application does the whole encoding/decoding modbus stuff, mqtt communication, node-red nodes 3) The communication method between "backend" and "worker" is unclear to me 4) Communication between "worker" and node-red is done by web sockets right? With the node-red nodes seen above. Does the "worker" application keep on sending the received stuff directly to MQTT? Or is it only "backend" -> "worker" -> node-red? For logging purposes it would be great to also have a single MQTT topic that would get published the 20 favorites including a timestamp by the worker. That would allow an external "logging" MQTT client (e.g. openhab or others) to write away the data to one data column that includes all the favorite values in one shot for a sinle point of time. That would keep such a logging service pretty simple. So you could choose between the whole favorites in one topic or different topics for each register. (the last is needed when using something like InfluxDB) |
||
|
||
|
Hi, I think I understood it now but I will repeat it in order to verify this: First, Modbus 40. As I got it from documentation and discussion on nibegw, the heat pump continouosly sends the favorites (up to twenty values) twice per second. This happens anyway, not depending on modbus request. Modbus 40 seems to buffer these values so if a modbus request will read 1-20 of these registers (according to doc, reading multiple registers seems to be possible for favorites) most likely not from the heat pump but from the internal buffer that is at most 0,5 seconds old. For all other requests, Modbus 40 issues a request to the heat pump and will get the answer within 2,1 sec. Second, NibePi in the way I understood it: As NibePi looks like Modbus 40 for the heat pump, mostly the same behavior applies: The heat pump will send all favorites twice a second without a request. NibePi will store that in some internal data structure that is updated with every new message, so data in this structure is at most 0,5 second old. Similar data structures exist for all other registers. If the user now request a register, we have two cases: First, if it is a favorite, the answer will contain the last value received and is at most 0,5 seconds old. Second, for all other registers NibePi will issue a request to the heat pump and will get the answer 2,1 seconds later and forward that to the user. So NibePi does NOT forward the periodic favorite data once it arrives but uses the local copy in order to realize fast answers. Therefore, in my understanding it behaves the same way as Modbus 40 (Modbus 40 also does not forward the periodic data directly) with the exception that the communication with the user is based on MQTT and not modbus on RS485. Furthermore, the user of NibePi can only request one register at a time requiring multiple requests for multiple registers (which I see not as a problem because the communication user<->NibePi using MQTT is probably much faster than the communication user<->Modbus 40). Is my understanding correct? Therefore, even without time stamps, if I request all 20 favorite registers one after the other from NibePi I will get a more or less consistent view. I guess 20 request + responds will not take more than a second (right?) so in worst case the difference in age is one period == 0,5 sec. Conclusion: For logging favorites, time stamps are nice but not necessary, for logging everything else, they are necessary to create a consistent view. Since I'm not really familiar with MQTT and have not yet looked at your sources, I have one more question: Regarding the communication between some user process (such as my logger) and NibePi - is this request/reply or publish/subscribe? Do I have to request data every time I want them or is it possible to subscribe in a way that NibePi sends me the subscribed registers every x time units? Thank you very much, Jan |
||
|
||
|
Unfortunally a request node only request one register and it takes 2,1 seconds. If it happens to be a favorite the request is faster. This is a limit that comes with the heatpump. Modbus40 wont improve this either. Because from my understanding it dosent support reading multiple registrers at one time. In point 1 and 2 you are right. 3) The communication between the worker and the backend is using node.js child_process.fork() option which spawns an IPC channel between the backend and the worker. And uses process.send() to communicate. This gives the worker and the backend two event loops that runs independently. Making sure the backend can prioritize the serial connection. 4) The Node-RED configuration node just includes (require('worker.js')) and have full access to all the parameters of the worker. When the worker has all the configuration parameters it then spawns (fork()) the backend. If you redeploy nodered the backend still runs connected. I have not implented the mqtt part yet. But it will be set up in the worker as a option. For nodered users it will be unnecessay to have the worker doing mqtt. When you can just use a mqtt node for that. But the "NibePi Interface" needs it. So it is Backend <-> Worker <-> NODERED <-> NibePi dashboard <-> MQTT Do you have an JSON example how that single topic should look like? |
||
|
||
|
Mmm I haven't really thought about the JSON structure right now. It is good to have the option of the worker communicating directly to MQTT as well. ( I understand that for other usecases the node-red part is needed) For logging I don't need the node red part at all. (keeping it as simple as possible) My process for logging would be: OpenHab (or some custom service) just subscribing to single MQTT register value topics. (or the sum up topic) When a new MQTT message is received I'm taking the timestamp and the register value and put it in the InfluxDB. (time series based db) So the only thing NibePi needs to do is receive the value from the heatpump and publish it to the specific register topic including the timestamp. Visualisation is done with Grafana which does that perfectly from different data sources. But I understand that correctly that the modbus messages don't include the timestamp for the reading itself? @JanRi MQTT ist Publish and Subscribe. Man subscribed mit dem Client für ein Topic und bekommt automatisch dann die neuen Werte, wenn neue Werte da sind. (gepublished werden) Ich persönlich bevorzuge, wenn der Timestamp direkt an der Quelle gesetzt wird und nicht erst irgendwann im Prozess, deswegen würde ich es auch für die Favoriten vorsehen. (da man es eh machen muss, würde ich es überall gleich machen) |
||
|
||
|
You're correct in your first part. That's my understanding too. But NibePi works a little bit different, first of all the backend or the worker does not store any data waiting to be requested. NibePi only works with live/most-recent accurate data. NibePi is a subscribe/publish/request unit. If it has data availible it publishes it. So it will publish the favorite registers every 0,5 seconds. It also has a built in "regularQueue" which other registers can be included in. The registers in that queue will be requested from every 2,1 second in order. So a regularQueue of 10 registers will take 21 seconds to get. So the delay will be 21 seconds for every register. Again this is not specifik for NibePi, it's the same with Modbus40. These registers will get published regulary. The time from rs485 data to mqtt should be less than 500mS. And the timestamp will probably be set around 50mS after the serialbuffer arrived. So NibePi works with live data. Always. |
||
|
||
|
So to make that clear for the "regularQueue" of lets say 2 registers we have: 1) Request Register One - wait 2,1 seconds - receive the result via modbus 2) Request Register Two - wait 2,1 seconds - receive the result via modbus 3) Publish the results after 4,2 seconds And 1) and 2) results coming from the heatpump do not include a timestamp so it would be great to save directly a timestamp after 1) and after 2). Is that correct? And are the values coming from the heatpumpt live values and just the request takes 2,1 seconds to be answered or are they 2,1 seconds old? |
||
|
||
|
Yes, it's just to subscribe to any register topic, but it has to be added to the getRegular list first if it's not a favorite. Example nibe/modbus/40004 would publish the outside temperature if it has been added first to the regularlist. You will be able to add it in NibePi interface or with something like nibe/modbus/40004/add . If you publish to nibe/modbus/40004/get a request will be made and data will be published to nibe/modbus/40004 even if it is not in the regular queue. nibe/modbus/40004/remove will remove it from the regular queue. This is not done yet in 1.1 im still working on it. Answering your question about the queue. The queue always sends out a ready message. So when Nr 1 is done it's sent out and it starts to work with nr 2. The real data occurs some between 0-2,1 seconds. The heatpumps allows request every 2,1 seconds. If you happen to request just 1 mS before that you will get the answer in a couple of mS. |
||
|
||
|
Hi, But it publishes (sends) them as soon as their is something, right? Lets assume I have 20 favorites. Now I subscribe for 10 of them and additionally I subscribe one register that is not a favorite. If I understood you correct, the following will happen: NibePi gets the 20 favorites from the heat pump every 0,5 sec. As only 10 of them are subscribed, it will publish those immediately. Furthermore, it continously request the additional register I subscribed so it will be published every 2,1 seconds. From the viewpoint of the subscriber (or user), I will get my 10 subscribed favorites every 0,5 seconds and the additional register every 2,1 seconds. Right? As NibePi can only send one register at a time, I will get the 10 registers not at once, but directly one after the other (a kind of "bunch"). Therefore, for logging purpose, if I get a bunch of favorites, I can assume that they originate from the same "big buffer" send by the heat pump (therefore representing a consistent view). After that bunch, there is silence for some fraction of 0,5 seconds until I get the next bunch and so on (with the non-favorite some between). With respect to publish subscribe, it publishes everything it got from heat pump without checking if the register value have changed at all. So for static values such as serial number I will get the same data again and again and again... Is this understanding correct? As I'm new to Node Red, MQTT and so on... what would be the most simple approach for just logging favorites (by subscribing to them) with the currect state of implementation? The logging itself should happen at some other machine not requiring the NibePi to have some writable medium. Greetings, Jan |
||
|
||
|
That's wrong. NibePI doesn't know which MQTT topics are subscribed from clients. (this does only know the MQTT broker) NibePI just gets the favorite register values every 0,5s and as soon as it gets the value it publishes the value to a MQTT topic. The MQTT broker than forwards the value to all subscribed clients. (your logging client) So to sum up NibePI receives every 0,5s all of the 20 favorites and publishes them directly to topics named "nibe/modbus/<register value>". It doesn't care which clients are subscribed to these topics. That's the nice thing about a message bus. The clients (in our case Nibe PI and our logging client) don't know each other and they don't have to. They just communicate via the MQTT broker. (indirectly) Hier einfach erklärt: |
||
|
||
|
Hi, I'm only not familiar with MQTT but the basic pub/sub-princible is very clear. At the end, we mean the same but we look at it from different viewpoints. I only considered the transfer between the NibePi system as a unit (everything including the broker) to the client while you looked at the internal structure and especially the pub-sub-relations. The result is alway the same: The client gets what it wants to get (the subscribed registers). So to put both views together: The heat pump sends the favorites every 0,5 seconds. Some part of NibePi gets all this. It is connected to the broker and publishes just everything it gets. Additionally, if it is aware of interest on some non-favorite register (by the add command), it also reads that periodically and publishes the answer. At the end, the broker gets all this data. If we have a client that subscribes to some registers, it is the task of the broker to deliver the data because the broker implements the decoupling between publisher and subscriber. In my example from the posting above this means that the broker is aware of the interest of our client in these 11 registers (the 11 topics) and therefore sends every publication on one of those topics to our client. If we change our view from the pub-sub-view to the data flow view, we have more or less the description from the posting above with the difference (here I was wrong and you corrected that) that the filtering is done by the broker (which makes more sense in this architecture) and not the component reading from heat pump. However, for logging purpose it should be sufficient to put everything we want to log into favorites and to subscribe to that. All we have to do is to figure out which bunch of messages belongs to one "snapshot". As I guess the values are published in the order they are contained in the message from the heat pump, we get them (if the broker and the network preserve order - I guess we can assume that in a LAN setting) in that order. In this case, it should be simple to put the values together as one log line (one snapshot). Remaining question: How do we write a register to heat pump? Is there a special topic the appropriate NibePi component is subscribed to? Then, if our client publishes a write request on that topic it will be written to heat pump? Or is this done differently? Greetings, Jan |
||
|
||
|
Yeah that is how it works right now if I understood @nibepis descriptions correctly. Well from my point of view it is pretty easy. For storage I would personally prefer a time series based database like InfluxDB (https://www.influxdata.com/products/influxdb-overview/). You just feed the db with datapoints. Each datapoint containing a name/value/time pair. (plus some meta data if you like) So it would be enough to subscribe to the different favorites register topics. The data value you get from each topic contains a point of time (timestamp) + the value itself. You take that data and throw it in the InfluxDB as a datapoint. For visualisation of the whole stuff you can use Grafana (https://grafana.com/). For more specific analyis you can use the query language of InfluxDB. So the whole "get me one snapshot of a point of time" is just one select away. The nice thing about sth. like influx db is that you can use that for every sensor data you have in your house no matter which source. (KNX, 1 Wire sensors etc.) And you can do time based analysis on this whole data pool not pretty easily. Thinking about the whole thing again and again leads me to the conclusion that a MQTT topic which contains one complete snapshot of favorites data ist not really needed. |
||
|
||
|
Hi, at the moment I'm using csv-files written by shell- and python-scripts but I see the advantages of the databased solution. Maybe some time... I agree to that. If our client really gets the whole favorite set every time the heat pump send it, we do not need such a topic. Greetings, Jan |
Beitrag schreiben oder Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]