Slider and numeric widgets only pass through message if different from current value

Unlike the behaviour of other dashboard widgets. The slider and numeric widgets do not pass through incoming message that are the same as the current value, even if the pass incoming option is set. I have tried with both numeric and string inputs but the effect is the same.

I am trying to simulate a form in the dashboard (I need to use some drop downs). So my join node needs to receive all the values from the other widgets even if they have not changed. I do this by sending them all initialisation messages so the join node is primed with the current values and will receive updates if values are changed via the UI. This works for everything other other than slider or numeric widgets.

Am I missing something here?

How can I get round this? Any ideas?

If this is designed behaviour then I would be helpful if it was mentioned in the documentation. If not then I suggest this is a bug.


I have come across a similar thing in setting up a "Parameter" dashboard for my system - On startup of the dashboard, I trigger an "update" to get the existing parameters of the system, essentially pre-loading the dashboard sliders/fields/text input areas as per the current settings.... It seems a bit hit and miss... Some ui nodes seem to pass this to screen and other types of ui nodes dont...

The problem is not with what is appearing on the screen. It is what get passed back into the flow by the nodes output messages. Especially when the ui has been initialised from automatically stored state that you do not have any control of.

I can confirm your findings with dashboard 2.28.1, at least with the slider.

I suggest filing a bug. Include a mini flow (inject plus slider/numerics plus debugs) to make it easier for others to check.Issues · node-red/node-red-dashboard · GitHub

This is currently working as designed.
Most widgets only send data to the front end if the value has changed - all the passthrough option does is allow it to block sending out data if it came in from the input rather than the ui.
Internally widgets have a flag emitOnlyNewValues which defaults to true. Only the button, text, template, gauge and switch have it set false.
We could change that decision but need to carefully consider if it would break anyone else's flows first.

My original problem here was "How do I get a group of dashboard to work like a form using a manual join node?". This a common suggestion that has been mode to get round limitations of the current form widget, especially the lack of a drop-down. What I found was sometimes widgets were not sending a message to the join node. The first run after a restart of node-red might work. But a subsequent one would not. My first attempt to solve this was to set all the widgets to a known state when my "form" was displayed, and set the pass through option on the widget. This worked for the nodes mentioned in the previous post that have emitOnlyNewValues set to false.

My work round for this was to add the topic that the widget would have sent to the reset message, and then send that message to the widget input and to all the nodes that are connected to the widget output.

This works.

A more ideal solution for for this situation would be to have a message property that could be sent to a widget that would force it to re-transmit its current status.

An alternative would to implement a msg property that forces emitOnlyNewValues to false. This could be implemented only on widget nodes that that have emitOnlyNewValues set to true. This would minimise the risk of breaking flows.

One thing that should be done is for the documentation to be explicit on the behaviour of nodes that have the emitOnlyNewValues flag. When I see in the ui documentation " If msg arrives on input, pass through to output:" I expect that to be exactly what happens.

Even if I like nodes with wide options how they behave or how they can be used - the most dangerous thing here is the checkbox in the nodes config or the property in message which by change will alter the owner of the responsibility to break the flow. The infinite loop the infinite loop the infinite loop the infinite loop the infinite loop the infinite loop....

And it is that at this point I bow out of this conversation :-). I have my work round and even if it is round, it is not a loop!

If you configure the join appropriately it will not forget the previous values, so they will always be available downstream.