Ui-leds grey after update

Dashboard
1

After updating my nodered-system yesterday, the ui-leds in my dashboard are grey and not green or red as usual.

I can force the ui-leds to green or red by manually injecting true or false. For example this log entry turns the ui-led from grey to red:

5/14/2021, 10:30:42 AMnode: 74507e09.d8ac08
polling : msg.payload : boolean
false

But my normal flow, which reads a modbus-slave, sends true or false each 100 ms to the ui-leds and then the leds are staying grey. These boolean messages look the same as my manual test inject:

(normal ui-led inputs each 100ms)
[...]
5/14/2021, 10:24:55 AMnode: 74507e09.d8ac08
polling : msg.payload : boolean
false
5/14/2021, 10:24:56 AMnode: 74507e09.d8ac08
polling : msg.payload : boolean
false
[...]

I thought that 100 ms cycles are eventually too fast for the new dashboard/ui-led, but even if I set the cyles to 2 seconds for example, the ui-leds are staying grey. I'm running out of ideas for the reason. I can't remember if those socketids were in the URL in the past, example:

http://192.168.123.246:1880/ui/#!/1?socketid=D2Q_06JgyfmGMkJJAAAA

I have the problem with the dashboard ui-leds with firefox and chromium, all systems (PC and RPi4) with current Buster.

May 14 10:16:22 opi2 Node-RED[372]: Welcome to Node-RED
May 14 10:16:22 opi2 Node-RED[372]: ===================
May 14 10:16:22 opi2 Node-RED[372]: 14 May 10:16:22 - [info] Node-RED version: v1.3.4
May 14 10:16:22 opi2 Node-RED[372]: 14 May 10:16:22 - [info] Node.js  version: v12.22.1
May 14 10:16:22 opi2 Node-RED[372]: 14 May 10:16:22 - [info] Linux 5.10.17-v7l+ arm LE
May 14 10:16:23 opi2 Node-RED[372]: 14 May 10:16:23 - [info] Loading palette nodes
May 14 10:16:26 opi2 Node-RED[372]: 14 May 10:16:26 - [info] Dashboard version 2.29.0 started at /ui
2

Set the debug node to show Complete message and see what the difference is in the message. Perhaps you are setting a socket id in the message, so only connections with that socket will take notice of the messages.

3

Ah, "complete message" is located in the debug node and not in the debug messages window, thank you.

My manual injection of boolean false (which successfully changes the color grey to red) has a simple object structure:

{"_msgid":"403eb9eb.161f58","payload":false,"topic":"polling"}

The non-working object (ui-led remains grey) is more complicated indeed:

{"topic":"polling","payload":false,"responseBuffer":{"data":[true,false,true,false,false,false,false,false],"buffer":[5]},"input":{"topic":"polling","from":"","payload":{"unitid":"","fc":2,"address":"0","quantity":"1","messageId":"609e8ff3e92e3c5ab46f7952"},"queueLengthByUnitId":{"unitId":1,"queueLength":0},"queueUnitId":1,"unitId":1},"sendingNodeId":"2ce4e912.835a5e","_msgid":"59261441.27dddc"}

Does this complicate object contain something, that confuses ui-led?

It is the output of my change node, that picks the true or false state from a modbus array and moves it to the msg.payload. Until the updates yesterday it had worked in the past as valid input for ui-led.

4

I don't see anything in there that should confuse it. It has three extra attributes, responseBuffer, input, and sendingNodeId
Add entries to the change node to get rid of each of those by adding rules such as
Delete msg.input
If that fixes it then remove those one at a time to find which one(s) it is that causes the problem. Then please submit an issue on the ui_led github page describing the problem.
I presume you have checked that you are using the latest version of that node.

5

Colin, you're the man!
Filtering those attributes helps!
sendingNodeId had no influence, but as soon as responseBuffer or input is deleted in the object, ui-led works a expected! I deleted both attributes now:

Ui_led is the latest v0.4.9. Eventually the deeper reason is the latest node-red-contrib-modbus v5.14.0, which had been updated a month ago. I have another quirk with this node in my flow that I have to sort out. Perhaps the mentioned attributes are new in that modbus version.

Thanks a lot

6

Could you submit an issue against the node please. Issues · Adorkable/node-red-contrib-ui-led · GitHub
Explain the problem and include a link to this thread.

7

Of course I will do, but I'm not convinced at the moment, that node-red-contrib-ui-led has an issue. The other "quirk" I had in my flow was with node-red-contrib-ui-svg. I could solve its problem too by deleting msg.responseBuffer and msg.input with a change-node between the modbus-read node and the SVG graphics node.

Wouldn't it be better to submit an issue to node-red-contrib-modbus?

8

Sorry, one question:

What is this moving msg.payload[1] to msg.payload all about?

9

Hi,
just a quick answer from my memory.

When the msg.payload is an array - for example
[true,false,true,false,false,false,false,false] - then msg.payload[0] picks the first field (here true) and msg.payload[1] the second (here false).

Moving this selection to a new msg.payload makes it directly usable to turn on or off a ui-led in the dashboard for example. Don't know if it is good practice, but it works for me.

10

And so, if msg.payload is an array...... It wouldn't work sending an array to the LED node.

But anyway, sorry. I just wanted to check if I understood the problem myself.

11

Yes, but at the output of the change node the msg.payload is boolean ("payload":false) then, see post #3.

12

Why? Nothing in the docs for the led node says that the other properties should affect it, therefore it should not matter whether they are there or not. It is very common for messages to contain additional properties used by previous nodes.

13

Ah ok, thank you, I have opened an issue for node-red-contrib-ui-led. Probably I have to do the same for node-red-contrib-ui-svg then, which is affected too.

1 Like
14

Yes if there is an issue with the svg node, please create an issue on Github to avoid that other users have the same troubles.
And please add enough info in the issue, because I don't go in depth through all discussions on Discourse...
Thanks!
Bart

15

Thank you, Bart,
just a very short summary at the moment: The issue with node-red-contrib-ui-svg is the same as in this topic, the grey fill color of elements can't be updated without the solution/workaround in post #7.

16

It would be useful for me if you create an issue in the svg node Github repository, so I can refer to that issue in the code for the fix...
And if you can add a simple flow in the issue, that would be a great help! I mean an svg with a single shape, and 2 inject nodes: one that fails and another that works (i.e. which is wired to the change node to delete the msg properties).
It doesn't ring a bell to me at the moment why it fails. I'm very curious now...

17

Yes I'm seeing some strange behavior after update too. I could not work out what was happening after I rebuilt a Pi from scratch, loaded my working flow backups and suddenly observed what seems like an inconsistent behavior where some of my LEDs should be showing green for healthy condition but show grey sometimes...

18

If I remember right the leds will show grey until a value I’d sent to them. So you could have an inject node send an initial value on deploy.

19

Yes that's how they are configured, in fact they are constantly updated

20

So are you saying that even after initializing them they will go to grey?

If so, I would add a debug Node to the output of the node feeding the ui-led node to see if there is a chance something invalid is being passed in.

What version of node-red, node.js, dashboard (start the startup log) and the ui-led node are you using?