I’m in the UK, and I don’t think I’m alone in preferring Celsius (metric) for temperature but miles and miles/hour (imperial) for distance and speed. This limitation means I either have to have Celsius for temperature and km/h for wind speed or Fahrenheit for temperature and mph for wind speed. I can’t have Celsius and mph.
Some integrations allow the units to be overridden but even if a weather integration supports separate units for temperature and wind speed (Dark Sky supports the uk2 unit type which does this) the weather card displays the units based on the global setting.
There are other systems which allow different unit systems for different measurements, for example my Alexa devices allow you to select independently whether you want to use metric or imperial units for temperature and distance like this:
TBH (also in the UK, as is Tink too) I use distances a LOT for home radii in heating, sounders, music etc.
I quite like the 3.462 km as that’s 3 km and 462 metres.
If some one asked me what 0.462 of a mile was I’d just have to guess between 790 and 880 yards (it’s actually 813 yards).
We’ve been metric since ‘well’ quite a long time (work started in the 1861 by some leading British Scientists Lord Kelvin, Maxwell and Joule to hit the high notes. (Note: Not implying this ‘should’ credited to the Brits as the French have had a major involvement (as have many other nationalities) and this system is not just based on the length of your ruler’s (i.e. King’s) forearm or other stupid arbitrary measurement (fahrenheit has me in stitches )
With SI units you can cross calculate stuff and make things both relevent and more meaningful.
eg whats the diameter of the earth ?
Well there’s 10,000 km from the equator to the pole (original definition) - so normal circumference is 40,000 km
Actally it’s 39,940.653 but I wouldn’t split hairs over that
So diameter is 12.732 km (radius is 6.366 km)
we rotate at 366.25 (ish) rotations a year (as we pass round the sun, so more than 365) so equatorial velocity (relative to the earth’s CoG) is 40,000 * 366.25 / 365.25 / 24 = 1671.23 km / hr (about 1032.5 mph or 464 m/s)
Say I weighhave a Mass of 100 kg and I’m stood at the equator
using f = m * v * v / r
100 (kg) * 464.23 (m/s) * 464.23 (m/s) / 12732 (m) = 3.385 N
3.385 (N) / 9.81 (m/s2) means I “weigh” 0.345 kg less (and as it was 100kg - 0.345% less for everybody) than I would at the North Pole, using a sin(lattitude) I can work that out for anywhere on the planet (unless you are a flat earther )
There are lots of similar examples - Ditch Imperial Get with SI
That’s how it’s done in another home automation software. The base unit system is SI so, for example, all your temperature sensors store their values in Kelvin. If you want to display one sensor’s value in Celsius and another in Fahrenheit (or even Rankine), you just append it like this:
The sensor value’s "type’ is “Temperature Unit” which has its own conversion methods. The newbie mistake is to do this:
sensor.interior_temperature
which defaults to reporting the temperature in the default Kelvin units ( … wow, it’s hot inside).
I don’t see this approach feasible in Home Assistant because all states have the same type, namely string. Some other technique would be needed, perhaps identifying the sensor value’s preferred unit system in its attributes. Not sure what would perform the actual conversion though.
I would assume we’d want the conversion on the backend. We don’t even want to store the non-converted units. Or maybe we do and only convert on the frontend. The software that I develop for does everything under the hood in mm and we convert to user units on the frontend only. The difference is, HA won’t always have the same units for the backend because every sensor is different
I agree the converted value should not be stored. The entity would only need to indicate the desired unit system to render its state value in the frontend. That leaves the conversion entirely to the frontend (assuming it’s able to perform the task of reading the entity’s ‘unit_system’ attribute and performing the appropriate conversion).
I assume this ‘frontend’ conversion not only applies to the user’s Lovelace cards but also to the States view? Otherwise, the States view will continue to display all values ‘raw’ and not ‘cooked’.
I would assume it would be buried in the method to get the information. So that might be in the backend but not stored. Typically with an mvvm model, you want to be able to attach any interface to it and get the same value.
Edit: doing this might get hairy with history, etc.
The way I understand it, the way it works is that the states are stored with their original units and then when these are displayed in the frontend it looks at the unit_of_measurement attribute of the state and the preferred units system and performs the conversion. It’s just that the same units system is used for everything and you can’t choose a different one for temperature, distance, etc.
This doesn’t necessarily need anything changing in the backend state engine, just more flexible conversions in the frontend.
FWIW, in the other software, that method is in the backend. If you ask for sensor.whatever.celsius you get the ‘cooked’ value in celsius. Ask for sensor.whatever and you get ‘raw’ Kelvin. Same goes for length, pressure, speed, volume, etc (all stored in SI; entities have methods to perform conversions to the requested unit system).
Screenshots displaying the properties and methods of various Unit classes (tiny black 'cube" icon indicates it’s a method):
A combination of “unit_of_measurement” and “device_class” would be a good base to create something.
That way, you could create a sensor in HA that has device_class: temperature - meaning the data stored is in kelvn, while the unit_of_measurement: C would mean that whatever I receive from the physical sensor is in Celsius, and when the value is stored, it should add 273.15 to the received value.
Then you could either add some jinja-filters, so you can do stuff like {{ sensor.my_temperature | celsius }} or {{ sensor.other_temperature | fahrenheit }}, or you could extend the sensors as @123 describes, so you could use sensor.my_temperature.celsius directly
I’ve been frustrated by the state of units in HA too. Why does every user in a house have to use the same units? I’d strongly prefer to use C everywhere but I have to use F because of my wife. Worse, HA isn’t always good about actually doing the conversion before storing so sometimes you get a mix of both units in your history.
HA is already storing the unit in the backend and doing conversions in some places but not others. It’d be much better if this were unified.
Another example… I live in the USA and am used to using F as the unit for indoor/outdoor environmental temperatures, but for CPU temperatures almost everyone uses C, no matter where they live. When I set up a CPU temperature sensor it was a huge PIA to get it to display in C because HA kept forcing it to F!
So even if there were a way to specify the unit you want to use for “temperature” independently from “distance” or “speed” there should still be a way per sensor to override the default to avoid the hoops I had to jump through with that CPU sensor.
P.S. I’m aware this thread was started almost two years ago, but it’s easy for googlers (like me) to end up here.
I think the best solution is to force the Americans to use the metric system, like the vast majority of the rest of the world (and including the American scientists). Everything else is a workaround.
)
Not sure what would perform the actual conversion though.
