I am using quite a number of global variables to keep track of statusses, which I use in various flows to update devices/dashboard. I know you can connect flows together, but I find it "messy" and hard to keep track.
What I do now is use an inject node every x seconds and read the single variable.
Is there a simple way to read all global variables as the context data also knows all variables ?
Wouldn't it be a good idea have (listener) node that exposes all (global) variables and emits its data upon changes ? This could make things quite efficient and could reduce flow management quite a bit. Or am I using NR in the wrong way ?
It's true that we really missing some sort of "best practices" advises section with scaling an perspective topics in it. If projects start to grow, sooner or later you can hit some limits or just lose control over it if this kind of advises are not followed.
Flow based programming feels a quite bit different from what we are used to deal with (if any of course). Somehow those little things you'll need can happen too easy just by wiring known things together and by creating one easy solution next to other, the moment of that hit might be unexpected and painful.
I am creating new version of my home automation. It's just because of with first one I lost scalability. Just adding one new device turned out of 3 days of fixing. No good. But it was a great learning curve.
New version goes on complete different path. I grouped logical similarities, everyone to different flow (tab).
Something like: object creation, incoming data listeners, time based injectors, control logic, outgoing data senders, dashboard widgets (separated for every dashboard tab) and so on. So I can't lose track if something does not behave correctly because of if I can figure out the potential reason of failure, I can find the source just by failure nature. And there is no need to go wire by wire to find the source of issue.
Of course this kind of approach might be good for my project and may be for some others too but definitely not for all of them. Every project is unique. So it takes a good time of planning and experimenting before it is reasonable enough to start to make it.
But back to my point - "best practices" in this direction would be really nice.
If you are using a large number of global variables then that is the problem that you should address. Look at each one and see if instead of keeping a global you can instead pass the value to the nodes that need it by using messages, which is what node-red is all about. Then there is no need for a listener as whenever the value changes the nodes that need to know will get a message.
It is always possible to do away with globals (except see below), just occasionally it is much more convenient to use them, and that is the time to do so, in my (admittedly extreme) opinion.
One time when they may be useful is for remembering system state over node-red restart, when the recently added feature of saving context in a file can be used. However I much prefer to use MQTT with Retained topics for this.
Hi @hotNipi - if you want to start a discussion about best practices, please start your own topic to do so. This topic is regarding a specific feature request and it isn't fair to derail it without any attempt to address the original question.
@bakman2 the very short answer is we've made the conscious choice not to make context a mini publish/subscribe system within the runtime. To do so would greatly complicate things from an implementors standpoint and actively get in the way of some of the goals for context around distributed systems.
I would love a context listener node! Maybe it could be integrated in the Watch node instead of having yet another node?
@bakman2 In the meantime, instead of having lots of global variables of type string or boolean, you could replace those multiple global variables with 1 or few global variable objects instead. I find that it usually reduces the amount of nodes and keeps things neater.
I am not sure if I see a difference in an global object with various variables or just global variables ?
@knolleary I am a simple user and think in simple terms, there is probably more stuff to it than I can grasp. I was not aiming at a mqtt idea, but indeed you might end up with something like it.
I can use an inject node every second with a function that gets all global variables, but this can not be the idea behind NR.
@Colin I understand what you are saying, but that was my main issue; it can become messy, or at least if you are not aware of a better approach (like me): how to organize flows.
Should I organize my flows in such a way that each flow does everything from A-Z for 1 particular device and only expose the necessary to variables ?
Just like @hotNipi stated, it requires a different mindset. I love NR, probably the best software I have ever used, but certain ideas I have to get used to.
Remember that you can pass message between flow tabs by using the link node, however I find that I rarely need to do this. The principle technique I use that simplifies flows is to write pretty much anything that has meaning in the real world out to MQTT. So for example I have a number of 1 Wire temperature sensors, so I have a tab with nodes that read the sensors at the required rate and write the temperatures out to MQTT with topics such as home/kitchen/temperature. Then on the dashboard tab that displays the current state I just have to use an MQTT In node configured to pick up home/kitchen/temperature and it is always available (it is a Retained Topic so the latest value is always immediately available). Similarly I have a tab that has the temperature control for the kitchen, again it picks it up using an MQTT In node. The control nodes determine the current heat power required and send that to MQTT topic home/kitchen/heatpower. The on yet another tab is the logic that actually drives the heater based on the required power. By using these techniques the individual flow tabs do not get too complex. Another advantage of using MQTT is that I can easily pick up values from one of my node red systems for use in another. I have a number of Pis handling different tasks around the house and a central one that handles the main user interface, accessing and setting values for the distributed systems via MQTT.
