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
