Thanks for fixing the spelling mistake. I am not good at that, and I think that isn't helping me programming either. 
Ok, new day.
Bad news.
Booted this machine.
Looked at the page. NO LEDs glowing.
(I've changed the flow slightly to also have buttons.)
Their colour is set manually. The LEDs need an input.
Loaded CHROME.
Same.
Looked at the extra queue I added.
Strange it shows a message as being sent, but I didn't get the exact time.
I put a timestamp node in it now.
So more data next time.
If you open the dashboard in one window and in another wicdow press the button 'TRUE' going to the LEDs, do the LED's all turn on?
I'm just looking for a simple 'yes they turned on' or 'no they did not turn on'
Alas at this time the answer is a definitive NO.
Both browsers.
But I am suspicious (now) of the ui_LED node.
I'll do more work and investigations.
And though not directly related, on this machine the WiFi scan has not been stopped from an inject node injecting a signal to stop it scanning at boot.
So maybe the inject node/s are playing up too?
Still too soon to know.
Slight update:
Seems button doesn't allow true to pass.
But it wasn't working before the buttons, so that is another bug I seem to have found.
Do you want me to raise it or are you in the right place to action it?
I modified the flow to bypass the buttons and I have booted now.
The screen LEDs are all set correctly.
That is this time.
If you read the info tab for the ui_button you will see the:
If set to pass through mode a message arriving on the input will act like pressing the button. The output payload will be as defined in the node configuration.
No matter what you send to the button, the output will be what you have defined in the button node. If you haven't set anything,
If no payload is specified, the node id is used.
If you were sending this output (the node id) to a ui_led node, the led will be grey since the node id does not equate to true or false.
In other words, the flows are doing exactly what you told them to do, but not what you want them to do.
Yeah, ok.
I did read something in the "info" part of the node, but what you say (or quote) is:
the output will be what you have defined in the button node
I read that as a pass through.
Irrespective of what the button has set to send when pressed..... If I tick the
If msg arrives on input, pass through to output
What ever is sent in, is sent out.
That's how I read it.
So the button may send pressed when pressed, but if I send something else, the something else is passed to the output.
Ok. My bad.
Sorry.
Maybe the line should read If msg arrives on input, send the 'button clicked' payload
BUT the moral is "Don't assume anything, look at the info tab of the node."
Does the info tab for the node say differently?
I think I spent a few good minutes reading that too and was not really any more confident.
The only bit that had me worried was this part:
Setting msg.enabled to false will disable the button.
But that is msg.enabled not msg.payload.
I thought it could be a bug. (It does happen.)
I am not trying to waste your time. I am just not understanding why things I have set to happen not happening.
It could be the inject node isn't working.....
But the latest stuff I have seen is: It is working.
However! that could be because I added specific nodes after it which are then recognised and the payload sent.
(shrug) It is beyond me.
Adds a button to the user interface.
Clicking the button generates a message with
msg.payloadset to the Payload field. If no payload is specified, the node id is used.The Size defaults to 3 by 1.
The Icon can be defined, as either a Material Design icon (e.g. 'check', 'close') or a Font Awesome icon (e.g. 'fa-fire') , or a Weather icon.
The colours of the text and background may be set. They can also be set by a message property by setting the field to the name of the property, for example
{{msg.background}}.The label can also be set by a message property by setting the field to the name of the property, for example
{{msg.topic}}.If set to pass through mode a message arriving on the input will act like pressing the button. The output payload will be as defined in the node configuration.
The Topic field can be used to set the
msg.topicproperty that is output.Setting
msg.enabledtofalsewill disable the button.
the third line says If no payload is specified, the node id is used. You never set a value in the button node. That is why when you clicked the button in the dashboard, or sent a msg to the button node, the node id was sent out in msg.payload. Since the node id did not match any of the conditions you specified in the LED node, the color went to grey.
Like I said, your flows worked perfectly, just the way you coded them, but maybe not the way you wanted them. So in this case, neithor the led, button or inject nodes have bugs. Your use of them was wrong.
2 Likes
I have to accept that.
However, we are straying from the fact that BEFORE I had the buttons there are/were times when I would load the page and all the LEDs were grey.
Andrew, this is a problem I have seen when people try to help you. You bring up an issue and someone asks a question and before you answer it you change things.
Do you now have an issue with LED's being grey? If so, recreate in a small sample flow and then provide that flow for others to look at.
1 Like
To now I can't.
What ever is/was happening has stopped.
Yeah, I probably do. But that is because I am trying to fix it myself.
"So why ask for help?"
Because it is beyond me knowledge and I am (as I said) trying!
There seems to be a few things going on with my set up/system.
(Which are beyond this scope so sorry for posting)
As mentioned I have another flow which scans WiFi networks for WAPs.
It is on this machine.
For reasons unknown to me, it defaults to ON at boot. No big.
To fix the problem I put an inject node to inject the signal required to stop it.
It is an "inject at startup".
It works - sometimes.
That annoys me.
I made a screen full of LEDs all different colours so I can see them and when designing screens I can better pick a colour.
Now and then I would look at it and the LEDs would be grey. I can't give a ratio, but it was enough to be annoying.
There are other things going on in/on other flows, which can/will be blamed on me and my programming.
These involved inject nodes, and LED nodes - and others. But basically those were the main two.
I couldn't prove the inject node was failing and sometimes when I injected they still didn't change colours.
Part of this may have been an old dashboard. That is now not applicable as I am updated to the latest version.
To help me with the colours I decided to add buttons to the flow. Buttons are standard and the colour names are also "built in" so I thought it would be nice to add them to the flow.
I stuffed up with reading the button's working and made a bad situation worse. (Story of my life)
That is now behind me.
I just looked and the problem with the WiFi scanner flow is still there despite the inject node being in the flow and injecting a stop signal once at start.
Inject node bug? Dunno.
I added more nodes to try and capture the problem but they only seem to confuse me.
A bit like: Things behave differently when you look at them to when you aren't.
The link node problem had me going nuts for a while because I occidentally connected an output to an input.
But "it was my fault for doing it"...... Basically.
The other day I did update 3 RPIs to the latest NR. Everything. Smooth as.
The fourth wasn't going to have a bar of it and I gave up at 02:00 local time - or there about.
The next morning my internet modem decided it was its turn to make my life hell and basically was going up and down at random times throughout the morning.
It took about 1 hour on the phone and at the end I was told it was my computer causing the problem. Despite while on the phone I could see the modem going on/off line.
Sorry.
That's only the surface of things. I know: "We all have our crosses to bare....".
For now, they are working. Why: I don't know. Will they work next time: I don't know.
Maybe the update fixed something. I don't know.
At the time I mentioned it: It was happening.
Forget I mentioned it. If it happens again, I will say something.
