I am using Dashboard 2 to create a dashboard that contains two dropdown nodes and a button. The dashboard will be accessed simultaneously by multiple users, so I am using the multi tenancy (Accept Client Data) functionality described here: Getting Started | Node-RED Dashboard 2.0
My requirements on the surface are relatively simple, but I'm having difficulties getting it to work as desired. I want to allow users to select a value from both dropdowns, and then when the button is clicked, use the selected values from both dropdowns for further operations.
I've configured the 'Accept Client Data' as required, and have my two dropdowns working independently for each dashboard instance/tab (so changes made on one instance aren't reflected on the other). The difficulty is with correctly getting hold of the selected values when the button is clicked.
I've wired the dropdowns to a join node so that whenever they change, the payloads are combined into a single message (using the dropdown topics as the key). This allows me to pass a message containing both values on to the button. However, unlike the dashboard nodes, the join node is not client constrained, which leads to undesired behaviour.
One such issue is as follows:
Open the dashboard
Select a value on both dropdowns - at this point, everything is okay, and the button receives a message containing both values
Refresh the page
Select a value on a single dropdown - at this point, the join node still holds the values that were selected by the previous client/socket prior to refreshing the page. This causes the button to receive a message with both values (the new one, and the stale one that hasn't actually been set for this client/socket).
Is there a recommended pattern/approach for dealing with this kind of requirement?
Thanks for the quick reply. I had read about the FlowFuse addon and the richer user functionality it provides, but unfortunately using FlowFuse is not an option for us.
Having said that, I perhaps didn't make it clear in my original post, but I'm not looking to tell that it's the same user after the refresh. The behaviour I'm trying to achieve is to have a 'clean slate' after the refresh is performed, so that as far as the dashboard and all nodes are concerned, no values have currently been set (rather than the current behaviour, where because of the join node the previous value lingers into the new dashboard socket)
but unfortunately using FlowFuse is not an option for us.
Mind if I ask why?
The behaviour I'm trying to achieve is to have a 'clean slate' after the refresh is performed
Ah, I'm with you. In that case, the ui-control could be useful as that emits an event when a socketdisconnects, you could use that to then clear the join of the data relevant to the socketId?
Sure - we are deploying Node-RED as part of an appliance, which already has it's own infrastructure, authentication mechanism, etc - along with the fact that resources on the appliance are limited, so we don't have the capacity to host an additional software solution on it.
Okay, thanks - I'll give that a try and see where I get with it.
Excuse the sales pitch here, but you may be interested in the FlowFuse Device Agent in that instance. It's a very lightweight agent that sits on your appliance, then FlowFuse can connect remotely and deploy/update instances of Node-RED running on that device.
If you have Node-RED/flow updates to run across your appliances, that's all managed centrally in FlowFuse too.
That's good to know, unfortunately we're too far down the line in our product lifecycle to introduce such a change - but I'll keep it in mind in case we are ever able to use it.
The user-specific context store functionality you described is going to simplify this use case drastically, as it would allow us to simply save the selected value for the socket when the dropdown is changed, and then retrieve all the selected values (if any) for that socket when the button is clicked.
