Hi, I am using Node-RED for home automation, and I have two flows for controlling my rolling shutters: one for "normal" days (opening the shutters in the morning, closing them in the evening), and another one for "hot" days (leaving them partly closed when the sun is shining on them, and generally implementing a different scheme of actions). There are several actions in each flow, and these are triggered by independent nodes (timers and sun events). There is no single connection which could be switched.
Currently I have to use the NR configuration interface to manually disable one flow and enable the other one when the weather situation changes. I'd like to have a simple user interface (or even an automatic solution using a weather forecast) to switch between the two flows. Any ideas? Perhaps a bit of JS or a 3rd party module? I searched a bit but could not find anything.
I am aware that this kind of self-manipulation can bring unexpected complexity if being misused (aka self-modifying code), but hey… 
The whole point of node-red is handling (read: route) messages based on their content values.
if temp > bla and time is this, then this flow else that flow. This sounds like a simple "problem" but I might misunderstand your problem.
example; I have a sun screen. node-red reads a nearby weather station for rain detection, wind meter. In parallel it reads my own weather station for temperature and it reads a lux meter for the brightness. If there is rain, screen open. If there is wind > 20ms screen open. If none of those, check the brightness between "sun noon" and sunset, close screen, else open.
If you haven't tried yet the https://flows.nodered.org/node/node-red-contrib-blindcontroller you probably should. I think most of your requirements are covered.
First, thank you for your replies. 
@hotNipi: this may well solve most of my problems regarding shutters, in fact it even seems far more elaborated than I'd thought I needed. But my question is also a general one, the rolling shutters being only one application.
@bakman2: for a more descriptive example, please have a look at my current setup,
From left to right, there are the triggers (fixed times and sun events, plus manual buttons), shutter positions put in as payload, devices put in as topic, and finally all is merged and sent via MQTT. Since the two flows are independent, each one can be edited separately.
My alternative implementation would probably be one single, long JavaScript function handling all actions, surrounded by a "if (global.get("summerMode")) {} else {}" construct, but that would lack NR's elegance…
…and that might be a solution. Having both flow tabs enabled, but throwing away all generated messages just before they leave the flow if it is non-active. Only disadvantage is that the server has to be running both of them, resulting in a somewhat greater workload.
Well you can place switch node to check things like "summerMode" right after any trigger node to reduce unnecessary computations.
but that would lack NR's elegance…
but disabling and enabling flows is elegant ? 
it defeats the purpose.
Your example of if (global.get("summerMode")) {} else {} -> you can set global variables with a change node, you can use a switch based on the global var.
Node.js (thus Node-RED) is event driven. So you can have lots of “flows” that just sit there until triggered. So no extra workload until they need to do something.
Yes, of course. In the home automation case here, there are only a few events triggered per day, so no real workload. I understand Node-RED is capable of handling much, much more workload
Nevertheless, I think it would be advantageous for certain settings to e.g. have a simple JS statement for enabling/disabling a complete flow, similar to setting a (global/local) state variable. I just have no idea what implications this might have for NR's runtime organisation as normally enabling/disabling a flow in the editor requires deploying.
Yes it will always require deploying. Much better to “disable” it by filtering out any triggers that fire that part of the flow. If hot set a global variable, then make that one of the decision variables for each flow.
I solve that in my setup by setting a couple global variables, then allow (sub)flows to be run through a switch node that checks what the current condition of that variable is before running the flow. That switch sits at the start, immediately behind anything that triggers it.
For example, I have a "guest mode" variable where in the default situation this is off. But if I have people over, rather than having the automation do semi-random things that only I know about, for example ask me (TTS over a speaker) how I'm doing with pain or giving suggestions for things to eat/pills to take. An alternative flow is started instead when guest mode is on, where these things still happen but rather than asking notifications will be send to my phone for me to respond to, whether normally I would just answer out loud as a Snips conversation is started.
For me, that works just fine. Yeah it's a bit verbose with all those flows visible in the editor, but with good naming both flows and subflows it does not hinder me.
2 Likes
