I think this is a bug, but I am a bit unclear which component, and would also appreciate confirmation that I am thinking of this correctly.
This begins with occasionally seeing graphs labeled in celsius that are in fact in fahrenheit. I am convinced the problem however is not in the graph, at least not really.
My configuration.yaml has unit_system: imperial, and I have a couple of MQTT thermometers sending data. Those default to C in the transmission and correctly label it as C, and generally speaking HA is converting to F.
The issue comes on HA restart (and maybe other similar functions). I deleted all “states” entries for a sensor and restarted HA. Here is what is recorded in states after a few minutes:
sqlite> select state, entity_id, last_updated, attributes from states where entity_id = 'sensor.ac_split_ambient_temp' order by last_updated;;
state entity_id last_updated attributes
--------------- ------------------------------ ------------------------------ --------------------------------------------------
unavailable sensor.ac_split_ambient_temp 2020-04-08 17:24:15.786679 {"unit_of_measurement": "\u00b0C", "friendly_name"
unknown sensor.ac_split_ambient_temp 2020-04-08 17:24:15.789305 {"unit_of_measurement": "\u00b0C", "friendly_name"
75.6 sensor.ac_split_ambient_temp 2020-04-08 17:24:15.849785 {"unit_of_measurement": "\u00b0F", "friendly_name"
75.7 sensor.ac_split_ambient_temp 2020-04-08 17:24:37.966803 {"unit_of_measurement": "\u00b0F", "friendly_name"
75.9 sensor.ac_split_ambient_temp 2020-04-08 17:26:37.967369 {"unit_of_measurement": "\u00b0F", "friendly_name"
Notice that the first two somewhat bogus items are in C, but subsequently in F.
When this sort of record is the FIRST record (in date order), the history-graph will use it for the label. Worse, if you mix two entities on the same graph one of which has this row and one doesn’t, it gets separated into two graphs.
If there are real data rows earlier in the states table, that history-graph sees first, it is in F.
I am not sure if it has to be the first row in an absolute sense, or first in the data range graphed.
Deleting the unknown/unavailable rows from states fixes the graph correctly.
Zwave thermometers record a similar unavailable (didn’t see any unknown) but the are labeled F consistently in the states tables, leading me to think this is an MQTT issue as it writes state entries. At a guess when it can’t do the math it ignores the units.
Note that the states display in the developer tools shows this as F given the above data.
Because often a new sensor appears only after a restart (or you might force one by a restarted), this is perhaps more common than you might think, i.e. where the first row is incorrect. Intervening rows that are incorrect have no impact (well, I think – I have not seen any).
My ESPHOME has no explicit unit of measurement defined and is sending (always) C as expected (I’ve looked in the database).
I have read several postings where people are pushed to configure explicit unit of measurements in customize vs configuration or in the graphs, but I think this is just broken at the data level. The same entity_id should not be converted sometimes and not others, at least in my opinion.
Bug?
MQTT?
Or am I missing something?
Venue: 0.107.7 ESPHome 1.14.3 Mosquitto (separate not imbedded) 5.1 on all Hass.io