Deprecation of legacy template entities in 2025.12

Configuration
1342

as i politely pointed out, this guide did not make it clear to me. I also clearly said that it is my fault. This is written in the form of a forum post rather than a guide or in the docs made available on the home-assistant.io website. (ignore the other link as anything else clearly brings out allergic reactions.
The code suggested is useful (even if the formatting is then all messed up, if i copy paste from the message in home-assistant), but, given we have many sensors, it would be nice to gain better understanding. The question was simple and woudl help people understand the underlying rational and learn what should be done now.

Calling anything “random” is a little rude given so many people put effort into this project but whatever.

1343

I’m frustrated because I can see you did not click on the link, that tells me you haven’t used the guides in the official documentation on home-assistant.io.

image
image772×234 19 KB

Here’s the link again.

Please try to use those guides before asking questions. And if you have problems, mention which guide you’re using (there is 3 of them) and what you’re confused about.

Sorry, it’s not rude. That person created a guide off incorrect information. It is a random guide and it likely gets things wrong.

1344

ok thanks, will read again. I have several browsers open and i did read the links but nevermind. thansk for the pointers. much appreciated! As i said, it is no ones fault but mine. but i DID make an effort reading.
I am sorry you are getting frustrated answering newbies is understandable but I thought the forum is to help all.
But seriously, thank you for being here to help.

1346

No it hasn’t, you could still use the legacy format.

But it will be the case once the depreciation comes into effect, in 6 months.

Also this was answered already (and correctly too), 2 weeks ago.

1 Like
1347

hi,

today i updated from 2025.9 to 2026.1 and was shocked by 61 repairs due to “Legacy sensor template deprecation” :sob:WWHHYYY?:sob::sob:

is it possible to mix old and new style in sensor yaml, so i could do one sensor by one? or do i have to clean up all at same time?:tired_face:

e.g. …both in same sensor.yaml?

#old depreciated, but not still migrated
  - platform: template
    sensors:
      # Template sensor for values of power import (active_power > 0)
      power_import:
      ...
#other one, migrated yet...
  - default_entity_id: sensor.power_export
    unit_of_measurement: W
    ...

.
.

…and what are this “\n” and “backslashes” in state: of repair dialog for? should i clean it up? or could i use simply my old value_template: statement 1:1 for the new state: statement, but only clean up the rest indention and notations?

#migrated example from repair dialog
template:
- binary_sensor:
  - device_class: door
    default_entity_id: binary_sensor.regensensor_contact_invert
    state: "{% if ( (is_state('input_boolean.rainsensor_mainswitch','on')) ) %}   \n
      \ {{ is_state('binary_sensor.aqara_rs_59_contact', 'off') }}\n{% elif ( (is_state('input_boolean.rainsensor_mainswitch','off'))
      ) %}   \n  {{ is_state('binary_sensor.aqara_rs_59_contact', 'unavailable') }}\n{%
      endif %}\n#{{ is_state('binary_sensor.aqara_rs_59_contact', 'off') }}"
    name: regensensor_contact_invert

#old sensor, from configuration.yaml
binary_sensor:
# RAIN binary_sensor start
  # restartsafe invertsensor
  - platform: template
    sensors:
      regensensor_contact_invert:
        value_template: >-
          {% if ( (is_state('input_boolean.rainsensor_mainswitch','on')) ) %}   
            {{ is_state('binary_sensor.aqara_rs_59_contact', 'off') }}
          {% elif ( (is_state('input_boolean.rainsensor_mainswitch','off')) ) %}   
            {{ is_state('binary_sensor.aqara_rs_59_contact', 'unavailable') }}
          {% endif %}
  
          #{{ is_state('binary_sensor.aqara_rs_59_contact', 'off') }}
        device_class: door

#new cleaned up for config.yaml
- binary_sensor:
  - default_entity_id: binary_sensor.regensensor_contact_invert
    state: 
         " {% if ( (is_state('input_boolean.rainsensor_mainswitch','on')) ) %}   
            {{ is_state('binary_sensor.aqara_rs_59_contact', 'off') }}
          {% elif ( (is_state('input_boolean.rainsensor_mainswitch','off')) ) %}   
            {{ is_state('binary_sensor.aqara_rs_59_contact', 'unavailable') }}
          {% endif %}"
    name: regensensor_contact_invert
    device_class: door

thanx in advance
br
Frank

1348

No. The new sensors do not go in your sensors.yaml file. Please read the first post in this topic and the migration guides here: Template - Home Assistant

Yes you can migrate them one by one. Or all at once using the provided add-on.

1349

@FrankRy
The \n is added because of the YAML parser used in Home assistant. You can use the custom integration (not an add-on @tom_l) :stuck_out_tongue_winking_eye:) which doesn’t mess up the formatting

