I’ve been digging around to work around this missing feature. Looking at .storage/core.device_registry and .storage/core.entity_registry, and I just want to keep some notes here on how far I got.
Looking at my IKEA Zigbee on/off/dimmer button, it’s as a device in the registry of course, but without useful info about the device class: all of this seems to be hidden in the integration (ZHA in my case), which figured out that this is a switch and enumerates entities. So there’s no info in HA that says “This is a switch [corresponding e.g. to a Zigbee cluster in a profile?], and in addition to having the switch-entity, it has another few entities that may be useful to you, like battery-level”.
So if I’m not interested in entities only, but the physical devices, my best way forward seems to be to build a mechanism that reconstructs the “device class” (switch/dimmer/sensor) based on the available entities (which I find in the core.entity_registry) and define a library of well-known device classes (which collection of entities for a device make it a “switch”, possibly with subclassing/multiple inheritance). Basically, HA doesn’t so much work with devices, but just all of their individual entities, with the only benefit of adding all entities of a new devices together in a UI-element when adding it.
Given just the device id, is there a way to ask the underlying integration to provide the underlying device class to me? Or is the original_device_class in the entity registry OR the entity-class (“switch”,“sensor”,…) the closest I can get? It would be really nice to somehow harness the underlying Python classes/class-hierarchy…except: is there actually a hierarchy? The binary_sensor has no relation to the sensor-device class, it seems, and duplicates lots of the enums in there.