Template sensors with non-numeric values causing warnings

Configuration
,
1

I’ve got a number of template sensors that have somewhat unconventional unit of measurement (specifically to show in a badge). They repeatedly cause warnings in my logs, which I’d like to avoid/eliminate.

One example:
Sensor sensor.sunrise has device class None, state class None and unit ˄ thus indicating it has a numeric value; however, it has the non-numeric value: 06:26 (<class 'str'>); Please update your configuration if your entity is manually configured, otherwise create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+template%22

Is there a way to avoid this warning, knowing the unit of measurement will cause HA to expect a numeric value, but not getting one?

2

Yes. Configure your sensor correctly.

Your sensor stores either a string or a timestamp device class. Neither are numeric, so remove the unit of measurement from its configuration.

3

I could remove the UoM, but then my usecase for the whole sensor is gone… this is the unit I’d like to show in the lovelace badge.
I guess I’m either looking for the badge to have a customizable UoM (or text in that part of the badge), or a way to avoid this warning when customizing the UoM in the template sensor.

4

Show your sensor config. We may be able to concatenate the unit to the measurement and remove the UoM from the config. As long as you never want to graph it.

5

These are my template sensors it complains about:

  - name: "Sunrise"
    unit_of_measurement: ˄
    icon: mdi:weather-sunset-up
    state: >
      {{ states.sensor.sunrise.state }}
  - name: "Sunset"
    unit_of_measurement: ˅
    icon: mdi:weather-sunset-down
    state: >
      {{ states.sensor.sunset.state }}
  - name: "Working"
    unit_of_measurement: "@ Home"
    icon: mdi:briefcase
    state: >
      {% if is_state('device_tracker.werk_laptop_n', 'home') and is_state('device_tracker.werk_laptop_j', 'home') %}
        J & N
      {% elif is_state('device_tracker.werk_laptop_n', 'home') %}
        N
      {% elif is_state('device_tracker.werk_laptop_j', 'home') %}
        J
      {% else %}
        -
      {% endif %}

And then there’s one SQL sensor with “°C” as UoM.

6

Try this:

  - name: "Sunrise"
    icon: mdi:weather-sunset-up
    state: >
      {{ states('sensor.sunrise') ~ " ˄" }}
  - name: "Sunset"
    icon: mdi:weather-sunset-down
    state: >
      {{ states('sensor.sunset') ~ " ˅" }}

Also you should take note of the warning box here: https://www.home-assistant.io/docs/configuration/templating/#states

IMG_0822
IMG_08221385×373 111 KB

7

Thank you Tom,

It’s a bit of a visual preference, where I want the badges to all have a UoM between the value and the name. This puts the indicator inside the badge after the time, which keeps the UoM visible, but less visually pleasing. I’m ok to have the warning in the logs, if I can’t avoid it; I was just wondering if I could clean my logs / avoid the warning, while maintaining the visual consistency of the badges.

And thanks for the pointer on using states in templates. I knew I’d read that at some point, but I guess I hadn’t removed it from all templates.

8

Hey fellas. Apologies for bumping an old thread, but in case any one is interested, I have a solve.

As seen in the situation above, any sensor with a non-numeric value cannot have a Unit of Measurement (UoM) as it is not supported any more. As with @JvH, my dasboard also consists of a lot of badges, which I was using for non numeric purposes, such as power toggle. See my post (again an older one) - https://community.home-assistant.io/t/template-sensors-not-showing-up-after-updating-to-2023-6-1/580912/6. Due to this, I have been running on 2023.4.0.

Today, I finally upgraded to 2024.2.2, and as expected, faced the same issue again. However, I have managed to figure out a work around. Try these steps out:

  • In the non numeric sensor code, add the availability function. Just make sure that the entity is one which will ALWAYS a non numeric value so the sensor would be unavailable. Just add a light or fan entity. This will cause the sensor to be forever unavailable and instead of not working, it will be displayed as an unavailable badge. See below:

unavai

My code reads like this:

  - sensor:
      - name: "Bedroom Fan Sensor"
        unit_of_measurement: "Fan"
        state: >
          {% if is_state('light.bedroom_fan', 'off') %}
            Off
          {% elif is_state('light.bedroom_fan', 'on') %}
            On
          {% else %}
            Offline
          {% endif %}
        availability: "{{ is_number(states('light.bedroom_fan')) }}"

Now that we have the badge displaying as unavailable, we just need to change its value to “On” or “Off”. If you go to Developer Tools > States, and then change the value manually, you’ll see that the badge is displayed exactly as before. The key is to now automate the state change of this unavailable sensor on the basis of the entity it represents. However, there is no function in HA which allows us to do this.

A quick search led me to this video - https://www.youtube.com/watch?v=V2-bwsTLjh4 which walks you through installing a small Python script which creates a service we can use to set the state

Follow the instrunctions in the video and you will end up with a service named “python_script.set_state”. You can use this to change the state of the unavailable sensor. All that needs to be done is to create an automation which sets the required state. Here’s the code I am using

alias: Hack - Set UI Fan Sensor Value as per fan state
description: ""
trigger:
  - platform: state
    entity_id:
      - light.bedroom_fan
condition: []
action:
  - service: python_script.set_state
    data_template:
      entity_id: sensor.bedroom_fan_sensor
      state: "{{trigger.to_state.state | title}}"
mode: single

fan

This has worked beautifully for me and I just had to share it with the community. I hope this helps.

Cheers