An idea for the behavior of connections.
A connection between nodes can have a color depending on one or more properties. e.g. msg.payload = true -> color = green, msg.payload = false -> color = red, .....
The color and properties should be freely configurable. The property should also be able to be displayed as a status to each wire.
A wire changes its appearance with each forwarded message.
Welcome to the forum @uli-rpi
Imagine a wire which alternately carries messages which show different colours. Now imagine that the messages are going through at a rate of 1000/second. Now think about the overhead in the comms to the browser to pass this information, and the processor overhead in the browser flicking the line colour at this rate.
This is a similar problem to PLC monitoring. The logic can be flip-flopimg at 80MHz but the state displayed is from the time of read and it doesn't try to show you every scan (kinda rate limited)
While I'm not sure I fully support the suggestion, I see why it's being asked. Seeing "power flow" in PLC ladder logic is VERY powerful for debugging - but can also trip lesser experienced engineers.
Food for thought.
The editor is not a dashboard...
@dceejay , have you hijacked Ben's login 
Cheeky 
Joking aside, there are tangible benefits to visualising the data (for debugging purposes alone) - I wouldn't thank you for a PLC without decent monitoring software without visual cues of powerflow or transient values. It makes life difficult.
But yeah, I'm fully up to speed on the node-red is not a dashboard mantra 
This has come up multiple times over the years. Apart from the “it is not a dashboard” side of things, and the update rate hitting performance thing, the other main practical problem is that wires do not have properties so can’t be assigned things like colours or function. To add them would require a new flow file format, and a major rework of the internals. This would break any backwards compatibility and is not on any short term priority list.
Absolutely Dave, I do understand the current limitations and reasons (I'm pretty sure you know I know ). But I am always (personally) open to the idea of things like this (wires properties, visual feedback, etc) being of importance coming from 25y+ of debugging "flow like" logic in high volume production facilities.
We may never get there but I do enjoy engaging in these conversations in the hope a new direction may one day lead to something new and exciting and helpful.
At first I didn't like this idea because it somhow seems contrary to the idea of a flow of data. A wire is the route data takes, not the data itself.
But I can see a use in a complex flow with lots of crossing wires.
If a data input point sets a property msg.wirecolour, the route of that data through the flow diagram could "light up" something like this.
Never say never, but there are lots of things on the todo list that seem to be higher priority.
And don't forget we already have the node-red-debugger that can be enhanced to improve debugging.
And indeed a thought Nick had re splitting wires to help routing by using a small dummy node.
I understand what you mean, the basic idea was to set the color when a message is transmitted, a selectable interval such as the tigger node would of course be helpful.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
