Please give me some clarifications regarding using a device_class for a sensor domain.
For binary_sensor the class at least changes the icon: some icon for on, some for off.
I only know that for battery class the sensor changes the icon too - but I do not see any icon’s changes for other classes.
Also, I have to specify unit_of_measurement - although units are supposed to be specified (see the link)
Can anyone answer? )))
Sensor device classes do apply icons, and a unit of measurement.
Cannot confirm this:
So far the only benefit for me is a predefined icon…
P.S. The picture above contains sample values of template sensors with defined device_class and based on some input_number. I played with this input_numbers to see if icons are changing - and only the battery icon was changed.
Yes only the battery icon changes, the others are static.
The unit not showing could be a bug.
Then it seems to be a very old bug - at least from the autumn 2020 (I just started to learn HA that time).
OK, I will try to create an issue!
1 Like
Please check this:
So, the class sets only an icon…
Update: although Uom is not set automatically, a user may define only a Uom supported by a current device_class.
1 Like
Makes sense. Some classes have more than one unit.
I thought it also limited which units of measurement could be used…
It definitely does do that. I have had errors related to that for air quality index sensors which have a unitless device class but some integrations try to add μg/m3
Assume a sensor is created by some integration with some device_class (let it be “voltage”).
By default UoM=“V”.
But this device class also supports other UoMs like "mV (0.001x).
If some of these UoMs is chosen - then the state will be re-calculated (hope so) based on a corr. factor.
Here 12.4V is converted to 12400 mV:
And it is reflected in History in more-info:
and NOT reflected in History:
In fact, after restoring UoM back to “V” the history becomes wrong as well:
Issue with no any feedback from devs.
Assume this is a template sensor defined by a user.
And we defined “device_class=frequency”, defined a “state”, defined “UoM=Hz”, some unique_id:
input_number:
testing_uom_conversion:
min: 0
max: 1000
step: 10
mode: box
template:
- sensor:
- name: testing_uom_conversion
unit_of_measurement: Hz
device_class: frequency
unique_id: a54c405b-bb01-4e7c-8bea-22fb9b2938ca
state: >-
{{ states("input_number.testing_uom_conversion") }}
Current history:
Although we defined unique_id - Uom cannot be changed, no such a field:
So we have to change UoM in yaml:
...
unit_of_measurement: kHz
...
This does not reflect neither on a current value (not recalculated) not on a history:
i.e. device_classes for template sensors are smth a bit less than useless.
That is working as expected. Changing the unit does not retroactively change all the stored history values. If you want it to then you should open a feature request, not an issue.
Instead it changes the current values and makes a history inconsistent ))))
And for template sensors - defining device_class does nothing.
I guess converting a current value works only between Celsius & Fahrenheit.
Although it shows a wrong unit on a card.
- name: testing_uom_conversion_temperature_c
unit_of_measurement: °C
device_class: temperature
state: >-
{{ states("input_number.testing_uom_conversion") }}
- name: testing_uom_conversion_temperature_f
unit_of_measurement: °F
device_class: temperature
state: >-
{{ states("input_number.testing_uom_conversion") }}
Conversions between “kilo”, “milli” etc - are not performed:
- name: testing_uom_conversion_current_a
unit_of_measurement: A
device_class: current
state: >-
{{ states("input_number.testing_uom_conversion") }}
- name: testing_uom_conversion_current_ma
unit_of_measurement: mA
device_class: current
state: >-
{{ states("input_number.testing_uom_conversion") }}
