Add new sensor/number device classes: altitude, azimuth, height, latitude, longitude, cpu_utilization, memory_utilization, storage_utilization

[ximex]

Describe your core improvement

This proposes 8 new device classes for sensor and number entities, covering angular positions, vertical measurements, geographic coordinates, and system resource utilization — all common sensor values that currently have no dedicated device class.

altitude — Solar/object elevation angle above the horizon

• Unit: ° | State class: MEASUREMENT
• Example: sensor.sun_solar_altitude (sun integration), solar panel tilt trackers

azimuth — Compass bearing / directional angle (circular, 0–360°)

• Unit: ° | State class: MEASUREMENT_ANGLE
• Example: sensor.sun_solar_azimuth, wind vane direction, motorised dish bearing

height — Vertical extent (water level, snow depth, sea level rise)

• Units: all UnitOfLength (mm, cm, m, km, in, ft, yd, mi) with automatic metric ↔ imperial conversion
• State class: MEASUREMENT
• Example: sensor.tank_water_level (cm), sensor.snow_depth (mm)

latitude / longitude — Geographic coordinates from GPS-capable devices

• Unit: ° | Precision: 6 decimal places (~11 cm resolution)
• State class: MEASUREMENT (latitude), MEASUREMENT_ANGLE (longitude)
• Example: vehicle trackers, GPS beacons, mobile weather stations

cpu_utilization — CPU load as a percentage

• Unit: % | State class: MEASUREMENT
• Example: system_monitor, netdata, ESPHome system stats

memory_utilization — RAM usage as a percentage

• Unit: % | State class: MEASUREMENT
• Example: system_monitor, netdata

storage_utilization — Disk/storage usage as a percentage

• Unit: % | State class: MEASUREMENT
• Example: system_monitor, synology_dsm, netdata

Current limitations

All 8 of these sensor types are in widespread use today across multiple integrations, but none have a dedicated device class. The consequences are:

• Integration authors use None as the device class, or pick the closest approximate class (e.g. misusing distance for height) — resulting in wrong icons, wrong labels, and misleading semantics.
• The UI cannot distinguish between a % sensor that represents battery level, humidity, CPU load, memory usage, or disk usage — they all look the same.
• Automation UI offers no meaningful filter: a user building "alert me when disk is almost full" must manually hunt for the right entity rather than filtering by storage_utilization.
• Long-term statistics and energy dashboards cannot group or filter these sensors by meaning.
• For coordinates (latitude/longitude), there is no device class at all — meaning map-card integrations cannot be driven by standard sensor entities, and automations cannot use typed triggers like "when latitude changes".
• For height, the existing distance class is semantically wrong (it implies travel distance) and altitude with length units doesn't exist yet — forcing integrations like tank level sensors to either misuse distance or use no class.

Technical benefits

• Consistent UI across integrations: every integration exposing CPU load will get the same icon, label, and unit display — regardless of which platform it comes from.
• Typed automation conditions and triggers: users can build automations like "when cpu_utilization exceeds 80% for 5 minutes" or "when latitude crosses a boundary" using the device automation UI, without manually knowing which entity to pick.
• Correct unit conversion: height registers DistanceConverter, enabling automatic metric ↔ imperial conversion (cm → inches) consistent with how distance and precipitation already work.
• Correct precision defaults: latitude/longitude get 6 decimal places (~11 cm GPS resolution); height gets 1 decimal place in meters; altitude/azimuth get 1 decimal place in degrees.
• Semantic separation of percentage sensors: battery, humidity, moisture, cpu_utilization, memory_utilization, and storage_utilization are all % — but now each has its own class, making dashboards and statistics meaningful.
• MEASUREMENT_ANGLE state class used correctly: azimuth and longitude use the existing MEASUREMENT_ANGLE state class (introduced specifically for circular/wrapping angle values), ensuring correct handling of 0°/360° wrap-around.
• No breaking changes: all additions are new enum values; existing integrations using None or other classes are unaffected.

Additional context

affects homeassistant/components/sensor/const.py, homeassistant/components/number/const.py, homeassistant/components/sensor/strings.json

Design decisions worth discussing:

• altitude uses ° (degrees) — targeting solar elevation angle. A separate length-based altitude class (meters/feet for GPS elevation) may also be needed, but that use case is partially covered by the new height class.
• longitude uses MEASUREMENT_ANGLE because it wraps at ±180°. Open to using plain MEASUREMENT instead.
• The three utilization classes (cpu_utilization, memory_utilization, storage_utilization) are intentionally separate to allow per-resource filtering in dashboards. A single system_resource_utilization class was also considered.

Comparable patterns already in core:

• azimuth follows the same pattern as the existing MEASUREMENT_ANGLE state class introduced for wind direction and similar sensors.
• height follows the same pattern as distance (same units, same converter) but with distinct semantics.
• The utilization classes follow the same pattern as battery and humidity — both are % but have dedicated classes.

[Petro31]

GPS coordinates already are a thing in HA but they aren't a device class. Any sensor with latitude or longitude can be placed on a map. It doesn't make sense to separate them and add a unit of measurement because they wouldn't work on a map.

height already exists, it's distance. It covers any measurement that is the unit of a distance.

All your percentage ones are covered already with percentage. There are no dynamic icons for this aside from battery, so there's no real benefit to add them. As for statistics, the equations are the same, what do you mean "More meaningful"?

Technically wind_direction can handle azimuth. That one would be useful. altitude could also be useful, but what integration would provide it? I can't think of any.

You have AI compairing current patterns in HA, but there's no real reason to add these unique distinctions. Just some blanket AI statement saying "distinct semantics" or "dedicated classes". But what actual benefits do these supply.

Please use your own words, not AI.