[HELP wanted] A Linear Level Indicator

Share Your Nodes
1

As for follow up of thread Linear gauge as another gauge option I actually started to do it.
First version (early beta) - horizontal only. Takes one unit height. Reasonably configurable.

image

It is kind of ready for testing. And here I need your help.
I guess some device testing should be done and may be something performance wise. And of course main behaviors and appearance.

I really don't now what is the best path to organize such phase of development and testing so I 'm wide open for suggestions.

Widget is not published to npm, you can reach it from github: https://github.com/hotNipi/node-red-contrib-ui-level

2 Likes
2

Very nice... (hopefully)

When I try to run it with just a slider input from 0 - 100 I get

image
image.png986Ă—58 8.88 KB

in the console and nothing on screen
Coming from
image
image.png1320Ă—140 30.1 KB

Some other bits and pieces...
in the config are these labels the wrong way round ? - I think warn is yellow...
image

As the node does not output anything it should have no outputs, and the icon should be on the right... (and maybe a better icon at some point :slight_smile:
image

Where is the word LEVEL coming from ? Should that be a Lebel people can customise - and if so should it also be the word shown on the flow editor side (unless optional Name is defined)
image

Finally the text colour ought to pick up the theme text colour so when you have a light background it changes automatically.

But - yes please... looks great.

2 Likes
3

Thank you @dceejay for this all. Fixed couple of things. :slight_smile:

Note to myself. Default comes first!

4

Nice widget ! I can't imagine any improvement, it is already perfect in appearance and behaviour (after the changes already done). Working well in my system.

21 Mar 15:28:45 - [info] Node-RED version: v0.20.3
21 Mar 15:28:45 - [info] Node.js version: v8.11.1
21 Mar 15:28:45 - [info] Windows_NT 10.0.17763 x64 LE

5

@hotNipi very nice!
It doesn't seem to work with negative numbers though. I was thinking of displaying signal strength (but could equally be sound levels or temperature, etc).

[{"id":"d4e95e21.57a23","type":"ui_level","z":"31e18edc.98bdc2","group":"ddd690d2.0351d","order":2,"width":"4","height":"1","name":"Level display","label":"","colorHi":"#e60000","colorWarn":"#ff9900","colorNormal":"#00b33c","colorOff":"#595959","min":"-100","max":"0","segWarn":"-25","segHigh":"-10","unit":"dB","decimals":0,"x":510,"y":640,"wires":[]},{"id":"bd43744c.616798","type":"inject","z":"31e18edc.98bdc2","name":"","topic":"","payload":"","payloadType":"date","repeat":"2","crontab":"","once":false,"onceDelay":0.1,"x":110,"y":640,"wires":[["abbb4584.76fad8"]]},{"id":"abbb4584.76fad8","type":"random","z":"31e18edc.98bdc2","name":"","low":"0","high":"-100","inte":"true","property":"payload","x":290,"y":640,"wires":[["d4e95e21.57a23"]]},{"id":"ddd690d2.0351d","type":"ui_group","z":"","name":"Test2","tab":"117b6717.6166b9","disp":true,"width":"27","collapse":false},{"id":"117b6717.6166b9","type":"ui_tab","z":"","name":"Test2","icon":"dashboard","order":7,"disabled":false,"hidden":false}]

level1
level2

Paul

6

I was thinking about the volume and then I made it to react too slow with animations for audio. Probably can be an option to turn animations on/off.

And for audio the stereo pair would be the thing i think. Something like this. And vertical.
image

For negative numbers I'll check out of course.

1 Like
7

Negative numbers supported now. And many thanks to @dceejay for high level support. Many things improved according to layout.

2 Likes
8

Updated https://github.com/hotNipi/node-red-contrib-ui-level
New - horizontal pair & animation options
Wide open for comments and suggestions :slight_smile:

image

2 Likes
9

Haven't tried today's changes, but tried it last night, it works very well now with negative numbers, and those spanning + & -.
As you mentioned above, on quickly changing values, it presents better with animations switched off.

Nice work.

10

Very nice, thanks for this!
Not sure if this is caused by the level node, but I can't seem to change it's position in the group. No matter where I put it, it always ends up as the last one. ( click image to see the entire group)

46
Screen Shot 2019-03-25 at 22.14.46.PNG328Ă—813 37.5 KB

11

That's strange... but yes confirmed. I'm seeing the same issue.
@hotNipi

12

Found it by myself also but seems to be lower level than node itself. No workaround at the moment.
EDIT:
Tried with node-red-contrib-ui_list. Same issue. It seems to be common for custom ui widgets.
In private conversation with @dceejay the issue was mentioned once, but may be it's better to do in some more official way somehow?

13

Did you ever sort this issue, or is it something that needs resolving at a core level by the node-RED team.

14

It is probably something dashboard level or deeper. I did what I could. Dave promised to look at it, but this will happen sometime next week or so.

1 Like
16

It's not error but warning. Nothing really broken. Its an issue we are currently working on. Can't give any time estimates really for now.

If you are using default or near default settings for dashboard layout, you should be fine. That's the warning says, node uses hardcoded default settings for internal measurements.

17

Very nice, thanks for this!
Not sure if this is caused by the level node, but I can't seem to change it's position in the group. No matter where I put it, it always ends up as the last one. ( click image to see the entire group)

Well, that is weird.

I have my test thing and it is quite happy to be number 1.

(See attached.)

For the sake of it while testing it, I put a text (I think) node under it to check the values are getting there.

As you can see my level node is before the text node.

On outputs:
It was also mentioned that the node donesn't have an output.
Ok, it probably doesn't, but I think it would/could be nice if it passes on the input to the output.
That way it is nicer if someone is having trouble with the node.
Stick a debug node on the output and check the node is getting a correct input.
(Speaking from experience) Putting a debug node beside it can be fraught with problems: like not having the node in the flow, but still getting data displayed and wondering why the node isn't working.

Just a thought.

Screenshot%20from%202019-04-03%2012-54-43

18

For widgets order/placement issue, just update the ui_level node.

About output, the regular gauge node as many others don't have output. And I really don't see the practical usage of it. If the input parameter needs to be debugged, correct place of debugger node will be output of that node which gives input to ui widget. As you can not see what is going on with your input inside the node you shouldn't expect the data to survive the path thru the node also.

1 Like
19

I agree with you about it being unnecessary to provide an output for debugging purposes, that should be taken care of from the output of the preceding node.

However most of the ui nodes do provide an output which we tend to use to save the last value to context, and so that we can re-inject it, in the event that the flow is restarted or a system reboot.

I of course realise that 'the last value' could easily be obtained from the preceding node output to save to context, but in the interests of ui node consistency, wouldn't it be better to add an output?
It also looks aesthetically better when laying out the flow, to tag a change node on the end of the ui node for that purpose.

20

No - the only "output" node that has an output for the state is the chart node, (as the way it stores state internally is a real pain and re-injecting hundreds of points would be daft). For simple values like gauges use, storing in context just prior to sending to the widget, and triggering a resend using ui_control node should be fine.

1 Like
21

I was meaning other ui nodes such as button, slider, switch, dropdown etc as well as the chart node. They all provide an output which could be used to restore the state.

I can imagine that being a pain, but the chart node and the level node are very different, in that for the level node it would simply be a pass through - ie just a single value, and not storing hundreds of points internally...
It would be very easy to implement and would not affect the node functionality.

But hey @hotNipi - your node -your rules :laughing: