Is it possible for a custom node to react immediately to a change in a flow/global variable? Is there an event emitted when a function node executes something like global.set("global","value") or when a change node modifies a variable?
If you want notification when something like that changes you may be better off using MQTT rather than global variables.
... or also wire an output from the function node to the custom node. If it's on a different tab use a pair of link nodes. That is what the wires are for.
No, there is no event that is triggered when a variable changes. Also, just because a function node rewrites a variable doesn't mean that it has changed! So this partly depends on what you are trying to achieve.
Generally, if I want to check if something has been updated (not necessarily changed), I will add a timestamp when it is written. Then I can check the timestamp - but that still means that I have to read it again.
MQTT would work but doesn't really help unless you make sure that you don't update the data unless it has actually changed. If you do that, then MQTT is the best approach.
@TotallyInformation, I would settle for rewrite, changed or not.
@Colin and @dceejay, yes of course, I'm using both mqtt and ordinary message passing, but I have a rather special (peculiar?) situation where a large of number of nodes might need to be aware of a change in a variable, and it gets to be messy to wire up dozens of link or mqtt nodes. If the answer is that no such event is available, I can live with that.
well you can have one link out node and loads of link in nodes connected to it to help keep the mess under control
1 Like
Or one publisher and loads of subscribers 
. Got it.
Hello good people,
some years later and i'm having the same problem but cant find any other thread on this. Is there any developement in this? Is it still impossible to broadcast / subscribe to commands withing NR without going through an external MQTT broker or making a mess with "invisible" wires aka link-nodes? This seems like the most basic function, I cant believe it doesn't exist!
Thank you for this information, very interesting. A lot easier for sure than using an external broker, but still unnecessarily complicated it seems - any idea why this is not built into NR as a basic function?
The "Action" Nodes do something so very similar, yet not quite that.
I would assume it's because NR is based on flow based programming. Stuff triggering in the background without no indicating wires would go against the principle.
I've wished a feature like this on some occasions so I understand the "need" but I also understand the principle why something like that doesn't exist. With that said I would likely use them if some "context watcher" nodes existed.
2 Likes
I'd suspect that its not been asked for very much - also the workarounds are easy - also state changes being sent from one node to another node without something in-between, is pretty much against the whole Node-RED philosophy
(Last bit just my opinion) 
[edit] But I note that @ristomatti seems to agree with me[/edit]
1 Like
The thing about Node-RED Philosophy is indeed a good point here i guess. However variables and the linking of action-nodes are also not quite "visible", so one could ague NR has kinda left the realm of purely visible connections a while ago anyway 
Workarounds are actually not quite as easy it seems to me - but i'll give Aedes a try!
One workaround could be simply polling for changes. A parameterized subflow could wrap a function node that would periodically check if the given flow/global property has changed, and send the new value if it has.
I don't like polling approach as an idea but it could work if thought pragmatically.
Yeah i have thought about this too and even tried it in one instance - it however generates a lot of unnecessary "background noise" processing-wise so i never did it on a larger scale.
I doubt any performance hit could be noticed if polled on a reasonable interval. Can't say what reasonable would be but maybe something between 100-1000ms. I suppose for most purposes that latency would not be an issue.
Hm. Yeah maybe you are right, i just didnt like the nervousness of the debug log, but it probably doesnt stress out an Rpi4 as much. Might give it another go, but since i just managed to get Aedes MQTT up and running within less than 5 minutes i guess MQTT is indeed the easiest option!
Installing mosquitto is just as quick.
sudo apt install mosquitto
and you are up and running.
2 Likes
Another advantage of mosquito is that if you keep it running in the background it will always be ready when Node-RED starts (or restarts). If you use a broker implemented as a contributed node, there can be timing issues that prevent new or retained messages from being sent when you need them. Of course, there are workarounds, but why bother?
I see, thank you for the clarification. I will switch to mosquitto then!
