I am using Node Red for a handful of different purposes, but it is primarily a SmartHome platform for me. I am doing some things that while not groundbreaking are somewhat complex. For example, I have built synchronized inputs (and sometimes outputs) across 11-12 different control interfaces. While some of these flows can be generalized and put into sub-flows, many of them require just enough tweaking between devices to require a separate flow per device. Here is a mostly completed set for controlling a RGBW bulb that is connected to Zigbee2MQTT:
This covers on/off, brightness and color temp. Actual colors is still a work in progress.
Knowing that I am doing this for 40-50 devices, I am finding that it is hard to group flows in a way that makes it intuitive to find one when I want to either use it as the basis for a new device or tweak the existing one.
I think the main options for organization are either groups or tabs. Can anyone suggest a good way of organizing flows to make them easy to find?
I am wondering if the right answer is to trying to get node red to follow the lead of most web browsers and implement some collapsible/expandable tab group feature.
Alternatively, I am thinking maybe I should just give up on the portion of the tab name displayed being meaningful and switch to very descriptive tab names and then focus on using the List Flows button/shortcut to search the tabs.
I'm also still looking for a good way to organise groups and nodes.
If you have 40-50 similar devices isnt it an option to make one subflow and use it 40 times?
I have also some similar devices and I was able to organise 90% of nodes into 1 subflow
Unfortunately, because I am doing so many interactions (Alexa, Homekit, Home Assistant, Google Home, etc) getting all of the information into and out of a subflow would almost be as complex as just copying the flows and tweaking for the different device.
well, then you will run into problems, I guess. Imaging if you want to make changes to your nodes? you need to adjust 40 of them, instead of one subflow, to apply changes everywhere. I think the effort to create a working subflow is worth the time. But its only my "nooby" opinion, because I dont have so much exp with nodered
Much as I'm a fan of Node-RED and using it for my own home control system, this is unfortunately one of the disadvantages of visual programming methods as compared to more traditional coding. It's very difficult to scale up, and handling large, complex systems is a real test of ingenuity.
I've worked with Scratch at one end of the scale, and LabVIEW at the other, and finding ways to achieve complexity without a "rats nest" is hard. I'd echo the subflow suggestion, looking at extracting common functionality where possible, even if it needs a bit of configuration to be reused in multiple instances.
To be honest, if I was looking at a system like yours with 40 - 50 devices, I'd be inclined to develop an application in C++ or C# and use a more structured approach which would allow for better modularisation and parameterisation.
I had a similar problem to you. The way I "fixed" it was to take one of the flows and break it down. Make parts generic by specifying the specific item in a msg.topic or other property and have your code flow and split on that.
I now just need to duplicate Enable and Disable buttons and everything else is handled in code or split nodes. Liberal use of Link In/Link Out nodes also helps.
Publish your code and I am sure someone (me included) will have a go at reducing it - if it's possible.
Belay that! I just had another look at my target system design, and I'll probably be looking at well over 60 devices of various kinds once it's fully implemented. However, even in the small scale test setup I'm developing the complexity is reduced by using common flows and subflows for groups of similar devices.
I'm also using MQTT-style messages (a bit like the suggestion from @MyRandomThoughts above) and flow functionality which treats e.g. all the environmental sensors identically for most processing, only separating them when absolutely necessary.
I can't see detail in the screenshot you posted, but the three grouped flows look very similar, and may share enough commonality that they could be combined and/or turned into subflows.
I'm not nearly close to the complexity mentioned above.
My approach to simplify the logic/functionality part of the flows is to have a common data structure. I invented my own. Today I would probably choose the homie convention, but I'm too lazy to change everything now.
That way I had to write flows for each device type to transform the data into the defined structure and safe it (send to MQTT, influxdb, global context). But this I do once per device type, no need to touch this ever again. This solves the scaling issue on this part.
The control logic is another issue. Here it gets messy very quickly.
If you separate the "actions" (on, off, etc) from the different command structures you can store the command structures in a database and have a single set of flows call up the unique command structures based solely upon a device name/type combo.
So if you feed your flow with {deviceName: "MyDeviceName", deviceType: "MyDeviceType", "deviceCmd": "on"} Then you can look up commands needed to take the "on" action for the device name and device type combination and then execute the results of the database result.
There a certainly some good suggestions on ways to potentially simplify some of the duplication in flows, but I guess there really aren’t any great solutions for organization that is easy to find a flow across many tabs.
I am embarrassed to say that I missed the obvious answer to my own question. The Flows hierarchy inside the info tab was really what I was looking for. I had never used it before even though it has been there as long as I have been using Node Red.
So now I am switching to a hierarchy of flows with longer meaningful names. In the past I had avoided this as I had felt limited by the viewable space on the tabs at the top of the workspace. Then I am grouping items within a flow in a meaningful way and again not constraining myself to artificially short group names. Finally, I love that the info tab hierarchy handles nested groups in just the way I would want..
My only quibble is that the search box in the info tab and in general only searches on exact strings. So I have a group named "Living Room Lamps", I can search for "Living", "Living Room Lamps", etc, but I can't search for "Living Lamps". It makes sense that node red isn't focused on search, but I have been spoiled by all the tricks that can be done through google, etc by those that are search focused.
The combination of flows + groups hierarchy and as is search solves 99.9% of my needs.
I'm discovering this right along with you. I never thought to use the info tab as my primary navigation. (also, did you know you can reorder the sidebar icons by dragging them?).
When you say groups though, are you talking about the node-grouping?
If there's a way to group flows I'd like to know! I see there's the ability to select multiple in the tab view but doesn't appear you can group them in the same way.
By this I mean selecting nodes ant then using the Groups option:
I wouldn't mind having such a capability (I don't think it exists), but I find most of my flows once I have built them and arranged them for maximum later legibility can then be put into a group and multiple groups on a single tab (aka flow) gives me the organization I want. Especially if there are a bunch of really small flows (in the sense of connected group of nodes, not tab), then group them individually, them group the groups and then put the groups of groups onto a tab (aka flow).
One other key that I didn't mention, but regular users of the info tab probably all ready know is when you group flows and groups into a hierarchy like I am doing, then as you drill down into it, there is a magnifying glass on the left hand side that the hover over text says "Find in workspace". This jumps you right to that flow, group, sub-group or node that you are looking for.
