The Number platform currently lacks a device class for angular measurements. This makes it difficult to properly represent devices that operate based on angular positions (like adjustable beds, motorized mounts, etc.) in a semantically correct way.
The Solution
Add a new device class angle to the Number platform to support devices that operate based on angular positions.
Device Class Details
Name: angle
Unit of measurement: degrees (°)
Suggested value range: 0-360° (with individual entities defining their specific valid ranges)
Icon suggestion: mdi:angle-acute
Use Cases
Adjustable beds
Head position (typically 0-60°)
Foot position (typically 0-45°)
Motorized TV mounts
Horizontal rotation (0-180°)
Vertical tilt (0-15°)
Smart vent systems
Flap angle (0-90°)
Automated window louvers
Blade angle (0-180°)
Benefits
Provides semantic meaning for angle-based controls
Standardizes the representation of angular positions
Enables proper unit display in the UI
Allows for more intuitive automation based on angular positions
UI Considerations
Display value with degree symbol (°)
Slider control would remain appropriate for user input
Out of curiosity (not to diminish the request): while it certainly would not hurt to add it, what is it you cannot do right now by simply setting the unit_ of_measurement and icon yourself? I do not think value ranges are enforced by device class now. I have lots of angle/degrees entities already. If you’d propose a different input than number or slider I’d understand, but that is not what you ask for.
You are correct, this is not blocking me.
I’m currently working on building an integration for my adjustable bed.
I was looking for the best platform to use and was surprised to find that there is no elegant way to do it.
I could either extend a cover or a number, but both don’t really fit.
For now my plan is to move forward with exactly what you suggested. But it would be more elegant to have a supported device class.
Also thinking that asking for a “Bed” platform is much bigger than asking for a “angle” device class
Having a device class will make the sensor go into the statistics databases and I am not certain that is worth it.
It is not really something you would do trends and historic evaluation on, or compare to other sensors.
The vent/cable opening might, but then the angle could probably be converted to a flow instead, which would make direct companions possible, so again no angle.needed.
If Home Assistant were to over-extend a definition then the cover integration wouldn’t be a bad fit (per bed segment), seeing that it has already got a damper device class in there that is kind of a stretch to call a cover. It is a percentage though, so a number isn’t half bad and not stretching the definition.
If you check the beta, you’ll see next wednesday has an improvement for the tile card. That release is adding buttons to make numbers more bed worthy
Sadly my Auping connected bed has changed the API so there no longer is a working integration for it.
