WTH - Why do I have to set up templates to convert units?

I am implementing a Netatmo Anemometer to measure wind. The Netatmo app lets its users choose what units they want to display the data in (km/h, m/s, miles/h, Beaufort or Knots).
But in HA, I have to set up a template sensor to convert the data??
I guess this could be fixed using an option in the Lovelace card? Or maybe even the Netatmo API lets HA check what units the user has chosen!?

Yes please! Convert data directly in Lovelace

While I 100% want this, I have to point out that would require major changes. Especially if we wanted units to change on an individual sensor basis. Essentially each sensor would need ‘user units’, ‘input units (from hardware)’, and a conversion equation for this to work. Maybe this could make it easier to implement…

Edit: There’s also this. Seems a bit easier but it would require some very specific unit types.

Lovelace is mostly client side javascript and unit conversion is very simple math… Provide an optional input that lets the user perform an math operation in javascript. If you wanted to get fancy and the integration knows the current unit, you could present presets but really most of the time I just want to convert seconds to Minutes or something simple.

IMO ideal situation would be if data stored in sensors are always normalized to some system of units. Let’s say SI.
It would makes easier then to manage conversion on FEs. It obviously has more profits than this one. AFAIK current HA can store temperature in Bars and the system doesn’t care about it. Which works but has limitations if you start to transform/compare those data etc.

Yes, this is what most softwares do. System units under the hood in the backend and user units in the UI. It’s no easy change, it would be rather large. It would also screw up all the current databases.

OK if making it know units is hard just give us a simple math transform in JavaScript or something.

You could even over simplify it to only multiply and divide functions… as that is mostly what unit conversion is.

I have a counter point to this, for consideration. I do believe that some values are best stored in this way, but not all. Time for example, great practice to store in UTC, then just shift to local in a UI. However, many values stored would benefit from getting normalized to local standards before storage to make analysis and display much easier. I’m working on a simple barometric pressure input. I want it stored in inHg, because that is what we know where I’m from. I don’t want it stored in hPa and have to convert it in every chart or panel. Not to mention the overhead, extra calculations every display as opposed to one calculation on store, then never again. While I’m a fan of SI, it is still not how everyone in the world thinks, so as long as we have to convert, why have to do it every time as opposed to just once?

don’t get it. You are ok with converting between time zones, but you aren’t in case of other units?

because it makes software more resistant to programmer mistakes. It allows to establish strict contracts, thank to which core programmer has to take care about only one unit. The rest is FE responsibility

That’s correct. There is an overhead involved to be considered. Time is not a unit shift, it is a value shift. When you have a unit conversion to do you need to consider all units. This makes working with the data and the logic almost impossible at the same time as a human. Computers do not solve all problems, many times programs need to be worked from a data perspective. This can complicate things massively if my logic needs to consider all possible units. Also, any program then needs libraries to do all possible conversions loaded at all times to do all conversions. I’m not saying I disagree with standardizing storage. I will just say it’s not an absolute “right thing to do” and that there are clear reasons and example not to do it.

I have a sensor reporting kW and another reporting W. They are in the same expected range (expected solar output, actual output).

I cannot plot them in the same figure because of the different units…
So creating a template. This requires skills (yaml, templates) and overhead (I have now multiple sensors reporting the same thing). Also what about names, do I add units to a sensor name? That sounds a-typical.

No? You only add units to the unit_of_measurement.

As for the rest, that’s all pretty simple stuff. Templates aren’t so simple, but dividing by 1000 is extremely simple, people just put templates on a pedestal and immediately assume they can’t do it. Same with yaml. Yaml is just a pattern. Copy the pattern.

Here’s a few different templates that does the division
kW → W

{{ states('sensor.xyz') | float / 1000 }}
{{ states('sensor.xyz') | multiply(0.001) }}

W → kW

{{ states('sensor.xyz') | float * 1000 }}
{{ states('sensor.xyz') | multiply(1000) }}

@petro Thank you for the examples. Can you kindly clarify what happens in each row? Mostly I am curious about the “float” part. Is that casting the sensor value? Are they just 2 ways of doing the same thing? Will HA complain about no default value?

All states are strings. If you want to perform math with a state, you need to make it a number. float is pythons version of a number that contains a decimal.

yes

yes

1 Like

The USA has been a signatory to the SI system since, I think, 1885. All Imperial units are based on the SI standard & the US is in a transition period to full SI.

The US has been in transion to SI for over 30 years, and the sooner the better. That will leave Iberia and Myanmar as the last holdouts to the illogical Imperial system.