The 'entity_id' option is deprecated, please remove it from your configuration

[CaptTom (Tom)]

Just updated to 0.115. So far so good, and I’m impressed with all the positive changes!

Only one minor (I hope) issue. I’m getting this warning in the log:

Logger: homeassistant.components.template.sensor
Source: helpers/config_validation.py:752
Integration: template (documentation, issues)
First occurred: 7:50:02 AM (7 occurrences)
Last logged: 7:50:03 AM

The 'entity_id' option is deprecated, please remove it from your configuration

I’ve got quite a few templates. 17 of them have entity_id entries. Yet the log says “7 occurrences” without indicating which 7. I didn’t see anything in the release notes indicating a change, and in fact, several of the examples use entity_id.

I did search for this, and wasn’t able to find anything which seemed to fit.

Any ideas as to what I’m missing?

[eXtatic (Dominik 🇩🇪)]

Watch out for “Templates” in the Braking Changes

[Piggyback (René)]

I found i had them in the sensor section where I used new sensors for specific attributes. Just taking out these lines.

Example. I had this sensor definition:

      vacuum_battery:
        friendly_name: Battery
        entity_id:
          - vacuum.xiaomi_vacuum_cleaner
        value_template: 'Battery: {{ states.vacuum.xiaomi_vacuum_cleaner.attributes.battery_level }}'
        unit_of_measurement: '%'
        icon_template: '{{ states.vacuum.xiaomi_vacuum_cleaner.attributes.battery_icon }}'

only had to remove the 2 lines related to the entity_id into:

      vacuum_battery:
        friendly_name: Battery
        value_template: 'Battery: {{ states.vacuum.xiaomi_vacuum_cleaner.attributes.battery_level }}'
        unit_of_measurement: '%'
        icon_template: '{{ states.vacuum.xiaomi_vacuum_cleaner.attributes.battery_icon }}'

[wmaker (Tommy Long)]

Thanks for this. I read about the breaking change, but couldn’t quite understand it and needed an example like yours.

[CaptTom (Tom)]

Thank you for the quick replies!

@eXtatic

Watch out for “Templates” in the Braking Changes

I searched that. Nothing about entry_id. None of the mentions of “template” seemed to apply. Did I miss something?

I’m concerned that if I remove the “entry_id” line (mine are all on one line) then I’d break other things which use that ID. What I’d really like to see is the description of the specific change which introduced this warning message. Maybe then I’d understand what’s going on.

Meanwhile, as I said, I have 17 “entry_id” lines, but the log only complained about 7 of them. Any idea how I could figure out which seven?

[eXtatic (Dominik 🇩🇪)]

[sender]

taking out the entity_id I understand… but why was it in at first then and what changes after taking it out…?

I get the message also after updating to 115.

[123 (Taras)]

I mentioned the deprecation of entity_id for Template Sensors in this post (~ 3 weeks ago):

Heads up! Upcoming breaking change in the Template integration

NOTE 2: Guidance for 0.116 and upcoming changes in 0.117 0.116 introduced improvements to mitigate performance problems reported by some users of 0.115 for templates containing states and states.DOMAIN. There are now built-in rate-limits that prevent excessive processing. If your template refers to states, any entity in your entire system that changes state will cause the template to be evaluated (updated). 0.116 ensures evaluations cannot happen more than once a minute. In 0.117 the rate-lim…

It’s much more difficult to find it in the release notes for 0.115.

If entity_id contains entities you can easily identify within the actual template, you can safely remove it. However, if entity_id contains entities not listed within the template, you will have to remember why you did that because now those entities must be incorporated within the template. In this particular case, simply removing entity_id is likely to negatively affect the Template Sensor.

[sender]

Ok… and what do I need to do? Just delete that line with entity_id?

[123 (Taras)]

You can’t just blindly remove it without first understanding why you put it there in the first place and what are the consequences of removing it now.

Worst case consequence of simply removing entity_id from a Template Sensor is:
The Template Sensor stops working.

[SteveDinn]

