I have already often built my own mechanism to store the output from a dashboard node into a context variable and then read the current state elsewhere when I need it, but I wanted to verify this:
- There is no way to have a change node or function node to retrieve the current state of a dashboard node (i.e. switch is on/off) unless that state was saved to a context variable upon an output from the dashboard node.
Remember that the Dashboard and Node-RED run in two completely different environments, often on different devices. The only link between them is a Socket.IO based websocket connection.
Also remember that a Dasboard might be open in multiple tabs/windows, possibly on multiple devices.
The way that Dashboard works is that any updates that a user makes in any instance of the Dashboard are sent to Node-RED. It is up to you to sort out where they have come from and what to do with them.
It wouldn't make sense to have Node-RED to reach out to try and get a value - which instance of the Dashboard would it get the value from? What if there were a hundred different values in different instances?
I always assumed that Node-Red itself knew the nodes current status. For instance imagine 1 switch node:
- User 1 connects to dashboard and sees switch in default position (say off)
- User 1 switches to on
- User 2 connects to dashboard and sees the switch in its current position (now on due to change made by user 1).
It does not need to be saved to context, but it needs to be stored somewhere. I use MQTT retained topics to save the state of switches etc and to restore them on node-red restart. Also it could be stored in nodes such as Join nodes.
Here is the situation, I am looking to address. I have 3 lights (Kathy, Mike, Overhead). I am using the multiswitch to control them with Overhead also having a separate switch. Ignore the charger switch.
When I get an update of Mike to on, then I want the multiswitch to go from off to Mike. This is easy. If however, Kathy is already on and an external input of Mike just turned on, then I need to move the switch from Kathy to both.
So without storing the state of the multiswitch in a context variable and then using the incoming new Mike on input plus the context variable, I can't distinguish between the 2 states.
I have done this before, but wanted to make sure that there wasn't a direct line to the current state without having to manage it myself.
Dashboard nodes may store the last value I think and may offer that as a cached value to new connections and will send updates to all connected clients.
Feed all the states into a Join node in key/value mode and then when any one of them changes the join node will output a message with all the current states in it so you can do what you want with the switch.
Very elegant solution to the specific case I am working on.
The concept will work in very many situations. I virtually never use context for such issues.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.