Sometimes wiring becomes a mess because the wires follow the shortest path. Can you somehow change the route of the wires?
The "shape" of the individual bezier curves is defined inside the editor's javascript logic -- so you cannot directly change the route that each wire takes. However, you can keep your flows more tidy using one or more of these techniques:
-
Use the
link out-link inpair of nodes to route wires from the end of a flow (on the right side) back to another node (on the left side) of the next line. This creates a "virtual" wire that only appears when you select the link node at either end of the virtual wire. It also has the advantage of allowing wires to connect across tabs, which the normal wires do no allow. -
Use an intermediate "no-op" node, that only serves to force the wires on either side to go through a different path than a single wire would choose. I have not looked lately, but there may be a contributed node that does nothing -- however, most people just use a
changenode with no actual change rules defined, and the label collapsed. There are probably a dozen other nodes that could be used to pass through the msg unchanged, but I would avoid using afunctionnode that just returns the msg object, because of the overhead of passing the msg through the sandboxed vm. -
Use sub-flows to group parts of your overall flow's logic, which can be reused in other flows. In the main editor, these sub-flows show up as a single node, which can be opened and edited in a separate tab.
In my younger days, I developed a couple alternate wire routing functions, hoping to contribute them back to the main development team as pluggable/configurable options. But there was not much interest in providing different looks to the editor layout at that time. Now that vertical layouts have been requested, it may be a good time to see about resurrecting that work... hmmm.
7 Likes
I have simple rule set:
If there is wire, crossed by more than 1 wires, then it is "work in progress".
If there is wire, crossed by 1 wire, then it is luck of clear thinking (equals to being lazy).
If there is wire between nodes but outer ends are not connected to anything and all systems are up and running perfectly, then it is well done cleanup.
5 Likes
Oh, and I should have added a 4th option:
- use MQTT and the
msg.topicto route the output of one part of your flow to the input of another part
Julian's heating system reminded me of this -- and since the MQTT broker has the ability to persist the last published msg, it is an excellent way to have your flows reconnect at startup, and pick up the last msg in order to re-initialize anything that relies on stored state (e.g. dashboards, light switches, etc)
3 Likes
Agreed, working fine for a Node-RED restart. Just be aware that to also "survive" a reboot, the MQTT broker has to be running on a different computer
If the topics are Retained then the broker can be running on the same computer and the retained values will be delivered when node red connects to the broker after a reboot, for example. That is how all my systems work.
2 Likes
Aha, ok. So means the broker keeps the (retained) data persistent in some way. I did not know, thank you!
As usual it depends. Again you have to configure Mqtt to persist data to storage rather than memory if you want it to survive a complete power cycle reboot.
2 Likes
And I have understood, this is not the default setting for mosquitto?
On Raspbian and Ubuntu (at least) it is the default, I believe. Looking at /etc/mosquitto/mosquitto.conf I see
persistence true
persistence_location /var/lib/mosquitto/
2 Likes
OK then fine, thanks!!!
... the default for other mqtt brokers may be different...
shrickus, can you supply a pointer to "Julian's heating system"? Thanks.
I think he might mean this: New home dashboard using uibuilder and bootstrap-vue - Share Your Projects - Node-RED Forum
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
