Hi,
so I recently got HA and node-red working together and I’m having a lot of fun messing around with the flows. I’ve recreated all of my automations from HA in NR and in doing so created a tangled monster of a flow for my bedroom and before I start tinkering with it more I’d like to know whether flow like this is “ok” or if it is best practice to have the flows for different things “linear” even though it means multiple copies of the same node. Or, in the end, does it matter at all?
Hm so in terms of Node RED functionality and performance, I don’t believe there’s really a downside either way. Everything is asynchronous execution so whether you copy the same node 10 times or ensure all 10 lines go into exactly the same node I don’t believe there’s a difference. Although if it’s a piece of logic you’re currently working on then that is obviously very different. For instance if there’s a conditional I’m actively working on and trying to figure out the right lower bound for and its used in a lot of places then I will definitely work on de-duping that, making the same change 10 times would be quite frustrating.
The listener nodes on the left edge are the only ones where I personally try and make an effort to de-dupe in general. I haven’t seen anyone show a performance degradation in doing so I just personally prefer to refactor common listener nodes to a shared location. I then point that listener into a link out node and drop a link in on the left edge any time a flow should be started by that listener. The link nodes in general can be a great tool to reduce complexity. Don’t want to go overboard with them but if my choice is between having my flow loop back on itself or criss-cross tons of lines I prefer to use link nodes with a clear label on either end.
I think the main point of consideration here is whether you find your flows easy to understand, maintain and develop on. I know personally when I first started in Node RED my initial set of automations looked very similar to yours. Overtime though I found the complicated dependencies made it difficult to debug and add to so I ended up refactoring. Once I started carving my flows up into reusable subflows I found it a lot easier to maintain and add to.
Another tool I’ve personally found particularly useful is this components package. They aren’t too different from subflows except they allow you to define inputs and map parts of the message to those inputs so you can have a clear interface. Subflows also have inputs but they don’t allow you to map the message to those, they’re more environmental variables. I’ve found each is useful in different situations.
1 Like
Thanks for the great advice I’ll have a look at the options, I think the subflows and link in and link out nodes should help me. Originally I used HA scenes to set up lights so it was just listener -> activate scene node -> some other node mostly, but after adding more lights from more vendors some lights didn’t properly change brightness / color between certain scenes, whereas having them directly activated via node red seems to work. Perhaps I could set the light configurations as separate subflows and link to those to reduce the clutter.
1 Like
Your flow looks difficult to maintain, and hard to track down why a light just turned off (for example).
I would suggest decoupling events from the actions you want to happen using MQTT. Then you can, for example, have a service that turns light(s) off or on at any brightness and log the action along with the reason. So if a light goes off, you can look in your log and see it was because “leaving home” fired.
I’ve also found it useful to have separate NR tabs for each room, plus other service tabs for handling groups of entities like lights, switches, heaters, etc. It doesn’t take long to run out of vertical real estate in the editor.
I agree, log actions in your HA logbook, so you will be able to trace back why some things happened.
In general, I try to keep the simple flows in HA (say events that have 2 triggers and/or conditions) and group them in different yaml files. These are also easier to keep track of changes.
Once you go to NR for the more advanced flows, I often model them as statemachines.
I ended up going with the components as I prefer having everything on 1 page in node red (and I couldn’t really grasp how the subflows work), so now I have this for the “main” flow
and the “scenes” separated like this with the use of components:
I find it much clearer now, thanks for suggesting components again! This pretty much stretches my “technical” abilities already, I just like node red because the visual “flows” make sense to me whereas yaml and ha gui automation does not or does not meet my needs, but I appreciate the further suggestions too.
1 Like
So over weekend I finally managed to get the subflows working, but I’m running into an issue that the nodes that are inside subflow don’t display any info under them so I’ve no idea if/when they were activated. They all work, just don’t show the info text under as if they would display if they were on main page.
Any way to enable this?
No, there is no way. There can be multiple instances of that subflow. Add a call service to save something in the logbook (for example) and add it right before you enter the subflow, that will have the time displayed.
I guess I’m getting in way over my head 
I don;t get why everyone suggest me to log stuff into HA logbook honestly, I do not see any use for that. Don’t mean to be rude, just trying to wrap my head around it.
As in I don’t really care what the information going through the node is, I only care about activating the node and showing me under the node when it done so as the only nodes I use are nodes like turn light off/on set color on light etc, for those it’s irrelevant what the message payload is.
I think I’ll go back to the components as those did that though I’ll have to keep it all on 1 page I guess (which I said I prefer, but I didn;t know the page is so short, I thought it’s infinite 
).
You will need it once you are troubleshooting. The node will only show the last execution time, which will be useless if it executes often.
Just sharing my best practices 
Also, your flows seem to be quite easy. Why not do it just in HA with scenes?
I prefer this visual approach, I originally had it as HA scenes, but kept running into issues with brigthness / colors not being applied correctly between certain scene changes.