Unit_of_measurement_template

Feature Requests
1

I would like to have a conditional unit of measurement added to sensor template mainly for power display but I’m sure it would be handy for others.

  • platform: template
    sensors:
    solar_today:
    friendly_name: “Solar Today”
    value_template: >-
    {% if states(‘sensor.envoy_today_s_energy_production’)|float > 1000 %}
    {{ (states(‘sensor.envoy_today_s_energy_production’) |float / 1000 ) | round(1) }}
    {% else %}
    {{ (states(‘sensor.envoy_today_s_energy_production’)) }}
    {% endif %}
    unit_of_measurement_template: >-
    {% if states(‘sensor.envoy_today_s_energy_production’)|float > 1000 %}
    ‘KWh’
    {% else %}
    ‘Wh’
    {% endif %}
2

You could accomplish this with what you have and combining that with the numeric value… a sensor for numeric value, and a template sensor for the unit of measurement, then combine the two in another template sensor.

3

There is the problem unit_of_measurement_template: is not an available option under Template Sensor

4

Because it would likely play havoc with the database and the way history is displayed.

1 Like
5

Yeah I just wouldn’t use the unit of measurement field at all just two template sensors… one for the numeric , one for the unit of measurement template and then combine them into another sensor. As Tom said it would pretty much be impossible to do that with the graphs/history/recorder

6

you could try and fiddle out a nice template in JS and use it in customize:

homeassistant:
  customize:
    sensor.ha_update_available:
      state_card_mode: badges
      templates:
        unit_of_measurement: ${entities['sensor.ha_latest_version'].state}

this does need custom-ui and works just fine.

something like:

if ((entities['sensor.envoy_today_s_energy_production'].state)|float > 1000 ) return 'kWh' ;
return 'Wh';
7

As others have said, having the same sensor report in different units of measurement at different times will likely cause issues with history and graphing. What you really want is simply a Lovelace card that will display in Wh or KWh depending on the value. Your underlying sensor should simply report in the same units regardless. It’s the job of the frontend to display that appropriately.

8

If you want to try to make this work now without any custom cards or anything, you could try simply creating two separate sensors, one for Wh and one for KWh, then use a conditional card to decide which one to show based on the value.

9

I would aim higher and ask for units handling for every numeric sensor. Then graphing etc would have no problem. For example, all temperature values could be stored in Celsius but converted to Farenheit when needed on the frontend sensor or on a graph. Or the unit in the backend could be stored along each value, so that it can be converted for display on the frontend.

The are many issues with the weather component for example with units.

https://github.com/home-assistant/architecture/issues/132

10

but that’s another issue, and a plain error. the data is in meters/second, while the shown unit is km/hr…
tbh I don’t understand why that isn’t fixed immediately and a so called architectural discussion is needed to see the error and fix it.

I do agree mixing units could be confusing. Merely showed a way one can do it in the frontend.

11

I agree, but these errors arise, IMO, due to the fact that each platform must implement unit conversions independently. If there was a better units strategy, it would be trivial to address across every component and platform.

12

Yes this will be a good solution for me.
I will display the original value till it gets to 1000Wh then use a template to set an entity for switching mode to display the KWh entity.

13

Sorry for reviving an old thread, but one clear application for this would be internationalization. E.g. gallons vs. liters, km vs miles, etc, etc…

It does not have to change runtime, but at least at start/boot time. It could even clear the DB if that is a problem.

Is there a generally accepted solution for that?

CustomUI seems to be undergoing major changes, and it’s not clear to me that is something I should be betting on since it’s not HA core… can someone confirm?

14

I guess this PR would address the issue I’m trying to solve, but it’s abandoned apparently.