Now, there's a global variable, which indicates a condition to execute the functionality in this node. Currently, I have no better idea (or knowledge) to do this that way:
I don't think there is anything particularly wrong with your approach as is, but one alternative would be to use the simple gate from node-red-contrib-simple-gate. Then instead of setting the global variable to true, send an open command to the gates and when false send the close command.
Of course, you still have as many nodes as using the change, but it might be more obvious in this way to know what is controlling the gates.
Valid point, @Colin. However, the use case is home automation, with 100+ nodes.
What would be best practice to indicate "residents at home", "heating/cooling period" and so forth?
There are many nodes that shall behave differently depending on the situation.
I am not sure what that has to do with it. The node-red server that manages my home has 845 nodes, and I don't think I use any global or flow context variables.
Any values that map onto things in the real world, such as those you mention, live in Retained topics in MQTT. The big advantages of that over global variables are that any time one of them changes then all interested flows get informed immediately, and on startup all current values get injected into the flows automatically.
While I do understand the advantage you are mentioning, I don't see a remarkable difference between retained topics and global variables though.
There's a repository of retained values or messages. One message is retained per topic - one global variable containing a value. A message, published on that topic will replace the previous message, like the variable would change its value.
The advantages I mentioned are the remarkable difference. In addition is the fact that MQTT can be cross server, allowing the automation (and dashboards) to be easily distributed across multiple devices, including devices that are not even running node-red.