Per message color configuration

[Just-another-pleb]

Just as something which has become of interest to me playing with JavaScript.

Could the colours be set by the message properties like: msg.truecolour msg.falsecolour

Then if the true value is received, the truecolour is displayed.

[yoiang]

Do you mean color configuration along with the message? It's a great idea! I'd want it formalized to be more robust and potentially an opt in option.

Re: more robust I'm thinking maybe a msg.colorForValue map that would be used in your case as:

• msg.colorForValue[true] === what you would have passed in msg.truecolor
• msg.colorForValue[false] === what you would have passed in msg.falsecolor

Does that feel like jumping through hoops or will it require the same amount of construction in Node-RED you were planning to get values in truecolor and falsecolor?

I'd especially want this to be opt in because one could see unsanitized data causing havoc with the expected color output, for example not even being able to identify erroneous data.

Edit: haha the map should be colorForValue not colorToValue, fixed

[Just-another-pleb]

Hi..... Yikes! Just looked at the reply address.

I'm up to my neck (or higher) just now with NR. I am really not having luck.

The idea came up because I was using one of you LED's as an indicator.

Alas, in a perfect world all would be good. But the flow got complicated. It needed its colours edited "on the fly".

So my idea is that to set it up, you would send a message with a "topic" (or something) indicating to the node that this message sets the colours for the TRUE - FALSE - (and) - BLANK.

That message sets the colours. Subsequent messages which don't have the "topic" (or what ever) set, are treated as normal messages and the LED colour changes to suite.

Honestly, it is just a thought. Probably not that much need. LEDs are usually either on or off. You having the third option is good enough for most things. I just got hit with this "problem" and it seemed like a nice idea.

Thanks.

On Wed, 10 Jul 2019 at 00:10, Ian G notifications@github.com wrote:

Do you mean color configuration along with the message? It's a great idea! I'd want it formalized to be more robust and potentially an opt in option.

Re: more robust I'm thinking maybe a msg.colorToValue map that would be used in your case as:

• msg.colorToValue[true] === what you would have passed in msg.truecolor
• msg.colorToValue[false] === what you would have passed in msg.falsecolor

Does that feel like jumping through hoops or will it require the same amount of construction in Node-RED you were planning to get values in truecolor and falsecolor?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Adorkable/node-red-contrib-ui-led/issues/38?email_source=notifications&email_token=AJQKLGEGKMTTQAYJPPDIUYLP6SL4PA5CNFSM4H7CV3H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZQMKQQ#issuecomment-509658434, or mute the thread https://github.com/notifications/unsubscribe-auth/AJQKLGDURMSYTA3F3U5UUBTP6SL4PANCNFSM4H7CV3HQ .

[yoiang]

So if we are to have the most recent msg.colorForValue act as an override going forward for messages to that LED that don't contain a msg.colorForValue I would expect this override to stick between restarts of Node-RED on a per LED basis as well. What do you think?

[yoiang]

Refreshing on Node-RED contexts I don't think persistence should be within the scope of this feature, it'd be too much of a "you have to set up Node-RED this way".

The more robust solution is to have a node that checks if colorForValue values are in a message and sets it to the context and a matching one that checks if one has been set and includes it in the next message if so. I could see those being separate nodes included in this library, I'll think about it more and play with constructions.

I should have a first PR with this feature soon, just running through a few test cases before pushing.

[Just-another-pleb]

And fair enough.

You lost me with the last sentence.

I should have a first PR with this feature..... PR?

On Wed, 10 Jul 2019 at 07:58, Ian G notifications@github.com wrote:

Refreshing on Node-RED contexts I don't think persistence should be within the scope of this feature, it'd be too much of a "you have to set up Node-RED this way".

The more robust solution is to have a node that checks if colorForValue values are in a message and sets it to the context and a matching one that checks if one has been set and includes it in the next message if so. I could see those being separate nodes included in this library, I'll think about it more and play with constructions.

I should have a first PR with this feature soon, just running through a few test cases before pushing.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Adorkable/node-red-contrib-ui-led/issues/38?email_source=notifications&email_token=AJQKLGCMWJM3PPNSNRWPSC3P6UCZRA5CNFSM4H7CV3H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZRVEKA#issuecomment-509825576, or mute the thread https://github.com/notifications/unsubscribe-auth/AJQKLGECU742M2T4G63P5IDP6UCZRANCNFSM4H7CV3HQ .

[Just-another-pleb]

Actually just another thought that came to mind.

Though you have this as a LED......

Neopixels are becoming more popular. Though I get that this is a dashboard for NR.....

That may be an interesting idea to consider.

Maybe the control could be the same format as how NeoPixels get their commands.

That way if someone wants to test a project this node would be a nice test bed.

On Wed, 10 Jul 2019 at 07:58, Ian G notifications@github.com wrote:

Refreshing on Node-RED contexts I don't think persistence should be within the scope of this feature, it'd be too much of a "you have to set up Node-RED this way".

The more robust solution is to have a node that checks if colorForValue values are in a message and sets it to the context and a matching one that checks if one has been set and includes it in the next message if so. I could see those being separate nodes included in this library, I'll think about it more and play with constructions.

I should have a first PR with this feature soon, just running through a few test cases before pushing.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Adorkable/node-red-contrib-ui-led/issues/38?email_source=notifications&email_token=AJQKLGCMWJM3PPNSNRWPSC3P6UCZRA5CNFSM4H7CV3H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZRVEKA#issuecomment-509825576, or mute the thread https://github.com/notifications/unsubscribe-auth/AJQKLGECU742M2T4G63P5IDP6UCZRANCNFSM4H7CV3HQ .

[yoiang]

That's interesting, if you think it is potentially helpful and have time to think about what that would mean and formalize it it'd be great to start a new discussion, feel free to start a new issue.

PR is pull request, when I have a few minutes today I'll push it to git so you can try it out.

[Just-another-pleb]

Thanks.

I shall try to get online later.

Where should the discussion happen? On the node red forum or in the git hub place. On 12 Jul 2019 2:27 AM, "Ian G" notifications@github.com wrote:

That's interesting, if you think it is potentially helpful and have time to think about what that would mean and formalize it it'd be great to start a new discussion, feel free to start a new issue.

PR is pull request, when I have a few minutes today I'll push it to git so you can try it out.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Adorkable/node-red-contrib-ui-led/issues/38?email_source=notifications&email_token=AJQKLGBNAIAB6ZRZ3YLKHOLP65NNNA5CNFSM4H7CV3H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZXH4JY#issuecomment-510557735, or mute the thread https://github.com/notifications/unsubscribe-auth/AJQKLGDJF5WYNQ7EU4HORNLP65NNNANCNFSM4H7CV3HQ .

[yoiang]

https://github.com/Adorkable/node-red-contrib-ui-led/issues/new/choose

[yoiang]

Feature included in 7a7cc148f44792f913d3504695bb942c8df456c0