Add device_class "direction" and "orientation"

[ratermir]

Hello

I am working on integration of Garni weather station to be able to untilize "autodiscovery" mechanism of Home Assistant.
These stations support (among others) also wind direction measuring. But I didn't fint such device_class (wind_direction) in the list.

So I suggest to add 2 new device classes: "direction" and "orientation".

There is a lot of real-life things, that are oriented somehow. I suppose integration cuantity of many of them will increase in the future. The same is direction.
A slight difference exists in understanding of orientation and direction: whereas orientation usually means static object, that is rotated to some direction, the "direction" usually means direction of movement (as in case of wind).

So my suggestion is to add these 2 device classes:

• "direction", means global direction in degrees from North
• "orientation", means object orientation in degrees from North

If these seem to be too generic, maybe "wind_direction" could be also OK for my use case. But I think the first two are wide usable for many use-cases.

There are more device classes that are missing (UV index, dew point - which is in fact temperature, but with different meaning), which are not so useful, but also consider to addthem?

[teskanoo]

They do not seem too generic for me.

I have a nagging log entry for my Everything presence mm wave sensor (Esp32)

Entity sensor.presence_library_target_1_angle (<class 'homeassistant.components.esphome.sensor.EsphomeSensor'>) is using native unit of measurement '°' which is not a valid unit for the device class ('distance') it is using; expected one of ['mm', 'ft', 'in', 'km', 'm', 'mi', 'cm', 'yd'];

I wish I could set this sensor's device_class to orientation or bearing or direction.

I have managed to set it to null using customize,

    sensor.presence_library_target_1_angle:
      device_class: ~
      state_class: measurement
      unit_of_measurement: °

but that just makes core fall-back to using the original_device_class in core.entity_registry

"device_class":null
"original_device_class":"distance"

[ratermir]

Ok, so what to do next? I started this discussion 1/2 of year ago, should I create normal ticket to realize it?
It should be simple change, but I don't have enough knowledge to do it.

[MartinHjelmare]

When you open an architecture discussion you should be prepared to implement the suggestion. Otherwise it's just a feature request that we don't track here.

Also, it's not a good idea to include more than one new thing per discussion. I suggest splitting this suggestion in two suggestions, one for each new device class.

Before adding a new device class we want to know how many existing, please list them explicitly, integrations can use it. Don't count MQTT, template or Esphome that can add support for anything.