Possibly, but my scant knowledge of CSS means it will take some time to work out what it will do for me. Luckily there is no urgent requirement so I can let it wash over me for a while.
Thanks, I suppose 
What exactly behind idea of changing the viewport?
Actually, it is soaking in already I think. By defining the gauge bit of the widget as a transform box then for the rotation it doesn't matter where in the total widget the gauge is.
The reason one might want to change the viewport is that at the moment it is square, but if one wanted just a 180 degree gauge then the widget could be wider that it is high. At the moment the box is 100x100 so percentages are the same as units, so it isn't an issue.
For that situation I think CSS variable should be applied to the outermost element and with that variable the container can behave as needed. And the attributed for the SVG can be changed.
On the phone currently so can't create example or something.
But if layout management goes too crazy it is very reasonable to have different widgets. As there will be no chance to leave out not used CSS or JavaScript, every instance carry all the data (except for core widgets I'd guess) so that part should be considered also.
For stuff like needle rotation in the gauge, where there may be multiple instances of the same template, the CSS really has to be inline in the html I think. Although it is implemented using CSS it isn't really styling, it manages the current state of the gauge.
Trying to pass in 'unit' & 'max' dynamically into artless gauge, using msg.unitinput & msg.maxinput, so that I can change units, such as Wh to kWh, which would be useful to make the full range of readings easily readable.
I thought the following would be a start, but obviously not!!
watch: {
msg: function(){
if(this.msg.payload !== undefined){
const v = this.validate(this.msg.payload)
if(v === null){
return
}
this.value = v
if(this.type != "artless"){
this.lit()
}
else{
this.changeLine()
}
},
if(this.msg.unitinput !== undefined){ <------
console.log("msg.unitinput exists") <------
} <------
}
},
Is there an invalid msg.payload possibly? The dreaded early return, which is best avoided.
No, the payload is a numerical value and correct.
I presume you are getting nothing from the log. That shows in the browser console of course, I guess you know that.
Add some more logs. At the start of the watch msg put
console.log({msg: msg})
Edit, sorry,
console.log({msg: this.msg})
Your addition shows that the payload is as expected, but whenever I add my code I get a syntax error;
[quote="Paul-Reed, post:107, topic:85955"]
}
**},**
if(this.msg.unitinput !== undefined){ <------
console.log("msg.unitinput exists") <------
} <------
}
Try loosing the comma
1 Like
Inline CSS has one disadvantage. The end user can't override it with ease. So must be used wisely. As we can't see into users heads and can't know anything about their design targets, the creator just needs to be openminded for everything.
Certainly. In the case of the needle rotation CSS the position of the centre of the needle is defined in the code and should be defined only once. Therefore any css that is involved in making that happen, such as transform-origin, should be inline in order that it can use the same definition of the required position.
Ah Ok, thanks Jeff.
I think that the comma crept in through habit of working with objects !
Hi,
this is my new dashboard2 ....
and I have this little aesthetic problem.
I show this dashboard in a tablet and the lower part under the gauge hum terreno, uv, ecc. is too high and it's out of the screen.
Where can I modify the gauge code to reduce this height?
If you look at my examples in post 96, one of them is raised up so that the gauge overlays the label, so you could look at how I have done that.
Ok, thank you ...
I seem to have missed the instructions after reading this thread twice?
When I put the first post code and CSS into a template node, this is what I get...
The 'testing stuff' is my group name.
EDIT: Found the issue. The first post CSS section does not include <style> at the start and </style> at the end of the CSS.
Then scroll down to about 1/2 though to the middle of the code and you will find this section:
You can adjust the type of gauge here.
Do a full deploy (dashboard 2.0 does not handle modified deploys very well at the moment).
With a simple number msg.payload, you can get the gauges to show up.
2 Likes
Is there a way to give them a little more 'breathing' room between each gauge?
They tend to run together.
Also the scale text is not responsive, but I think that's a common issue with Dash v2.0 at the moment.
Here is how they look on my Pixel 8 Pro.
Thanks for the work putting these together @hotNipi and for sharing them.
They are filling in a lot of gaps in the new dash. (I miss sparklines, have spent a few hours trying to get them going in v2).
