I’ve had this happen before with a REST + template sensor as well, which imports the data as unit_of_measurement *C, then displays as *F. Sometimes, after a while, lovelace displays it correctly as *F, but every so often it switches on it’s own to be labeled as *C, while displaying the numeric value of *F (so it’ll be 23C → should display as 73F, but instead displays as 73C).
Interestingly, this only affects these graph style charts (both in a custom dashboard and in the history tab, but not the gauges or the graph when inspecting an individual item. I’ve tried updating homeos and hacore and am kind of at a loss - this seems like some sort of bug in ha?
It’s set to “Imperial Fahrenheit, pounds”. switching them around didn’t seem to change what graphs showed up in lovelace, with still a *F and *C separate graph, with the same lines on each.
Though I noticed a different bizzare (at least to me) behavior after switching the general config to metric: the history graph has the old values in F, but just smacks the C value at the front. (I know for sure the raw values for this specific picture are *F, coming from REST. The same happened to another REST which has raw *C values…). Does HA store the value & unit, or it seems to just store the raw value and switching the system units seems to break things.
That can happen if some bogus measures get recorded with the wrong unit.
Assuming the root cause (configuration?) is fixed, it will disappear by itself.
@koying is correct. This has come up before, and as I understand it, Lovelace looks at the first entry in the recorder database to determine the unit. Every other value after that is assumed to use the same unit.
Once you’ve got it recording the correct unit, the solution is to either delete the recorder database or wait for the “bad” values to roll off. It’s also possible to edit the database to delete just the unwanted values if you’re handy with SQL and databases.
I wonder if it might be a good idea to submit a request to change the logic to use the last unit entered for a value, instead of the first.
This is weird because I never change unit_of_measurement in my config, yet this is a recurring issue, where certain entities will periodically bounce between being labeled as “C” or “F”. I know one that is particularly problematic is a REST api which periodically returns null values, would that cause issues?
This seems to be something more than just bad data in database causing this bug. It’s also related to the hours_to_show. Here’s three history graphs using the same 2 entities, but the hours_to_show are 35, 45, 55. Anything between 35 and 55 breaks like the 45 you see.
I checked the database and anytime the sensor state is unavailable, attributes is {"state_class":"measurement","unit_of_measurement":"\u00b0C","friendly_name":"Hall Motion Sensor temperature","device_class":"temperature"} (weird design, attributes should be null if you ask me). So the wrong unit is being recorded where there’s no real attributes to record, and the card reads this as useful?!?
The sensor only became unavailable twice, both times were for very short periods, not enough to even make a mark in the graph, yet this somehow creates a 20 hour zone of madness. Beyond weird choices for null data in the database, this is definitely a bug in the card, as it should not be taking into account the unit type of the times when the sensor is unavailable. In my mind the card should at least:
Always use the unit type set on the entity for display, not the data itself.
Transform recorded data into display units when possible.
Ignore recorded data with mismatched units when impossible to transform.
Override features that would be nice to have per entity:
A settable display unit type
A Flag to ignore recorded unit type (i.e. pretend the recorded values are of the display unit type)
My SQL-fu is kind of weak, and I have no interest in periodically fixing up the database. I hope this gets fixed soon.
Got the same problem: two pressure sensors, both configured in hPa, show in statistic scard with the unit ‘Pa’, one shows with a conversion factor of 100 (which calculates to the correct value in Pa, altough I would like to see it in hPa) and one without conversion, resulting in two measurements which are really close together to show as a factor 100 different.
