Common unit-of-measurement config for all entities

[rianadon]

It's been a long time since home-assistant/core#59533 fell through. Sorry about that—life got busy. I'm now brainstorming how to best approach the original goal of making weather units customizable & consistent across integrations.

Looking at https://github.com/home-assistant/core/pull/64366/files, the easiest approach seems to be:

1. Have some standardized way (maybe an attribute?) for entities to describe what units need to be configured. For weather entities, this would be an array like [pressure, wind speed, precipitation, ...]
2. Add a CONF_UNITS_OF_MEASUREMENT setting to the entity registry. This will be a dictionary of fields like pressure: hPa

There are multiple units of measurement (pressure, wind speed, precipitation) for the weather component so it doesn't make sense to reuse the single CONF_UNIT_OF_MEASUREMENT that sensor uses

3. If no units of measurement are specified, use the appropriate units from the unit system instead
4. Allow integration authors to use whichever native units they see fit (i.e. integrations with weather sensors shouldn't be running unit conversions; the base weather component shall run unit conversions instead)
5. Run unit conversion inside def state(self) in components/weather/__init__.py

However, I will be duplicating some of the supporting code (e.g. listening for entity registry updates, rendering the units options on the frontend). Other entities with user-configurable units will also need to duplicate similar code. Some options for consolidation I'm considering:

1. Pull out some useful unit conversion routines like scaling units and suppressing ValueErrors from sensor/__init__.py and put them in the utils libraries.

2. (I don't like this) Make CONF_UNITS_OF_MEASUREMENTS standardized across all entities, including sensor. In the frontend, this might look like a second drop-down where 1 or more units of measurement could be configured.

   

   This is keeps the units of the measurement in a consistent spot, but I'm unsure if having a dropdown makes sense for cases where there's only one unit of measurement to configure.

3. (I like this better) I'm also considering a system where entities have either a CONF_UNIT_OF_MEASUREMENTS option rendered as an input field or a CONF_UNITS_OF_MEASUREMENTS option rendered as a dropdown.

4. Also one lingering question: I remember the effect of the user changing units on the history graphs was an issue in previous discussions. Is there a solution to this problem?

@emontnemery @frenck you've both had great advice in my last PRs on the weather integration units so I'm curious to hear your opinion on this.

[emontnemery]

I would suggest to start with implementing unit conversion support specifically for weather instead of trying to solve it for all platforms at once.
If needed, we can always reconsider unifying how settings are stored etc. in the future.

Avoiding duplicating common helpers which are now part of sensor, for example for unit conversion and for listening to entity registry updates, can of course still be done.

Maybe a mixin class for Entity which adds boiler plate code for entity registry entry options?

[rianadon]

@emontnemery for the weather integration, I'm considering having a single attribute preferred_units for the entity to describe which units it would like to use (i.e. the units that are in effect before the user overrides them). Something like this:

Once the new units are validated, they can be merged easily: final_units = preferred_units | options_units

This differs from your solution where we add new state attributes precipitation_unit_of_measurement, pressure_unit_of_measurement, temperature_unit_of_measurement, visibility_unit_of_measurement, wind_speed_unit_of_measurement.

I'm hoping that having a single method rather than multiple properties will help unify units in the future and run unit validation from a common mixin.