1 Like
1350

I think I’ve got something similar (from the ha-ultrasync integration - GitHub - caronc/ha-ultrasync: Interlogix ZeroWire and Hills ComNav (NX-595E) UltraSync Security Panel for Integration for Home Assistant Comunity Store (HACS)) and I have no idea how to make this compliant before it disappears in 2026.6.

Can anyone help point out what changes need to be made, as the ‘suggestion’ from the Home Assistant Repairs section didn’t work.

#Alarm Config to Allow Homekit Integration
alarm_control_panel:
  - platform: manual
    name: ultrasync_alarm_ghost
    code_arm_required: false
    arming_time: 0
    delay_time: 0
    trigger_time: 300
    disarmed:
      trigger_time: 0
    armed_away:
      arming_time: 30
      delay_time: 20
    armed_home:
      arming_time: 15
      delay_time: 10
  - platform: template
    panels:
      ultrasync_alarm:
        value_template: "{{ states('alarm_control_panel.ultrasync_alarm_ghost') }}"
        code_arm_required: false
        arm_away:
          service: alarm_control_panel.alarm_arm_away
          target:
            entity_id: alarm_control_panel.ultrasync_alarm_ghost
        arm_home:
          service: alarm_control_panel.alarm_arm_home
          target:
            entity_id: alarm_control_panel.ultrasync_alarm_ghost
        disarm:
          service: alarm_control_panel.alarm_disarm
          target:
            entity_id: alarm_control_panel.ultrasync_alarm_ghost
1351

Leave the manual alarm platform as is. Comment out the template platform alarm panel and use this example to rebuild it: https://www.home-assistant.io/integrations/template/#alarm-control-panel in configuration.yaml.

1352

I haven’t touched my configuration.yaml in a long time and am deathly afraid I’m going to screw this up because my usage is a little different with a combination of switch and light and my knowledge of YAML is weak :frowning:

switch:
  - platform: template
    switches:
      gosundsw6_1_inverted:
        value_template: "{{ is_state('switch.gosundsw6_1_toggle1', 'off') }}"
        turn_on:
          service: switch.turn_off
          entity_id: switch.gosundsw6_1_inverted
        turn_off:
          service: switch.turn_on
          entity_id: switch.gosundsw6_1_inverted

light:
  - platform: template
    lights:
      treatlife1_light: # front porch lights
        friendly_name: "Treatlife1 Light"
        value_template: >-
          {% if is_state('switch.treatlife1_toggle1', 'off') %}
            off
          {% else %}
            on
          {% endif %}
        icon_template: >-
          {% if is_state('switch.treatlife1_toggle1', 'off') %}
            mdi:lightbulb-off
          {% else %}
            mdi:lightbulb-on
          {% endif %}
        turn_on:
          service: switch.turn_on
          data:
            entity_id: switch.front_porch_lights
        turn_off:
          service: switch.turn_off
          data:
            entity_id: switch.front_porch_lights

      treatlife2_light: # Unused/broken
        friendly_name: "Treatlife2 Light"
        value_template: >-
          {% if is_state('switch.treatlife2_toggle1', 'off') %}
            off
          {% else %}
            on
          {% endif %}
        icon_template: >-
          {% if is_state('switch.treatlife2_toggle1', 'off') %}
            mdi:lightbulb-off
          {% else %}
            mdi:lightbulb-on
          {% endif %}
        turn_on:
          service: switch.turn_on
          data:
            entity_id: switch.treatlife2_toggle2
        turn_off:
          service: switch.turn_off
          data:
            entity_id: switch.treatlife2_toggle2

