I'm developing a new UI node that can be configured to a.o. add N LEDS on top of an image. In the following example I add 3 LEDs, each with a different color:
Which results in something like this:
Now I want to control the color of those LEDs via input messages from the Node-RED flow. But not sure what the best way is to accomplish this.
Should I add a field in the config screen for every widget, where the user can enter a unique name (which I have to validate). Or should I generate an ascending index myself (and show it readonly). Or should I add a Or something else.
The input message should contain both a LED identifier and a LED color. Should identfier be the msg.topic and the color be the msg.payload (which e.g. can be configured via two TypedInputs fields), or should both be in the payload, or something else.
Suppose the user wants to change the status of all 3 LEDS. Should this be possible with a single input message (then I cannot use a topic I assume), or should I oblige him to send 3 separate input messages ...
I got in the past some great feedback from @DeanC (about another node), about avoiding people having to add tons of extra nodes (like Change node) in their flows to compose the input message. So that is really something that I would like to pay attention to this time...
P.S. This discussion is not about 'why' I want to add LEDs. If some users really hate LEDs, they can just ignore them. Case closed in advance
I would look at naming them so their id doesn't change if the user decides to delete one from the middle of the list. You could, of course, generate default values for the name as the user adds them, so they don't have to type anything in if they are happy with the default. It also means the user can identify which led is which in the list without having to remember which coordinates map to which light.
For the message, I'd start with the idea of msg.payload being a key/value object that maps led to desired state - allowing the user to set multiple. You could also check if msg payload is a string then use msg.topic to identify the single led to change - that's more streamlined for the single led case.
@knolleary: thanks, that makes sense and is very flexible. I like the idea that users can choose a bit, how they can control my node. Perhaps I could also check whether it is an Array of key-value pairs, to setup multiple leds at once ...
The only thing that bothers me, is that msg.payload could also contain an image (if the user specifies to push the images to my camera viewer). Then I have to detect also whether the payload contains a base64 encoded image, since there is no topic to see the difference between images and control messages. Not sure at the moment whether it is resource consuming to continiously do the base64 check. Or perhaps I need to add multiple TypedInputs:
One typed input for image source e.g. msg.image
Another typed input for control messages e.g. msg.payload
And validate that both fields need to be different. On the other hand then the users would need to use extra Change-nodes to move their images to msg.image
An object can contain multiple key/value pairs... No need to also wrap it in an array.
{
"LED1": "red",
"LED2": "blue"
}
If you want the user to be able to set the image as well, then I would avoid overloading a single property that much. Decide which is more important feature, use msg.payload for that and pick a suitably named property for the other feature.
@BartButenaers are these LEDs to be SVG based (e.g. are you presenting the image as part of an SVG and drawing colour filled circles?)
If this is the case, i could imagine a time where you add other shapes like a car or a person and this ends up being used as a layout with live / animated objects representing your data.
I would potentially use this as an AGV map. Send an AGV shape (SVG path or shape) to specific coordinates. Animate / update it's position on the image. Change its colour to represent things like fault, battery low, last seen etc.
Additional thoughts. Position should be a typedinput so it can be easily and flexibly animated. Widget itself could also be a typedinput. perhaps size/scale should also be available?
As for the widget itself, these could simply be a piece of SVG code in a file or folder of SVGs permitting the user to define their own? Or a config node where users can add additional SVG coded widgets?
Just a few thoughts - if they aren't relevant or go against your design or intended use then please ignore.
Have been thinking about that also, but I want to avoid users going to use it as a floorplan or whatever. Want to keep this widget focussed on video surveillance. Most probably I will add other shapes afterwards, but focussed on video surveillance.
For a floorplan that would be indeed useful, e.g. to animate where someone is walking. But to move LED's or PTZ buttons around on my camera widget seems very annoying to me.
Don't know if widgets are going to be changed dynamically? Perhaps I could make the visibility adjustable via an input message...
Have been thinking about that also. But I'm afraid that everybody is going to abuse my camera-viewer node as a general drawing node. Currently I would prefer if people contact me if they know a cool (camera related) widget to add, or that they create a pull request.
Think we need create in the near future a general SVG UI node, so you can start playing
Regarding your node,
Are you going to add click events to the SVG items? I could see someone wanting to operate things like lights or PTT for sending speech or audio to a camera or a network audio device (e.g. barix exstreamer).
As you are focused on surveillance, I imagine you might want to have camera widgets populating the drawing? Perhaps the ability to fire PTZ commands too? Or switch to the video stream on click?
Yes some of the widgets (like ptz control) have already clicked events, and result in output messages. Other widgets (like LED) have no clicked events.
Yes I draw the SVG shapes on top of the video footage.
As soon as I have an alpha version ready, I will start a new thread so we can focus properly on all these things. Have to stop here, because Discourse gives me a spoiler alert ...
Hey @dceejay,
One of my current widgets is "text" which is static text or supplied via a msg property. That allows users to show e.g. "cam living room" or an alert text or ... Is that what you mean?
This was a very decent proposal. However (based on the question of @Steve-Mcl), now I would also like to control the visibility of every widget via the input message (invisible or invisible). However e.g. a LED widget now has two properties that I need to control via the input message: color AND visibility. I assume the only way is to do that like this:
put the property name ("COLOR" or "VISIBILITY") in the msg.topic field
put the key/value pairs (from Nick's proposal) into e.g. the msg.payload field
Perhaps a topic "IMAGE" could be used when the payload contains an image to be displayed...
Is this an acceptable way of working, or is there a better approach?
That might indeed be a good message field to use! Will keep it in mind.
But when I look at the documentation, I still don't know where to put the widget name. A single cam-viewer node could contain e.g. four LEDs. So I need to be able to specify LED1-Color-red or LED3-Visibility-false. I cannot put 3 fields in a single key-value pair, so I wanted to put the third property into the topic. Or am I getting nuts?
Thanks @hotNipi !! And indeed I think your format is simple enough to allow users to create such a message with a single Change-node, so they don't have to clutter their flows to setup my new node ...
warning... ui_control messages currently get processed to overwrite exiting properties that otherwise can't be (like chart axis font size etc)... i "think" it should be ok for you to re-use like this... but ensure you don't have anything in your node config with the same property names.... and test before release
