After update 2025.4.0 I do receive a state_class error for template sensor

Configuration
1

Since the update to 2025.4.0 I do receive an error that the state_class is missing for some template sensors.
If I do add a State class in the code it gives an error it is not allowed to give state class in template sensors.
my code:

- platform: template
  sensors:
    power_consumption_watt:
      friendly_name: "Power Consumption Watt"
      unit_of_measurement: "W"
      icon_template: "mdi:flash"
      value_template: "{{ ((states('sensor.dsmr_reading_electricity_currently_delivered') | float * 1000) - (states('sensor.dsmr_reading_electricity_currently_returned') | float * 1000)) }}"

    convert_gas:
      friendly_name: 'Convert Gj naar gas mÂł'
      unit_of_measurement: "mÂł"
      value_template: "{{ states('sensor.gj')|float * 0.0316 }}"
      device_class: 'gas'

If i do add:
state_class: total_increasing
to the code I do get an error that this is not allowed??

How to add a state_class to these sensors?

2

Convert them into the UI or move them to the new template style. Legacy template style does not support state_class.

3

Conversion from the legacy template sensor platform to the new template integration example for you:

configuration.yaml (not sensors.yaml):

template
  - sensor:
      - name: "Power Consumption Watt"
        unique_id: power_consumption_watt
        state_class: measurement
        device_class: power
        unit_of_measurement: "W"
        icon: "mdi:flash"
        state: "{{ ((states('sensor.dsmr_reading_electricity_currently_delivered') | float * 1000) - (states('sensor.dsmr_reading_electricity_currently_returned') | float * 1000)) }}"
        availability: "{{ has_value('sensor.dsmr_reading_electricity_currently_delivered') and has_value('sensor.dsmr_reading_electricity_currently_returned') }}"

      - name: 'Convert Gas'
        unique_id: convert_gas
        unit_of_measurement: "mÂł"
        device_class: 'gas'
        state_class: total_increasing
        state: "{{ states('sensor.gj')|float * 0.0316 }}"
        availability: "{{ has_value('sensor.gj') }}"

Note I have changed the second sensor’s name. This is so that it has the same entity id as before. The entity id is generated from the name.

4

Thank you very much.
One more question:
What is availability doing?

5

If the availability template resolves to false because one of your source sensors is not returning a number then the state template is not evaluated (which would cause an error or odd reading) and the template sensor is marked as unavailable. Why an availability template is important for energy template sensors

6

Thanks clear for me

7

I do like to ask another question about the new sensors if allowed.
I do have a lot of legacy build sensors, so I try to change them to the new standard.
Thats working well, but I do have one situation I do not understand:
I do have an old sensor:

    mancave_licht:
      value_template: >
        {{ area_entities('Mancave')
          | select('match', 'light') | expand
          | selectattr('state', 'eq', 'on') | list | count }}  
      unit_of_measurement: "on"
      friendly_name: "aantal lampen mancave"

And did translate it to:

    - name: "aantal lampen mancave"  
      unique_id: mancave_licht
      state: >
        {{ area_entities('Mancave')
          | select('match', 'light') | expand
          | selectattr('state', 'eq', 'on') | list | count }}  
      unit_of_measurement: "on"

Then I do receive an error in my card:
ButtonCardJSTemplateError: TypeError: Cannot read properties of undefined (reading 'state') in 'if (states["sensor.mancave_licht"].state > 0) return <ha-icon icon=“mdi:lightbulb” …'`
What can be the reason for this error?

8

You have an error in a button card template. Not sure how that template ever worked because states are strings and you’re comparing to a number.

9

Yes sorry about that it was a string, but because the error I tried to change to number
I checked on entitie sensor.macave_licht. It is not existing, so not created by the sensor It is creating sensor.aantal_lampen_mancave instead
So I conclude that unique_id is not creating the sensor name

EDIT again:

    - name: "mancave licht"  
      unique_id: aantal lampen mancave
      state: >
        {{ area_entities('Mancave')
         | select('match', 'light') | expand
         | selectattr('state', 'eq', 'on') | list | count }}  
      unit_of_measurement: "on"

is creating:
image

So my conclusion is that unique_id is doing nothing.
The sensor name is created from name.
At Unique Id the template description says:
The unique ID for this config block. This will be prefixed to all unique IDs of all entities in this block.
To be honest I do not understand what that means

10

Unique_id is an id in the system that lets HA know what configuration it is. It does not generate the entity_id unless you omit a name. The entity_id is generated from name. If you remove unique_id, you risk getting duplicate entities sensor.mancave_licht, sensor.mancave_licht_2, etc every time you reload templates. Unique_id prevents that and allows you to modify the entity in the UI.

11

Thanks again. That makes sense.
Is it possible to create somehow a friendly name from template sensor? Or must that be happening in the UI?

12

I don’t follow you. Are you asking if name is templatable?

13

Yes as your sensor has a unique id you can change the name in the UI without affecting the entity id.

Old way you could have a different name to entity id. New way the entity id is generated from the name. So if you want a different name to entity id you either have to use manual customization (not recommended) or make sure the sensor has a unique id so you can change the name to whatever you want in the UI.

14

Yes, I understand that, but I don’t gather that from his question.

15

:man_shrugging: I guess we wait for an answer from them.

16

Rereading the question, I think he is asking what you’re answering

17

Yes that was the question.
In the old method friendly_name was possible to set in yaml.
Now we need to do it in the HA ui.
Thanks for the answer

18

I’m going to attempt to reintroduce this ability in the modern style templates. Not making any promises though, historically it’s been rejected. However it’s unclear if it was rejected because of the implementation or principle behind the field.

If it gets accepted, it will be in a future release (not 2025.4).

2 Likes