Is the following the correct migrated configuration? Or should there be only one light section with the two lights indented?

template:
- switch:
  - turn_on:
    - entity_id:
      - switch.gosundsw6_1_inverted
      action: switch.turn_off
    turn_off:
    - entity_id:
      - switch.gosundsw6_1_inverted
      action: switch.turn_on
    default_entity_id: switch.gosundsw6_1_inverted
    state: '{{ is_state(''switch.gosundsw6_1_toggle1'', ''off'') }}'
    name: gosundsw6_1_inverted

- light:
  - turn_on:
    - data:
        entity_id: switch.front_porch_lights
      action: switch.turn_on
    turn_off:
    - data:
        entity_id: switch.front_porch_lights
      action: switch.turn_off
    default_entity_id: light.treatlife1_light
    icon: "{% if is_state('switch.treatlife1_toggle1', 'off') %}\n  mdi:lightbulb-off\n{%
      else %}\n  mdi:lightbulb-on\n{% endif %}"
    name: Treatlife1 Light
    state: "{% if is_state('switch.treatlife1_toggle1', 'off') %}\n  off\n{% else
      %}\n  on\n{% endif %}"

- light:
  - turn_on:
    - data:
        entity_id: switch.treatlife2_toggle2
      action: switch.turn_on
    turn_off:
    - data:
        entity_id: switch.treatlife2_toggle2
      action: switch.turn_off
    default_entity_id: light.treatlife2_light
    icon: "{% if is_state('switch.treatlife2_toggle1', 'off') %}\n  mdi:lightbulb-off\n{%
      else %}\n  mdi:lightbulb-on\n{% endif %}"
    name: Treatlife2 Light
    state: "{% if is_state('switch.treatlife2_toggle1', 'off') %}\n  off\n{% else
      %}\n  on\n{% endif %}"
1353

Do a backup before starting anything.

Don’t forget to comment out your old platform configs first.

Do a config check before restarting.

Looks good, assuming that is in your configuration.yaml and you don’t have template: anywhere else in that file.

Both ways are actually valid.

template:
 - light:
    - name: etc...

 - light:
    - name: etc...

Or

template:
 - light:
    - name: etc...

    - name: etc...

Use the one you prefer. I Use the latter as I use !includes for each entity type.

1354

I used the first option and it worked great!

Now to figure out what (independently) broke in my hydrawise integration.

Thanks.

2 Likes
1355

I have 3 sensors that I’m trying to fix per the repair action items, but I’m copying the exact code it gives me and deleting the old stuff, and I get a “Property default_entity_id is not allowed” error in the yaml for all 3. No idea what to do.

1356

Please follow one of the migration guides. Keep in mind, that VSCode will lie and say things are not available when they actually are.

1357

Oh… damn… yeah, Studio Code Server is a complete liar! The sensors look fine. Thank you! I was baffled how it was erroring on the exact code the system gave me. I wonder if it’s the fact that mine is extremely out of date (5.1.2)

Edit: Yep, I updated the addon and it doesn’t show an error anymore. Classic case using an ancient version causing bizarre issues, I’ve had the same with ESPHome Builder.

1 Like
1358

5 repairs for me.

And lo and behold, comments in yaml

praise be

1359

?

Comments were always supported in YAML. It’s the UI where they are not supported.

Also supported in jinja if you use {# comment here #} instead of just #

1360

Rip me apart or flame me for whatever if you need to - but after 6 hours yesterday trying to upgrade / ‘fix’ templates in 2026.1.2 and subsequently finally getting 2025.11.3 to revert last night (let’s not talk about a failed backup recovery in ProxMox), I officially HATE this template update. I have 402, yes 402 of them to fix. What a nightmare this whole update it. Fixing stuff that wasn’t broken yesterday and was intentionally ‘updated’ has to be my absolute LEAST favorite part of HA.

1361

402 across sensors, binary_sensors, covers and switches.

1362

Use the custom integration, follow the directions step by step. It should take no longer than 10 minutes to create the new entities. Unfortunately, you still need to manually remove the old entities. Just search your config for platform: template and remove all the lines associated with that key pair.

EDIT: Do not remove platform: template key pairs from automation or script sections. Only from your config