Version 0.1.9
A little bit of small print added.
Alignment of elements improved to support non square 1X1 widget size
11 Likes
...This node just gets better...
Could you consider enabling users to be able to define the input message format please.
It's not an important request, but just something that you may feel would be helpful.
Many users will be using the gauge to display data from either their own sensors, or via an api, and a common format is by using a json object.
Currently before feeding the value into the artless gauge, the value must be run through a change node to identify & separate the values, like this -
However, if users could change the input format, it would remove the need to use change nodes (in my case lots of them!)
The default value could be payload
1 Like
Maybe I'm too oldscool but I'm against laziness in coding. Protocol is the rule to follow. I can't see any reason why the node, meant to deal with graphical representaiton of single numeric value should deal with finding it's input from arbitrary chunk.
But as always, I'm open for discussions.
2 Likes
As I said above, it's not an important request, just a consideration as it would reduce the number of nodes in a flow, make the flow easier to visualise and make the node more transportable within the flow.
The suggestion was based upon nodes that already provide this feature. Core nodes such as switch, range, random, template, just to mention a few.
But no worries, I'm using this node exclusively for graphical elements in my new dashboard, and it's a great addition 
Looks pretty readable to me. As we always say - a node should do it's particular job and do it well rather than try to do everything.
(but yes there are plenty of places where we have been "flexible" 
2 Likes
Next and most probably the last thing this node gets is the runtime configuration of min, max, sectors (with colors), label and unit. And that will be it.
2 Likes
Version 0.1.10
Runtime configuration for:
min, max, sectors, icon, label and unit
And this is it. No more features. 
2 Likes
Never say never.
Just a little addition. Small dots.
Version 0.1.17
3 Likes
As someone who has just found this gauge, and they are fantastic, can I suggest enhancing the Range section of the readme to include a bit more information about the sectors and the dot features. It has taken me a while to realise they both exist! It is exactly what I am after (a gauge with multiple sectors) but it is not obvious to a new user this feature exists 
.
I'd add a +1 to that suggestion with the option to use a template as well (similar to the standard ui-gauge).
You could drop the decimals option in that case (set it via filter).
I'm sure the author would be happy to receive pull requests with extra documentation..
2 Likes
If only my Javascript skills extended that far 
. I do where I can and I'll look at the documentation bit once I've worked out how it all works.
I was just about out to write this same message. And I'm really thinking about to add the template option for value format. I'm afraid it will be breaking change so no promises for now
1 Like
@hotNipi, is it possible to configure the stroke-width of the gauge? Could this be added as a feature? 
.
I left it out because it creates too many layout dependencies. I may add it maybe with very limited amount to adjust so that extreme fat stripe still not possible.
1 Like
@borpin you’ve obviously worked out enough for the range and dot though. So can start with that.
Oh yes, I've got the gauge up and running and looking good - vast improvement. Just on my wall panel, the strokes just look a bit thin.
I've just realised that most of the issue is caused by the line being the same width no matter the size of the gauge. Perhaps simply multiplying the stroke-width by the size would do the trick. The size of the font etc seems to be relative to the size of the gauge.
Hi @hotNipi, I'm gonna back up @Paul-Reed here (I think)
Ok, then I'll chip in...
If I'm not mistaken, Paul is requesting that you employ the typedInput widget node red provides.
And as you say
I agree but that Maxim doesn't really apply here.
The end result is you or other kind souls telling newbies "add a change node before the gauge, move msg.payload.simplenumber to msg.payload` over and over.
I would argue that adding a user friendly feature (especially when a standard mechanism (typedInput) is provided in the infrastructure [node red] ) shouldn't be considered unrelated just because it's a graphical node or just dealing with a single number.
Lastly, this is all my opinion and I mean no offence, your nodes are fabulous and the work you've done is most definitely appreciated. It is, at the end of the day your work, your time & your choice.
3 Likes
I will try this out too.
Just let me get back home from nice muddy forest hike I enjoy currently.
1 Like
