Template sensor no longer working

Configuration
1

I’ve been using this template sensor for a long time and only recently noticed that it broke a few versions back. In the template tester/editor it works fine but the actual sensor is always blank.
Any ideas?

on_light_list:
  friendly_name: some_name
  value_template: >
    {% for light in states.light %}
      {% if ((light.state == "on") and (light.attributes.friendly_name != 'entity_to_exclude')) %}
        {{ light.attributes.friendly_name }}
        {% if not (loop.last) %}
        ,
        {% endif %}
      {% endif %}
    {% endfor %}

Thanks

2

You need to list out all the lights the template is expected to use. This was a breaking change a few weeks back in the release notes.

Also, you can tighten that up a bit if you’re interested:

on_light_list:
  friendly_name: some_name
  value_template: >
    {{ states.light | selectattr('entity_id', '!=', 'entity_to_exclude') | selectattr('state','eq','on') | map(attribute='name') | join(', ') }}
3

Thanks. Where can I read about the breaking change and understand what changed?

4

I don’t remember where it is, but templates like that should have never worked.

How template sensors work is that create a ‘listener’ for each device they find in the template. They do this by searching for the entity_id. When they find an entity_id, they create a listener for that. When the listener says ‘Hey the state changed for my entity’, it then triggers the template to evaluate. Because you have 0 entity id’s in your template, it will never evaluate because you have no listeners.

By adding an entity_id: attribute between friendly_name and value template, you can list out all the lights you want to trigger the template off of.

1 Like
5

Got it. Many thanks!

6

One last note is to see how to prevent this from working in the template editor. That one threw me off…

7

Yeah, the template editor won’t see this issue because you the user are triggering the template. So it will always appear to work.

8

I think another great improvement for this scenario is to support wildcards in sensor->entity_id. To now have to list all light entities is stupid and if I add something new I will surely forget to update this list.

9

They added a new update sensor service. So you could build an automation to cause that to trigger.

10

Yes I saw that but listening to STATE_CHANGED for the entire system only when seeking light changes which are more rare seems crazy to me… Even though the RPI is mostly doing nothing. I’ll think about it.

11

You can build an automation to search for the state change event and then fire an update if it contains a light domain.

12

OK. Thanks.

13

Thanks yet again! This is the clearest explanation of how template_sensors perform their magic and why (since 0.81) they need to have entity id’s explicitly defined.

I don’t mean to thread-jack but perhaps you have a moment to shed light on a question I posted in another thread. Someone created a template_sensor that triggers on an entity’s attribute (one of its very many attributes).

  • It’s the ELK M1 component and the entity is alarm_control_panel.area001.
  • The template’s trigger is states.alarm_control_panel.area001.attributes["alarm_state"]

So this isn’t a basic entity with a simple state of on/off but one with many attributes. Does this make the listener’s task more complex? Or is it just a matter of monitoring changes to the entity’s state and any changes in its attributes list.

14

feel free to adapt this;-)

- alias: 'State changed Light'
  id: 'State changed Light'
  initial_state: 'off'
  trigger:
    platform: event
    event_type: state_changed
  condition:
    condition: template
    value_template: >
      {{ trigger.event.data.entity_id in state_attr('group.all_lights_only','entity_id') }}
  action:
    - delay:
        seconds: 2
    - service: python_script.whats_on
    - delay:
        seconds: 2
    - service: python_script.summary
15

Yep, something similar to that. Accept @Joseph_Levy would be using the new homeassistant.update_entity service.

16

which is a cool new service indeed: I use that on 1 spot now, which is after repowering the printer to enter Office mode… the command_line scrape sensors of the ink level aren’t set then and it only updates every 14400 seconds…
using this little script in the to_work automation settles that nicely:

script:
  update_epson_cartridge_sensors:
    alias: Update Cartridge sensors
    sequence:
      - service: homeassistant.update_entity
        entity_id: sensor.epson_ink_level_black
      - service: homeassistant.update_entity
        entity_id: sensor.epson_ink_level_cyan
      - service: homeassistant.update_entity
        entity_id: sensor.epson_ink_level_magenta
      - service: homeassistant.update_entity
        entity_id: sensor.epson_ink_level_yellow
      - service: homeassistant.update_entity
        entity_id: sensor.epson_ink_level_waste