I have a lot of zigbee sensors which send out reminders of their status at regular intervals, so I use a lot of rbe nodes so that I only process actual changes in state. Unfortunately every time I deploy, the rbe nodes lose their state so I subsequently receive a lot of spurious messages the next time each sensor posts its status. Could the rbe node be modified to use the persistent context storage so that it survives a deploy?
Perhaps I've missed a trick here, if there's a better way of handling this I'd be glad to hear it. Thanks
The RBE node can be set to ignore first message. So it uses that to set its internal state then reports changes from then on.
Also if you use a partial rather than full deploy they will not lose there status, unless they are in the nodes to be deployed. Click the down arrow on the Deploy button.
if rbe can have option to persist the last value that would be very helpful. that way node-red would correctly handle the changes regardless of restarts.
If you do a 'modified nodes' deploy rather than a full deploy then the rbe will keep its state.
true. i am talking about different use case, where restart of node-red (which is needed sometimes .. e.g when removing nodes from pallet, after a crash etc) is unavoidable.given purpose of RBE, i think lot of users will benefit for persistence.
But while the runtime is stopped how do you know that input hasn’t changed ?
good point. if it had changed and gone back to original value, then flow wouldn't catch that. but that is another problem for another day.
i will go on a limb, and say that most of users would rather have value persisted than than not. restarting node-red shouldn't mean losing value (lol, maybe when you mess up values and want to intentionally reset all of the values ) . i have several flows which track certain value (prices of certain items, status of various applications/ availability of time slots/tickets), on different websites and send me alert if value changes. it would be immensely helpful to have this node persist values.
hoolahoous you can achieve what you want fairly easily:
- Configure your nod-red for filesystem context storage.
- Use a function node on the output of your rbe node to write the current
topic/value to a context variable. (If you have multiple topics you'll need to
use a JSON object as your context var and add each new topic/value pair that you see). - Use an inject node configured to fire once at startup to trigger another
function node to read the context variable and inject it into the rbe node.
For multiple topics you'll need to iterate the context object and inject each topic/value. - Configure the rbe node to ignore the initial value.
There you have it.
I'm the OP of this thread btw, I still have it on my todo list to write
node-red-contrib-persistent-rbe one day because for some reason I just like to do a full deployment anytime I've made a lot of changes.
thanks pcb.. alternatively a function node could do it in one single node.. but i was hoping that since this is such a common request, maybe it should be part of rbe itself.
Second time in 5 years, and first is fixed by ignoring first reading from repeating sensors. So not that common.
I doubt that. For most I suspect they would rather have an extra notification rather than risk missing one. An extra notification may be an inconvenience, a missing one could be catastrophic.
Also most systems, once they get into a 'production' state, don't keep restarting.
How do you get the data into node-red?
I'm using zigbee2mqtt
and a mqtt-in
node. Only the router is sending the state every 60 seconds.
Yes I use zigbee2mqtt. Some sensors send regular reminders of their state, some don't, Aqara sensors send a lot, every hour or so, Ikea tradfri and Konke don't send any.
Every hour isn't a lot. I also use xiaomi- and aqara-sensors/switches.
They just set the state and the message goes trought several nodes without any problems.
To check the availability I use a watchdog per device (timeout 70 mins).
For the router the wathdog is set to 2 mins, here I only get a message on timeout.