Not sure if demand is there, but I'd like to request some sort of visual indicator (perhaps a colored border indicator like the debug node gets if you hover over one of its messages in the debug window) to let users know if a node on the canvas is currently processing a message. This would make it easier to determine whether a lack of output is a result of a flow with no actual output, or whether we're just being impatient waiting for a particularly taxing message.
We’re not going to do this for most nodes as the comma overhead really does build up if you have lots of nodes and a very high message rate.
Some nodes like the http request node and exec node do show an indicator while processing.
Which particular node(s) are you thinking sbout
The ones in particular that I was using where this came to mind was a CSV>split>switch>join chain. Before I thought better of it, I was feeding it a way too large CSV file (the resulting filtered array contains around 400,000 objects, each with 4 properties.) I cut it to something a little more manageable for prototyping (the only time any visual indicator would be a valid ask, because I have drank and fully digested the "the editor is not a dashboard" kool-aid) but it still made my brain itch in a very "I wonder if anyone else would have use for that too" sort of way.
That all said, I don't know enough about what's going on under the hood to know if it's a reasonable suggestion or something totally infeasible.
1 Like
Please note that I mean the following not seriously:
One way to solve this would be the following:
You have a button somewhere to enable "process" indicators on a flow tab basis.
Then on this flow only every wire would flash in a color if a message is passed through.
It would definitely look cool 
If it is turned off, no performance impact
For csv - you can use the file in node and set it to send a msg per line. This effectively reads the file as a stream and does a split (and adds the relevant msg.parts) - so it doesn't have to wait to load the complete file.
Maybe cool - once. There was a reason the <blink> tag was deprecated. Having lived through it once I don't need to go there again.
1 Like
Not a bad idea. I was trying to keep it whole on the way through so I could use an array reverse at one point (working with a log from a medical device that dumps its audit logs in what feels to be the least useful formatting imaginable for our purposes, but derp, I can just reverse the final array after the join.)
I guess my mental image was more of an "amber outline if there are any messages pending" approach.
After the file in the necessary msg.parts are in place so you should be able to use a join again at some point - maybe after having reduced some fo the fields, - and then yes reverse the array later.
There once was a fork that did flash the wires... (anyone remember Octoblu 
) and we didn't accept the PR then either...
Yep, that's what I ended up doing.
That sounds awful...
I probably shoudn't have posted my post, since I really did not meant it seriously, sorry
Sometimes knowing or talking about what doesn't work is as important as knowing or talking about what does.
1 Like
well it did look fine when really slow - but we don't want slow
Aww, that would have been way cool! I think that animated rainbow colours would be fab. 
1 Like
You can get back in your box with Timothy Leary ! 
2 Likes
This would be superb if it was like a PLC editor shows a live line (connection) color like the line becomes green once a message passes and the border line of the node becomes green if it processes a message. After the cycle from begin to end node is complete all lines reset to grey (default).
A visual somewhat like this when running live:
Two things.
- The Editor is not a dashboard.
- What would happen when 25 different (arbitrary number) nodes are feeding 1 node? What value would the colouring have then?
Node-RED is not the same as an industrial PLC tool. It isn't meant to be.
I don't believe that the core concepts behind node-red and the Editor have changed in the last 4 years. If you have ideas for further development of Node-RED, probably best to share in a new thread.
- sure it's not a dashboard, it should not be. That's what dashboard/ui is meant for.
- they remain green, as blinking super rapidly won't help anyone's eyes.
It's purpose is simply to debug, and visualise the flow of messages so it's clear where no messages are going while they should and vice-versa.
Don't get this wrong;
- The editor has a debug pane that is not clear in where the messages come from, sure you can look it up but it's not instantly visible/clear.
- The editor nodes already has information like a bulb,circle, square and text as status info why would that be there otherwise?
- A line showing a color (green? or configurable) for as long as the node is sending data over that line would instantly make it clear where the messages are passing. Due note that NOT all tabs should process the color changes, only the lines that are actually visible in the editor could/should show the difference.
Yes node-red is not a PLC (editor) but the (plc) software has proven to be useable by large industries and even small companies because it's clear and easily debuggable.
Node-red is just missing this, or at least a way to see the actual functional flow of messages.
Sure i would put this in a new thread, probably would try to make it more clear. I'ts not much more that the image showing the active-connections trough the lines between nodes. it couldn't be more simple explained.
thanks for your info.
again i like node-red but think this is just a addition that would improve it's editing, debugging capabilities and visual representation just that much more.
A key difference between a PLC and Node-RED is that a PLC is continuously scanning and so representing the "power flow" (green lines) makes sense. Node-RED is event based and so only has "power flow" when a msg is transmitted.
How do you propose the power flow should appear with this ↑ knowledge in mind?
PS: I do agree in principle (that some kind of power flow or inline debug or other inline visual indication of state would be a great addition for understanding current condition at a glance) BUT what that is and how it would work precisely would need much thought and consideration & ultimately, we may all end up agreeing there is no sensible fit!
as stated before this could be simply the flow of a message. Since there is no "power" as in a plc software but the visalisation would indicate somewhat the same as if it where a digital signal.
This would be great if this was added to the "debugger" since again it's not always required to be active but a very welcome addition to "see the flow of messages from node to node".
I don't see why this would not be a good addition, but then i'm not the developer of the node red software. Even if it where hard or not, many people including total newbies and advanced users could benefit from this in my view.
Hi @sworteu
This particular feature has been discussed quite a few times in the history of the project - many of which will be findable on this forum.
One of the reasons we've held back from doing something like this is the performance impact and overhead to manage it properly. If you have 100s messages per second flowing through Node-RED, then that's a lot of overhead to send to the editor so it can represent this information for limited gain.
Alternatively, if the runtime becomes responsible for aggregating the information and providing a cut down version to the editor, that is again a lot of additional work for the runtime to do that isn't related to its primary purpose - running the flows.
Adding it to node-red-debugger would be one way to start experimenting with how it could be done efficiently. If anyone was interested in contributing something along those lines, I'd be happy to discuss first.
1 Like
