I have many similar devices (eWeLink/xxxxxx) and at some point the switch is becoming ... large...
I created a json file (from an excel file that contains the information about a device.
Searching through the flow.json, a "unique label" could provide the unique ID of the node.
I would like to know if I can rely on the fact the id of a node is unique as long as it is not deleted and that it is the same from one deployment to an other.
Is there a way to send this id'ed node ( here .. .ui_switch) a specific message coming from a function node.
This would greatly simplify and cleanup the flow while avoiding the copying of the identifiers in many places. Maybe there is a better way to do this...
Yes - the ID of a node doesn't change
If you mean "can a Function node send a message directly to any node based on its id?" the answer is no - it can only send messages to nodes it is wired to.
thanks for your prompt answer.
unfortunately, cannot use the id to send to a specific node.
would it be a valid suggestion ??
if I knew more about the internals, I would probably not have asked this question , right ??
No - there are no plans to allow a Function node to send to any node it isn't wired to.
It'd be a kludge, but couldn't you send a message from a function node to another node via GLOBAL context and make up your own ID system as part of it?
I'm not seeing why you cant just wire up an output and let the message topic or other payload field specify the intended destination.
it is just that the process with these devices (sonoff mini) is a bit involved and I have a lot, a lot of them.. .
I currently use simple "switch" to access the the different UI_switches... which is OK.
If this was possible, I would avoid the big switches and many links.
thanks for grading my question as a kludge... lol..
I kind of agree.
Generally, using an intermediary such as an MQTT broker gets the job done.
There are lots of possible ways to send messages between nodes, I wrote a proof of concept myself for an event-based approach. But the point is that doing these kind of work-arounds makes Node-RED more complex and less discoverable. If messages can warp between nodes using non-obvious mechanisms, it becomes almost impossible for someone to work out what is happening.
To be clear, you are talking about custom nodes that do internal routing between themselves. This does not apply to the Function node as asked in the original question. I wouldn't want your reply to be misinterpreted to mean the Function node could do something it cannot.
Yes.. in fact, using MQTT could do what I want, but it is not the purpose of MQTT as such.
An approach (simili-MQTT- internal messaging and dispatching system) like your proof of concept would be interesting to me.
Do you still have it ? and as a shareable custom node ?
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.