Switch node to use Label as output topic

Dashboard
1

Hello,

I have an array of objects used to populate the state of switch nodes on a dashboard.

I inject each object's current switch sate in the msg.payload and label in msg.topic.

Then when the switch state is changes on the dashboard I need to identify from its output which object in the array to update.

Currently I don't see away to inject information into the switch node that can be used in the msg.topic of the output to identify the switch. Being able to use the switch label in the output msg.topic would be perfect.

Any suggestions regarding this would be appreciated?

2

The msg.topic input will be the msg.topic output, when the input field is left blank.
[edit] I see the issue is when the switch is manually pressed in dashborad.

3

Thanks for your prompt response.

Here is the switch inject: {"payload":true,"topic":"Light","enabled":true,"_msgid":"a3c17f57.1ad5e"}

When the switch is manually pressed on the dashboard this is the output: {"payload":false,"socketid":"3OgE84LHeSQiDi5vAAAB","_msgid":"37b142e1.16d98e"}

The inject topic is not reflected in the output, I can thus not identify that this output belongs to "Light".

This is how the switch node is setup:

image
image507×691 5.81 KB

4

I can't think of any way to do that within the switch node, I think that unfortunately the best way is probably to save it in a flow context variable, then pick it up again after the switch. You could do that with a Change node setting it just before the switch, and another after it picking it up again.

5

Or with a join node and a couple of change node.

[{"id":"c1ee7660.0eee48","type":"change","z":"57675e72.26a0d8","name":"","rules":[{"t":"move","p":"payload","pt":"msg","to":"payload.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":590,"y":4380,"wires":[["7f335fe0.7fd38"]]},{"id":"a8755799.6a9c58","type":"ui_switch","z":"57675e72.26a0d8","name":"","label":"{{msg.label}}","tooltip":"","group":"8b5cde76.edd58","order":2,"width":0,"height":0,"passthru":false,"decouple":"false","topic":"","style":"","onvalue":"true","onvalueType":"bool","onicon":"","oncolor":"","offvalue":"false","offvalueType":"bool","officon":"","offcolor":"","x":300,"y":4380,"wires":[["c1ee7660.0eee48"]]},{"id":"7f335fe0.7fd38","type":"join","z":"57675e72.26a0d8","name":"","mode":"custom","build":"merged","property":"payload","propertyType":"msg","key":"topic","joiner":"\\n","joinerType":"str","accumulate":true,"timeout":"","count":"1","reduceRight":false,"reduceExp":"","reduceInit":"","reduceInitType":"","reduceFixup":"","x":370,"y":4440,"wires":[["adab6c12.45acd8"]]},{"id":"36097bde.040d7c","type":"inject","z":"57675e72.26a0d8","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"},{"p":"label","v":"device friendly name","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"this device","payload":"true","payloadType":"bool","x":130,"y":4380,"wires":[["a8755799.6a9c58","7f335fe0.7fd38"]]},{"id":"adab6c12.45acd8","type":"change","z":"57675e72.26a0d8","name":"","rules":[{"t":"move","p":"payload.value","pt":"msg","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":570,"y":4440,"wires":[["51b98dd9.43e6dc"]]},{"id":"51b98dd9.43e6dc","type":"debug","z":"57675e72.26a0d8","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":630,"y":4500,"wires":[]},{"id":"8b5cde76.edd58","type":"ui_group","z":"","name":"","tab":"8f03e639.85956","order":1,"disp":true,"width":"6","collapse":false},{"id":"8f03e639.85956","type":"ui_tab","z":"","name":"Home","icon":"dashboard","disabled":false,"hidden":false}]

But it would be nice if the switch node could pass on it's label and topic.

6

I was hoping that I just missed the obvious in how the switch works. I would prefer a cleaner solution like you said, maybe being able to use something like {{this.label}} in the topic for the output:

I'm still new here, not sure how to change this into a suggestion if that is possible.

7

You can submit an issue on the node-red github as a request.

You can clean the look up by making the switch and change nodes into a subflow.

8

I don't think the authorities want feature requests via github. They prefer requests here.
@Louis_Swart start a new thread with Feature Request in the title and describe it there.

9

I was under a different impression, i will take note, thank you.

10

I have checked to make sure I was not spreading Fake News. In the Contributing Guide it does say to raise feature requests here.

11

Consider it noted :slight_smile: but yes does need some thought / discussion.
The requested behaviour is that the node remembers the last incoming msg.topic and uses that if one is not set in the node config? However what is considered last incoming ? If the node is not in passthrough mode then should the input be ignored ? Should it only set it if the payload is a valid setting for the switch ?

12

No, otherwise there is no way of achieving the effect in non-passthrough mode

Good question. If the answer is No (ie always pickup topic), then this method could be useful if want to set the topic without changing the switch. The corollary would be that if incoming topic is undefined (for any message) then saved value should not be changed.

13

then any "random" msg with a topic could change it - which may not be a good thing further down the flow - surely only valid "inputs" should be honoured ?

14

I can't think of a use case where one would have random messages going into a switch, but likely that is because I just haven't thought of it. I can think of a use case where the path to the node to set the topic might be different to the path to set the switch state, in fact that would normally be the case I think. In that case it would be necessary to mix in the current state if one wanted to set the topic but not change the state.

15

The option to set the topic using {{msg.var}} or context would be helpful.

When passing the message or pressing the button, the topic should be passed by default even if blank, but not when undefined, along with the current state. The new message should set the last remembered topic, if topic is defined.

When set to "not pass message", the topic should be remembered.

16

well that is the crux - when pressing the button there is no topic (unless set in the config) - as there is no incoming msg , it's just the user - so it's creating a new msg, nothing is passed.

so this is another level entirely... :slight_smile: - the way to do this would be to make that field a typedinput field (like the on/off payloads currently are)... which the begs the question - what about all the other ui nodes that set topic... ? Should they all do the same ?

17

In that case it should see if a last stored topic is in memory and use that, if nothing send nothing. But you would know if that is even possible.

If it makes the user experience better and the nodes more dynamic, i would vote yes.

18

Um......

Big red flag to me.....

In the switch node.....

You haven't set the topic.

Dunno. Could it be that simple?

19

No, the requirement is to have a topic (or something) which can be changed at runtime, as explained in the first post of the thread.

20

Ah, sorry. My bad.