Language, date and time formats, etc, are all based on the user preference. Temperature (C/F) should be a user setting as well.
@jackjourneyman closed a copy of this at the below link as being complete so I can’t reply there, but it is not. The current implementation for F/C is a system setting, not a user setting. If you have multplie users of your HA instance that are from different backgrounds (such as European and American), one of them is stuck. They can change all time/date/language/etc in their user settings, but not temperature format.
What you’re asking for wouldn’t work. It’s currently a general setting (system wide) or a sensor setting. Statistics and the database are based on this setting. Based on how statistics work with unit conversion, this request would only alter the display in the frontend, however all the calculations wouldn’t be altered providing inconsistency in the UI. All your history would be based on the general settings / entity settings, so the graphs would have that unit. While your entity itself would display whatever the user selected. There’s really no way around this unless HA stored statistics for each unit. And that would drastically increase the size of databases.
I don’t even want to mention templates or automations either. Because those don’t know who’s logged in and the units would only be what’s configured in general/entity settings.
TLDR: Very unlikely this will ever happen as it would require a massive overhaul of many systems for almost no net gain. Especially when there are other ways to get desired units to display in the frontend.
… and then there is the why?
I get that people want to see the temperature, that’s fine.
But Home Assistant is based on automations, so in my view looking at the temperature is second place.
I use temperature sensors to trigger something, and I like having it in Celsius, but if I was forced to F then I would just set up the automation and be fine with it.
Having everything duplicated isn’t worth it for me. I have a few temperature sensors I don’t use.
Like the ESL tags, they display the temperature, I have no reason to use them as base on an automation or even look at it. They are just dead weight in my HA. So duplicating them would make it worse.
However as LiQuid said, you can template the ones that you need to make duplicates of. Most likely that will only be a few.
I like the idea. And I see where there would be a lot of work getting there.
From a system design perspective, I’d assume you’d have one internal standard (probably C or K) which all values would be stored in, and any conversion would be done only when they’re displayed.
Sort of like time. Use UTC internally, but adjust for the local time zone when displayed. Or store time stamps as seconds in the Unix epoch, but display them as days, months, years, hours, minutes and seconds.
Seems pretty logical to me. But again, if HA isn’t designed that way it would take some effort to change everything over.
That’s how HA works under the hood, but you can’t do that with statistics calculations because the equation changes based on the units. Also the backend handles the statistics calc and has no concept of the user. Units are stored in the backend, not the frontend. There’s a long list of small changes that would be needed. But the crux of the problem is the calculation being done in the backend using the units from the entity.
Actually HA doesn’t normalize units today. And still can provide statistics. Correct me if I’m wrong, but until conversion between units is a linear function (moreover Celsius vs Farenheit differs by fixed delta which gives errorless conversion) it really doesn’t matter the unit statistics are stored with. they remains convertible without an error after fetching from db.
IMO the request is valid.
PS currently HA relies on units chosen by user in data providers (devices reporting data to HA). coincidentally in most cases it matches a user needs. in most cases, not in all ones.
Kind of but then again not really.
Nobody in the household will stubbornly say it’s a different timezone.
And when you create time automations you just know it’s in local time.
But with temperatures (and possibly other units) it becomes a bit different.
Turn on fan at above 29 degrees.
29 degrees of what?
what’s the problem to add units to the query/formula? UI can propose units of the user who creates the automation. If missing, use system-wide default one.
Actually comparing time brings very similar challanges (if not more complex). you need to provide a timezone on both sides of equation. it influences definition of midnight, day, month, year boundaries, DST etc
The system may assume that missing timezone means local one. but it’s only an another way how to provide TZ (of course unless devs gave up opting for local time support only)
