So I’m tracking atmospheric pressure using long term statistics. I like to see it over a few months and correlate the pressure changes with the storms we usually get here over the winter. I have an MQTT sensor for atmospheric pressure with a unit of measure set to hPa (hectopascal), which is the unit we typically use for pressure here:
Which leads to strange long term graphs like this (look at the units on the left y axis):
Why does HA feel it must overule my own manually defined unit of measure ? Pressure is measured in hPa, not in Pa. Why does it do the conversion anyway ? Is there a way to turn that ‘feature’ off ? The whole long term statistics thing is very poorly documented. Not sure if this is a bug or a feature tbh.
For certain device classes, the unit of the statistics is normalized to for example make it possible to plot several sensors in a single graph. Sensor Entity | Home Assistant Developer Docs
Interesting. So it seems ‘intentional’, but the results are more akin to a bug. Normalizing doesn’t make sense if you only have one sensor on a graph and it doesn’t make sense to change units that are considered customary / conventional use. Atmospheric pressure is always measured as hPa and never as Pa, just like temperature is not measured in kilodegrees.
Does that work with long term statistics too ? They seem to use a different API to the ‘normal’ history.
Weird choice. To be honest, this does sound like a bug / design flaw. HA shouldn’t touch my manually defined units. It should store the raw unaltered data and do any type of conversion on display only. Thanks for the link to the Apexcharts card patch, will try it.
Hmm. It does feel a little wrong to actually remove the device class and deal with the fallout (icons, etc) just to keep HA from messing with my data. If it helps, I’ll try though. Maybe the device class for pressure is too generic. It basically puts general pressure (water pressure, oil pressure, whatever) in the same bin as atmospheric pressure. Adjusting the units of the former may be acceptable, but the latter uses customary units that should not normally be changed.
I’m a little bugged out that this behavior seems to be intentional. I don’t like it when a system tries to be too smart for its own good and messes with my data without asking. Especially when I manually requested a certain unit.
So I suppose that opening a Github issue would be a waste of time ?
That worked, thanks. Changing the device class (and as such the storage UoM) will delete the entire long term statistics for the entity. Not entirely unexpected, but something to keep in mind.
I still consider it a bug that the long term statistics view won’t display the value of the entity using the entities original UoM, regardless of how it was stored in the db. Especially if the entity is the only one shown in the graph. That’s also a consistency problem with respect to the normal entity history graph, which will show the entity with its original UoM.