Hi all,
My project is starting to get messy with a lot of flows. Any tips on how to keep things clean and organized in Node-RED?
Thanks!
A few suggestions
- Split them up into tabs with names that explain the purpose
- If you have lots of groups of repeated nodes, look at using subflows to make a single templated versoin
- if flows are running off the screen you can drag them to stacked in narrower columns to make them easier to read without scrolling
- Link nodes can also help, but you need to be careful as it can also make things a little harder to follow.
1 Like
Welcome to the forum @Sanders
- Group nodes together which have an identifiable common function.
- Use group labels and fill colours.
- Move groups onto their own flow tab and call with link nodes.
- Link nodes can be used within a tab too, avoiding visible crossed wires.
- Avoid wires running behind nodes.
- Generally aim for the flow to run left to right, top to bottom.
- It might help if you reduce some nodes to a small square in the editor by hiding the node's label.
ps There is a free online course in the newly established Node-red Academy "Node-red Advanced" which looks like it covers managing your flows' appearances
I separate the flow tabs by function, Process I/O, Control Logic, and UI
So, for example, for my home automation, I have tabs for the I/O, which is temperature sensors, relay outputs, etc and send the values to meaningful topics in MQTT, so I have topic home/bedroom/temperature for example, and for the required power output I have home/bedroom/power.
Then I have tabs containing the control logic, time scheduling and so on, which get and send all their data via MQTT.
Finally there are tabs containing the dashboard nodes for the user interface. Again, these communicate with the rest of the system using MQTT.
One advantage of using this sort of design is that if, for example, you decide to change the type of sensor reading the temperature then that only affects that one flow and has little or no effect on the logic and GUI.
Also, you could move the dashboard flows to node-red running on a different computer in your network and only have to change the MQTT configuration so that the dashboard flows get their data from the correct machine.
In the jargon, this is known as using a Unified Name Space or UNS.
This is a problem with all visual programming tools to be honest.
My personal opinion is that it is worth reviewing distinct chunks of your flows to see whether it is worth compressing multiple nodes into some JavaScript code in a function node. Of course, this somewhat depends on your level of JavaScript knowledge. There might be other ways to compress multiple nodes into a smaller number of specialist nodes as well.
It is also, of course, worth reviewing you flows to see if any can be simplified. Are there areas of your flows that have grown in an evolutionary fashion? Are there areas of your flows that have evolved as your knowledge of Node-RED has improved?
Other than that, reducing spaghetti is important.
(Oops - I didn't manage to post this when I wrote it yesterday!)
Hi
I find this challenging as well. And appreciate the hints. One thing I'm also looking for is any advice on how to manage individual flows (ie in a tab) with GitHub using the project feature. I'd like to be able to control and share the configuration of individual flows.
Cheers, Mike
Another trick with link nodes is to name them too.
This helps you remember where they are going/what they are used for.
Also, if they are staying on the same TAB, make them small.
That is:
to name it, but HIDE the name.
If it goes to another TAB, leave it showing the name.
If both, leave it as default.
To me, that helps me see when a LINK is staying local or going to another tab.
COMMENT nodes are also handy to put in GROUPS to explain what the group does.
Document what is expected at the input message structure and the output structures too.
I'm guilty of NOT doing that and have cursed myself many times.
So I would strongly suggest you try to get into the habit of doing it.
All the best.
P.S.
(Sorry)
DEBUG nodes: Name them but do NOT leave too many active by default.
(Long story behind that. I won't bore you with the details. But it could cause headaches if you leave them active)
1 Like
AS I use so many link nodes in more complex flows, I always try to name them. I often turn on the name as well. Names should be descriptive as well.
Don't forget that groups also have labels, I always use these.
Background colours are also useful though I always make them partially transparent.
(Sorry)
But the TITLE is somewhat limited.
The COMMENT node allows you to enter a lot of information as I explained in the post.
Though I do agree that TITLES are also handy.
Don't forget that you can use " \n " (with spaces around) to generate a new line. This is the same as a comment node. You also have a full markdown notes section. So really the features in the group are no different to a comment node. Other than less ability to reposition.
1 Like
Yes, but if you want to write the in/out structure of messages..... A comment node would be better.
Ok, I have (again) shown my ignorance in that area.
Just the comment node seems more..... intuitive that there is stuff to be read.
Without a doubt, both are useful. I like group titles because of their neatness. I use comment nodes - as you say - where you need to position a note next to something specific.
And just to prove the point. 
Oh, side note on the comment node.
We've taken on a bit of a discussion on titles vs comment nodes.
I mentioned them and now - in retrospect - admit I missed a point.
If I use a comment node and just have a title, well: all well and good.
But if I want to add extra/more stuff in the text area, in the name of the comment node I add a * at the end of the name.
To me: this indicates there is more to be read in that node.
Example:
(very basic one)
[{"id":"b4ce0bb76b5c7574","type":"comment","z":"b8111f78dd481d81","name":"Example 1","info":"","x":770,"y":750,"wires":[]},{"id":"1289fd11a74aaede","type":"comment","z":"b8111f78dd481d81","name":"Example 2 *","info":"This is extra text that isn't shown,\nbut may be of interest or importance\n","x":970,"y":750,"wires":[]}]
1 Like
If using a lot of descriptions, you might find the doc-red plugin useful as it provides visual indicators.
1 Like
