Wire heat map which can be controlled when creating node types

Developing Nodes
1

I wish to heat map a wire to reflect its usage either by thickness or color via a node. Is this possible. Wish to take metrics and in input adjust colors of attached wires.

See other benefits such as visually tracing a path of a message. The color could remain based on time period. Great way to see if you have tested all paths.

If wires can have a label , the ability to put metrics into the label would be nice as well.

2

Should this be in the features request subsection rather than creating nodes?

See Nicks reply here. Select Custom Colors for Wires?

1 Like
3

Should be a feature as well. As creating a node type wondered if I could do my own tweeting. The wires are assigned unique id. If the id was placed on the svg path then it may have been possible to achieve the result I desired until it was developed. But from what I can see this is not the case. I would have thought it should be relatively easy to provide. Even the first step of adding id to path would be quick win.

4

Apart from the issue that wires don't have properties, the other issue is that for this to work every node to node msg would trigger a websocket message to the browser, for simple flows this may be ok - but on more complex flows (of which we know there are many) and on low powered devices (of which we know there are even more) then the performance hit would not be insignificant. We already have instances where just the messages to the debug window can cause significant slowdown. Adding potentially hundreds (perhaps more) extra websocket messages is not something we are planning to entertain in the short/medium term. In settings you can turn on metrics and create a log with a lot more detailed timing information in it which you could then analyse, possibly in real time as a separate runtime, and could drive something like a heat map if so desired.

However that is the joy of open source - you can take and modify the code however you feel like. The main file that looks after the drawing is ./packages/node_modules/@node-red/editor-client/src/js/ui/view.js
Look forward to seeing what you come up with.

5

Appreciate the performance hit but would consider it use in the same light as the node "status" which would have the same considerations. Would see the same implementation. It is just extending this ability to the wire. That is, I assume it places information against a node which is then exposed on refresh cycle.

May be wires should be extended to having properties as would allow other potential benefits such as altering path on diagram. They have at least one property as they have an identifier which is the key to other properties.

6

It’s not really the same as status as status is supposed to be the state of the node and not the state of the msg passing through. So should not show things that change too often.

As previously noted by Nick, currently wires have no properties so there Is nowhere in the flow file format for that information to be held, without a major breaking change to the whole application. That is not going to happen lightly.

7

I suppose it is all relative as I see it being about the state of the wire and not the message going through the wire. That is the wire has been active. Rate of messages is not about message but number of messages. If node was a router could even show if a path had been stopped.

The sending node could even retain the state of wire. Actually start point as all wires would be the same for the start point. Thus not have to record against wire as a concept. Just an extension of current logic/cycle as node.state code. Fits within current architecture.