Feature Requests - Node.Status Enhancements & Retain Panel Width on Refresh

Core Development Feature Requests
1

Hey @knolleary,

A couple of feature requests I'd like to make in the hope that you think they are good enough to make the cut:

  1. Node status : Node-RED
    " The fill property can be: red , green , yellow , blue or grey"

Can we have the option for a hexcolour for the fill property?

  1. Love the new option to restore zoom and scroll.
    image

Can the right-hand side panel also remember it's width on refresh?

Cheers
Aleks

1 Like
2

Hi Aleks .. how's it going ?

This one is already on the list of features
node-red-whiteboard

2 Likes
3

@Andy,

Hey, good thanks!

Nice one on the trello front. I didn't realise it existed, but very cool to look through it.

As for how's it going.... well, now that you asked, I've been migrating to nr-zwave-js and in the process building all the components for a multi-slave to single master network using NR envirnonments. The aim is to be running my HA system 100% off NR.

The amazing news is that it is working!!!

So far, I have 3x active slave zwave environments reporting to one Master NR environment and have 5x devices included across them. The devices report to and from the main NR (master) flows perfectly. I'm having to do some work to get each device type configured e.g. a dimmer vs a binary switch, but have pretty much all of the foundation built now and ready to scale across new device types. I've built things like the ability to manually or automatic refreshing a central table of device state/values, automatic updating of device node status (using node.status) for each device represented by a node on my flows, comms to and from the master/slave NR environments.

I have also created all the tools to allow a controlled migration to nr-zwave-js i.e. both Fibaro and nr-zwave-js devices work together across all my flows and UIs, so I can move devices one at a time at whatever pace I like.

I have also create a full event and trigger log using influxdb/grafana... really happy with it!
It helps with debugging and also has lots of other purposes e.g. I can see fully into every change made by a user that impacts a device i.e. fully system audit history, down to when Alexa is used to do something e.g. turn a light on/off, or a user changes the setpoint temp on the heating panel and it turns the heating on in a zone.

Basically, I've been very busy :slight_smile:

The request (number 1) above is for the subflows that represent devices in my flows e.g. in the image below you can see 3 of the 5 devices I have migrated across so far, these are all subflows:
image

I have also used the same subflow to create generic devices, one for each of the slave NR instances. Effectively each node represents a slave zwave network, so one place to maintain code for different applications.

The great thing is that by using node.status, I can report anything I want e.g. you can see where I've used a green dot to show a device is on and grey to show it is off + I've added the device current value and current power consumption. I could add the last on/off time, trigger source e.g. wall switch, UI panel, automation engine... it's obviously (practically) limitless just like NR is.
A very important piece of transparency/debugging tool will be to represent the auto lighting state (eg motion trigger on, dimming 30s, wall switch off) of a light in the node.status message... really looking forward to implementing that one.

The request (1) above is to allow the colour of an RGB/RGBW light to be represented on the device subflow a the same time, hence if I could have my wish come true, I'd also ask for multiple shapes to add to one subflow node.

That way a device could report something like this, if it was on and set to 20 and the colour was light blue and it was using 3.5 watts:

green box + "20" light blue box + "the hexcolour or maybe just the word colour" + 3.5 watts

The extra box to represent the colour of a light is super useful as you should be able to see its colour even when it's off. That way when you turn it on you know what the colour will be.

If the powers that be decide against allowing multiple boxes, but do allow hexcolour (or similar) to be passed to fill the box colour, then it will have to do, and the subflow will not have an extra box to show that the device is on/off. C'est la vie!

@knolleary please have a look at my request .... thank you.

1 Like
4

The idea of the status under the node is NOT to be a dashboard, and show the state of a flow, but to show the status of the node ie an underlying condition. To that end we decided to restrict the colours so that the choice of colour would tend to mean something consistent... eg red for error, green for ok, grey for undefined/uninitialised etc. If we just open it up to any colour then that clarity would be lost.

5

While I get the desire, not sure that artificially restricting Node-RED in that way is still the best approach?

The usefulness of the status node could indeed be extending by allowing some more colour without undermining the purpose. Well that's my view anyway for what it is worth. And some of the existing colour differences may be of no use at all for people with colour-blindness - further restricting possible choices.

The best possible outcome of course would be to simply allow an actual CSS colour value - including var(....), rgb(....), etc. The use of var in particular would enable status messages to adapt to light/dark/high-contrast settings.

1 Like
6

which is why we use green with shape of dot and red with shape of ring so they can be told apart.

why of course ? It is one alternative outcome, that may or may not improve readability of flows. Yes I can see the utility for a rgb led but not for general status. On the other hand there has also previously been talk of enhancing the debug node to show more representations of data.

7

The "of course" was directed at being able to use CSS vars which let you easily design and build responsive interfaces. I expect there are also other ways of doing things like that but this seems like a relatively easy way of achieving it.

8

Hi,

I believe you could add your features / wish list to a function node and have it show you the status icons / values you desire. Probably you would be limited to one icon and a snippet of text but then create a separate function node for other icons / text. That would be the 'fast, easy' way to do this I think. More complex would be to add a custom node to display those things for you all in one place...

A small UI dashboard would also allow you to do what you ask plus much more.

Cheers,

Paul

9

Interesting discussion for me to read, especially as I am relatively new to Node-RED, having started in the middle of 2020.

@dceejay I am not in anyway trying to build a dashboard in node-red. You can read my other posts on this forum to see that I have spent a lot of time building actual dashboards using uibuilder and grafana.

The information that I want to represent will primarily be used for debugging, for example if I can see colour of the device (or for example, the status of the device as it is being passed through my automated lighting life-cycle), it will become a live representation of what is happening in my code related to that particular node, and in return be invaluable information when developing new features and debugging.

TBH, my mind is blown with the possibilities for debugging now that I can represent a device as a node... it alleviates a tonne of pressure on using debug messages (msg.x and node.warn's) and will make life so much easier when developing.

As for the request, I can of course pass the RGB values to node.status as a text string, but it's very tricky to visualise 3x values as a colour vs just seeing the colour.

Having the ability to represent multiple shapes each with their own RGW colour format via node.status will really help with the debugging, but as I said above, if it was restricted to the current single shape and RGB colour format, that would be workable.

I hope this is at least considered for future releases and thanks, as always, for your responsiveness.

1 Like
10

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.