Is this considered bad practice, or could it be a bad idea to do this?
Every time I receive a sensor reading from one of many Arduinos around the home, I write the sensor data to a global context object, then read all objects (all sensors) from memory to display on the Dashboard.
To be clear, this happens every time a sensor reading comes in. Although the incoming MQTT message triggers the Dashboard update, the data comes from Global Context, not passed through the flow (hope that makes sense).
Is this a bit over the top? Not so much the fact I write sensor data to Global Context, but that I call on Global Context every time I want to update a Dashboard view etc.?
I could probably update the part of the dashboard that corresponds to that sensor (rather than reading all data from all sensors every time one sensor updates, which is a bit illogical) but I'm doing the whole lot through a template node that displays a table of all sensors so this seems easiest. Also I know technically I could just pass the sensor data straight through to the dashboard but I combine it with stuff from memory to be able to monitor the state and compare it with previous readings etc. (e.g. a "last seen" and "device up status" etc. which would require a notification when the device was previously up, then went down.) A really general answer would be fine!
Right now I have two sensor nodes sending readings every 2 seconds each. So I'm reading an object of objects say every second and displaying on the Dashboard in a template node. I'm going to extend the period to 5 or 10 seconds eventually, but I may also increase the number of nodes in my home to 50 or even 100.
Sorry if my question is a bit "how long is a piece of string"... but is this
perfectly fine
keep an eye on performance
bad idea
really bad idea, never do this?
I know this question would be downvoted on Stack Exchange (!) because it depends on a lot, e.g. server hardware. To give an idea, I run NodeRED not on a Pi, but on a Hyper-V virtual machine running on a proper Dell server with 192GB RAM and decent dual processors. But it's more of a general "should I or shouldn't I" question and might steer me a little in my design decisions!
Personally I rarely use context for such things, I do everything through message passing and use Join nodes (as described in this post in the cookbook) where I need to combine the data with other information.
Others do it as you do and I don't believe there are any performance issues doing it that way.
Thanks, useful to hear. I guess the only downside is that if a device goes down, you wouldn't be able to determine its last reading, or if it's an actuator like a light, then its last state before it went down? (Presumably not important to everyone!)
You already know its last reading since it is the one passed last time. What exactly do you want to do with the last reading that means you need to save it in Global context?
I have a lighting scene management flow. If a light circuit goes down (e.g. in the fusebox) then when it comes back up I am able to automatically bring it back into the current scene selected.
As for sensor data, I can imagine scenarios where it may be useful. For example if a device overheats and it reports its own temperature value, and I only notice 5 days later after Node-RED rebooted, I could just look in Global Context. (it's pretty tenuous but could happen as the number of devices increases)
Can you describe exactly what is involved in doing that? I don't know enough about the hardware to know what is involved.
Normally one would use Retained Topics in MQTT to keep an internal mapping of the current system state so that it automatically restores the system state when a remote device reconnects or node-red restarts. In such cases you often don't need any additional logic to cope with those events, it just happens.
I think that is pretty tenuous. After node red reboots would not the value be replaced with the current value so the overheated value would be lost? If you have a need to record alarms and such like then I would suggest that would be better using some sort of database so you can look back and see what happened. Alternatively perhaps if an overheat event occurs it would be better to email or use Telegram or similar to notify you of the problem immediately. In which case the notification documents whatever data is needed.