I have the following binary sensor which indicates whether there was any motion on any of my motion sensors:

binary_sensor:
  - platform: template
    sensors:
      housewide_movement:
        friendly_name: House-wide movement
        device_class: motion
        entity_id:
          - binary_sensor.kitchen_motion
          - binary_sensor.livingroom_motion
          - binary_sensor.recroom_motion
          - binary_sensor.office_motion
          - binary_sensor.garage_motion
        value_template: >
          {% for state in states.binary_sensor
            if state.object_id.endswith('_motion')
            and (state.state == 'on')
          %}
            {% if loop.first %}
              {{ true }}
            {% endif %}
          {% endfor %}

If I have to remove the entity_id section, it’ll trigger on all binary_sensor updates instead of only the ones that matter. That’s unfortunate. I think I will have to replace this with an automation that manually updates the sensor when one of the applicable sensors is tripped.

[petro]

No, just move your list into the template or make a group using expand. Making a group is probably the easiest because your template just changes to

group:
  my_binary_sensors:
    entities:
          - binary_sensor.kitchen_motion
          - binary_sensor.livingroom_motion
          - binary_sensor.recroom_motion
          - binary_sensor.office_motion
          - binary_sensor.garage_motion

binary_sensor:
  - platform: template
    sensors:
      housewide_movement:
        friendly_name: House-wide movement
        device_class: motion
        value_template: >
          {% for state in expand('group.my_binary_sensors') 
            if state.object_id.endswith('_motion')
            and (state.state == 'on')
          %}
            {% if loop.first %}
              {{ true }}
            {% endif %}
          {% endfor %}

[petro]

It’s an extremely complicated change and discussed in great detail in this thread by @123.

[SteveDinn]

If I use the groiup, I can just do

{{ is_state('group.motion_sensors', 'on') }}

[SteveDinn]

I kind of liked the idea of being able to use an entity’s state in a template sensor, but not have it necessarily cause the state of the sensor to update. Like, I might want to use the value of sensor.time in a template sensor, but not necessarily have it update every minute.

Oh well, can’t please everybody. I’m probably an edge case.

[CaptTom (Tom)]

@123

You can’t just blindly remove it without first understanding why you put it there in the first place and what are the consequences of removing it now.

I put it there because that’s what all the examples in the documentation said to do.

@123

Worst case consequence of simply removing entity_id from a Template Sensor is:
The Template Sensor stops working.

I guess it comes back to my initial question, which is how would I know which seven entity_ids failed? If the warning messages told me that, I could start to answer those other questions.

In the end, I think I found seven templates which didn’t seem to need an entity_id, and everything seems to be OK after commenting them out. At least, no more warnings in the log. But I don’t really feel like I’ve learned anything, and I can’t help but wonder whether the other ten entity_id lines in my configuration.yaml are going to cause a future problem.

[petro]

@CaptTom

I guess it comes back to my initial question, which is how would I know which seven entity_ids failed? If the warning messages told me that, I could start to answer those other questions.

The warning is telling you that the field is deprecated, not that the sensors failed. The field is not being used currently. So you can tell that the sensors ‘failed’ if they aren’t updating properly.

@CaptTom

and I can’t help but wonder whether the other ten entity_id lines in my configuration.yaml are going to cause a future problem.

Are those 10 other entity_id fields in template sensors of any kind? If yes, then they should be removed when prompted.

[123 (Taras)]

My post was in reply to sender’s question:

@sender

Ok… and what do I need to do? Just delete that line with entity_id?

If whatever you removed had sensor.time or sensor.date (or similar) in it, that Template Sensor is probably no longer being updated periodically.

[sender]

So I have it in an automation…

How do I get rid of it?

- id: brightness
  alias: 'Brightness'
  trigger:
    platform: state
    entity_id: input_number.brightness
  action:
  - service: light.turn_on
    entity_id: light.dimmer_712
    data_template:
      brightness: "{{ states('input_number.brightness') | int }}"

[petro]

… that’s not a template sensor. This doesn’t apply.