Perhaps not in your case, but it is possible that 100s of messages could be flowing through every second. Without slowing the whole system down it would be impossible to see the wires lighting up, indeed the changes could easily exceed the refresh rate of the monitor, and certainly the abilities of the human eye !
PS @mobamoba You really shouldn't be so defensive about your code, there hasn't been a piece of software ever written that could not be improved upon.
Personally I find every day is a school day and I'm more than happy to learn from others.
Please be assured that the members of the forum are genuinely trying to help you.
Sorry not to critique you as some of my flows get to look like this - but when they do i decide it is time to look at my logic and work out what is needed - thinking about the fact that in a year if i come back to this and try to debug it - it will be a nightmare.
It looks like you are extensively using the Within time node (i can not zoom in far enough on my laptop to confirm - i too use this node a lot - when i find more than two or so of them on a page - i move them to their own flow and then either link to them - or put in a GLobal Variable (which when i set a value also has a field in the object for WHAT flow or procedure set/changed the variable - thanks @TotallyInformation !) - i can then either using a link node or accessing the global variable use that on multiple flows with a simple switch node.
You have already alluded to the issue that you have - exceeding complexity in debugging - you are much better off breaking a large flow like this into either sections on the page and then grouping them and placing links on that page (i do not like this as most of my work is done on a laptop and it then involves a lot of scrolling up and down) - or moving the various sections into seperate flows - again with link nodes between them with meaningful names on the links - as an example i do this with all my MQTT nodes - they are all on one page (well two pages - one for sending and one for listening) and then link nodes in from all the pages that access them
My solution may not be perfect, but I'm just saying large flows exist and when they do the visual problems of NR's wiring really come to the fore and is there a solution to that beyond "do it all differently".
And I'm not defensive about my flow. I created this thread and tagged it specifically as a "feature request" and not as a help request. It's fine if people don't want the feature, but people also aren't addressing the issue: for large flows where they must be large for whatever reason, NR has a UI problem when it comes to debugging and can that be addressed. That's literally the sole reason I created this thread.
But if you take me at my word that my flow is written the way it is for a reason, i.e. that there must be this level of complexity to it and that I, as the person who wrote it and use it, organize and arrange my flows in a way that works for me, then I'm saying NR becomes very difficult to debug the larger a flow gets and, for users who either don't want to or for whatever reason simply can't break up their flows into more manageable pieces, the UI becomes very difficult and I'm looking for a solution to that.
Pretend for a minute that my flow absolutely must be exactly like the pic I uploaded and can't be revised or shrunk in any way: now what? I'm saying NR's UI should scale better to larger flows and have a visual means of seeing what's going on in those large flows because the current method - a bunch of debug nodes - really isn't functional at scale and I'm saying maybe there's another way even if the way I initially suggested isn't that.
Sadly, we seem to be talking at cross purposes. We recognise the complexities of complex visual programmes and the debugging of them. But we are saying that there are ways to break down the processing to help address that and that the breakdown doesn't change the logic, simply some of the structuring. And that this approach directly mirrors how good text-based programs are structured for exactly the same reasons.
By breaking the flows into structures, not only does debugging get a lot simpler but it is common to find ways to simplify existing logic that were not obvious previously. The reason we are passionate about sharing these ways is that many of us have gone through exactly the stage you are at, building something up over years and hitting a point where it is hard to manage/debug and going through several iterations of restructuring. I've gone through that several times over the decade+ I've been working with Node-RED. I don't think my home automation flows are that complex but they still amount to: Nodes:1,756, tabs:20, Node Types:84. It used to be even more but much processing has been boiled down and, in some cases, collections of nodes reduced to function node code instead (which is a different kind of optimisation of course).
I suspect though, that it may seem to you that we have been dismissive of your idea and I can only apologise for that. I believe it is simply that we got immediately what you were asking for, realised that it would be a very hard thing to do, would likely have serious performance implications and that it probably would not help most people. And so we moved on to trying to help in a slightly different way.
To reiterate, the problem you outline is very real but it isn't a Node-RED issue per-se, it is shared by all visual programming, visual diagramming and text-based programming. The way to help reduce the issue is to break things into smaller structures like groups and with link nodes and that is why Node-RED introduced those concepts some while ago. Those 2 features alone made a massive difference to all of us with complex flows to manage.
Thanks for that. If it's essentially an uncrackable problem with visual programming at this point, then that's the way that is and I hear that.
It's simply that NR is for non-coders by design, and its baseline organizational structure allows for flows such as mine without providing either a consequent - perhaps impossible - UI scaling but, and perhaps this is more a direction to go, nor does it really provide any obvious easy ways to reduce flow clutter, like the junction node is nice (though not useful in my particular case) but not available in the standard sidebar, and, sure link nodes and the like can be of use in some cases though OFC they can provide a different sort of visual issue with readability and tracing.
Here's an example of something that would be of use: when you click a node, all the wires going to and from it are automatically highlighted in a different color and are first-selectable, meaning when I click my mouse after clicking a selected node one of the highlighted node is chosen out of the clutter of other wires. I mean that would help.
I hear people don't like my flow but - and you'll have to take my word on this - it's necessary the way it is, not merely for its function but because of the way I work with it. We all approach data differently and, while for other people subflows and links may work, that doesn't work for me - everything's a tradeoff. For me, I break flows down by device (in this case an AC window unit that has a lot of conditions and subconditions for whether it goes on or off) so many of the suggestions here don't work for my workflow. Thus I was coming here with a feature request to improve debugging within the way I work rather than changing the way I work since I already know, from past experience, that that creates its own problems for me. I need to see it all in one place, and my feature request had to do with NR looking for a way within its UI to accommodate that.
You are certainly right that masses of debug nodes make the screen layout even more cluttered. The debug pane is a bit limited for analysis too, though you can apply some filtering.
Have you found the Node-red debugger useful? It does stuff like setting break points and stepping through the flow.
This might usefully be combined with highlighting "active" wires, though that has been requested before and rejected on the grounds (as I recall) of extra runtime processing and limited value if hundreds of messages are being processed per second.
You could for example use a CSS transition to make a wire glow for a moment. But the editor page is drawn when it changes, not when a message is processed.
There is Nrlint too which might be of interest.
I think Nick should have said shift click (that's what works for me anyway) but the more spaghettilike the flow, the more likely it is that everything gets highlighted.
I've used NR debugger and found it to be of some use though, again, it doesn't really scale or at any rate adding too many breakpoints, which is necessary in a large flow, created CPU drag - while I'm not using a PI, I'm running NR on an old laptop and I guess the debugger uses more CPU and eventually started creating drag while debugging.
Part of the reason why some other form of debugging, IMHO, is necessary is that NR also relies on a lot of community contributors for nodes and those have various degrees of upkeep and bugginess to hardly mention all the potential device bugginess, meaning pinning down whether the issue is something within the node programming, within the device, or within my own error in connecting various nodes and not getting the outcome I anticipated can be really difficult, and I was looking for a way to narrow down problems and one way to do that is for NR to visually represent itself in such a way that I can at least go, "Okay my flow is solid, thus the problem is either with a buggy community node or my device" which would be really helpful since I'm sure we've all hit buggy community nodes or simply not understood how to use them properly (I find readmes on those nodes can be very obtuse about formatting for inputs for example - is it an JSON input? a msg. input? something else? do I need spaces, colons or commas? quotes? etc.). I'm just looking for a way, with NR's mashup of core programmers, random contributors, and even more random devices with their various firmwares, to narrow down issues and suggesting there might be a way for NR's UI to help with that.
Great, thanks (though those wires don't stay highlighted once you select one and it would be great to have all the links to/from a node remain highlighted until the user no longer needs it). I think this part of what I mean; the UI may very well have all kinds of functions but they're buried.
you also have option(alt)-s , d to just select downstream nodes, and option-s, u to select upstream. They can all be re-assigned via the settings - keyboard panel.
Well if your flows require that level of complexity then i would say that Node Red is not the right tool for you and you would be better of moving to a traditional programming model
NRs model is not to enable complexity in flows but to simplify them as much as possible - hence the many many tools they provide to simplify flows - from link nodes, sub flows, custom nodes and the like.
If my system (which is 45 flows for my whole of house control) looked like that on any page then i would contemplate moving to a different envirionment
Sorry for digging this topic up if this is bad practice, but I was looking for the same feature than the OP did.
In my case, a flow might be quite simple but payloads go from switches to switches (each relying on variables conditions) to achieve AND conditions (when I learned using nodered 3-4 yeas ago, I was told it was "the way" to do it but I'd be happy to learn alternative ways to do so if there are):
After 3 switches with 2 options each, I'd need 6 debug nodes to visualize/check where my payload went through. On the other hand, changing the aspect of the wire in which the last payload went through would point me directly to a faulty condition.
I understand perfectly how multiple per seconds and frequently changing payloads would defeat the purpose of such a visualization, and the impact performance it would have if it were active by default on all nodes and wires of a flow. But maybe a keyboard shortcut used when selecting node sending the payload could trigger the visualization of where the latest payload went through the wires? On a high frequency flow, this feature wouldn't be used by the user, but I think it could be helpful for slower flows when debugging.
Thanks for your time reading this and answer/advice on how to debug visually or to organize such a flow if there's a better way!
While it just might be possible to adjust something in the properties of a node so that wires drawn from it can be styled differently to the rest, and you could redraw the editor page every 5 seconds, I think it would involve at least as many extra nodes as your extra debugs.
Your cascade of switch nodes seems to implement a chain of if/else decisions.
I think I would probably code these as a single function node with two outputs, returning either [null, msg] or [msg, null] according to the appropriate downstream node.
Where a faulty condition occurs, use a message property to indicate it, eg
msg.error = "bsocfull above threshold"
And a [single] debug node can display msg.error.
If you export your inject and switch nodes and post them here, I expect we can suggest other ways to code them.
I agree here. Visual programming is useful only while the visuals remain clear. Once the visuals start to get in the way (e.g. by filling the screen and getting ever more complex), its usefulness starts to decrease.
So learning a little JavaScript to translate your switch nodes into a function node or 2 would be sensible.
In addition to jbudd's recommendations, if necessary, you can make your error string into an array of strings if you need to check several things and accumulate a set of errors. Add a true/false flag so that you can easily choose the correct outcome.
Thanks all for your advices and solutions. As a non-developer, I was pretty happy with my cascading if/elses, I found the logic readable enough, and thought it would be better to go visual programming all the way but I understand it's maybe a bit too far
There is nothing intrinsically wrong with what you have done. If you find that the easiest way to build it and if it makes it easier for you to understand what it is doing when you find yourself modifying it some time in the future then, for you, that is the best way.
I think the main reason why people end up wanting a different way of handling this is due to the mouse and scroll behaviour in node-red. I think i have mentioned this before.
If you see the flows that people create in davinci resolve, unreal engine or comfyui - and don't 'complain' about these types of flows is because of the click to drag + scroll to zoom behaviour.
It gives users a true canvas to work with, where as you see with node-red, people tend to start from the left and want to keep their flows within their visual space of the canvas because navigating requires more interaction than they deem convenient - and as scrolling is (conveniently) available, they go downwards, instead of using the horizontal space (which requires holding a key).
I think it's laziness - folks don't abide by simple rules such as using straight lines and not having lines crossing each other (i.e. use link nodes instead), grouping stuff that does similar things. Find simple rules and abide by them and don't be afraid to change those rules - nothing that humans do is carved in stone. Use subflows and link nodes to move stuff out the main flow etc etc.
For example, this is a flow that I've been maintaining for the last three years or so:
Top left http inputs (API (top group) and frontend (bottom group)), bottom right HTML frontend, top right JSON APIs providing content for the frontend and bottom left git interaction - the whole thing is a interface to git repository storage. In the middle is a caching layer, middle right are some helper functionality reached by using link call nodes.
I clearly know what is going on, I understand it's purpose and can still alter it without being afraid everything will fall apart. But the flow wasn't born like that, it evolved:
The constant moving, grouping, straightening of flows is 50% of the work but its important to maintain an overview of what a flow is doing. If you don't do that, well then don't do visual coding because it will literally become spaghetti code without this "visual refactoring".
Sorry for being so harsh but why should it be simple? After all, surgery isn't simple. Lawyers don't seem to be making the law simple. So why should programming be "simple". After all, it's simple for those that understand it (as is the law) - be thankful not to be coding assembler code!
