Template Switch broken in 0.113.x?

Configuration
1

Hi,

I have defined a template switch for “all_lights” that is in ON state when any of my lights are turned on and otherwise off:

platform: template
switches:
  all_lights:
    value_template: >
      {% set domain = 'light' %}
      {% set state = 'on' %}
      {{ states[domain] | selectattr('state','eq', state) | list | count > 0 }}
    turn_on:
      service: shell_command.nop
    turn_off:
      service: light.turn_off
      data:
        entity_id: all

Since 0.113 the switch state does not seem to be updated anymore, rendering it useless.
If it’s off, turning on any light will not make it switch to the on position.
If it’s on, turning off all my lights will still leave the switch on.

Here’s a screenshot from the template editor, showing that the switch state does not correspond to the result of the template evaluation:

88475589-c0032480-cf31-11ea-9129-093613870dc8
88475589-c0032480-cf31-11ea-9129-093613870dc81900×496 59.8 KB

I have already opened a bug report, but no one seemed to care, so far.

Am I the only one having this issue?

Sebastian

2

you may need to list the entity ids to monitor for your template switch to work…

There was a breaking change in 0.113 but I’m not sure if it’s related to your issue…

3

Thanks for pointing that out!
I remember reading this, thinking “what the hell are they trying to tell me about extracting entities?”.
Still have no clue if that’s related to my problem, but it might be.
But what do I need to do to fix it?
Maybe @bdraco knows more?

Edit: I just saw that you suggested to list all the entities to monitor.
That would be really annoying as the purpose of the switch is to emulate the former all_lights group which I used to refer to, well, all lights without having to list them explicitely.

Sebastian

4

extract_entities isn’t smart enough to find the entities based on that template so it won’t be able to determine which entities to monitor.

5

Use a light group instead of a template switch?

It will be on if any of the lights are on and can control all the attributes of the members.

6

So what is this extract_entities? Is this some internal function related to template processing?
Why was it smart enough prior to 0.113 and suddenly is not anymore?
The template evaluates as expected inside the template editor - what’s keeping the platform evaluating that template periodically?
Imagine I know how to use templates, but have not the slightest idea how they work under the hood…

I’m assuming the change is a performance-optimization thing?
Would it be possible to add a user-configurable option to get the old behavior back (accepting a possible performance impact)?

@tom_l:
The point is that I really would rather not have to manually maintain a list of all my currently configured lights just to be able to fetch the information if any of them is turned on.
It makes no difference if I’d had to list them in a light group or in a template.

Sebastian

7

Well keep your fingers crossed 123 mentioned a PR to fix it has been submitted. No guarantee it will be merged though. See his EDIT at the bottom of this post: Template sensor: count number of enabled input_booleans using an IF statement

8

The previous behavior was to subscribe to state change events for every single entity on the system. Most of the template entities have moved away from this behavior because it has significant performance problems and caused other bugs. The light and switch template integrations were one of the last remaining ones to get this fix.

It would be better to add support for extracting by domain than adding a flag to get the old behavior back which I have implemented here:

9

Ok, thanks @bdraco and @tom_l!
At least I now know why it broke and that people are looking to find better solutions to fix it.
Again, as someone who has no idea how template processing is implemented, I always assumed that specifying something like states['light'] would automatically limit the “search space” to light entities only and not cause HA to create state listeners for all entities (which, I assume, are only then filtered for the specified domain when any entity’s state change).

Sebastian

10

I’m trying to understand the implications of the change. Can you comment on whether I’ve understood the following scenarios correctly?

Creates listeners for all lights.

{{ states.light
   | selectatttr('state', 'eq', 'on') | etc }}

Creates one listener for the group (or is it multiple listeners, one for each light entity within the group?).

{{ expand('group.my_lights')
   | selectattr('state', 'eq', 'on') | etc }}

Creates listeners for all lights (or is it just for the entities found within the group?) and a listener for group.lights.

{{ states.lights
   | selectattr('entity_id', 'in', state_attr('group.lights', 'entity_id')) | etc }}
11

Creates listeners for all light entities

{{ states.light
   | selectatttr('state', 'eq', 'on') | etc }}

Creates listeners for each entity in the group

{{ expand('group.my_lights')
   | selectattr('state', 'eq', 'on') | etc }}

Creates listeners for all light entities and group.lights

{{ states.lights
   | selectattr('entity_id', 'in', state_attr('group.lights', 'entity_id')) | etc }}
1 Like
12

This feature was introduced in 0.110 but failed to work (the Issue I had opened remains open). The author posted a PR to fix it but encountered a problem. There was no guarantee that, on startup, groups were defined before Template Sensors. His PR also remains open (you participated in it).

So when you say “Creates listeners for each entity in the group” is that based on recent improvements or on the assumption that it was included in 0.110? If it’s recent, which version has, or will have, it?

13

The code assumes the group is setup when the template is processed.

14

I just got notified that you closed my Issue via the PR which is now targeted for version 0.114.

Let’s assume I have a Template Sensor whose template expands a group. If I add an entity to the group, then execute Reload Groups, I believe that will not add another listener for the group’s new entity. I would need to restart Home Assistant so that it can re-evaluate the template (and create a listener for each group member, including the new one). Is that correct?

15

The template integration does not have a reload service, it does not listen for group reloads, and it does not know about new entities being added after it starts up.

The only current option is a restart for it to see the new entity.

16

I mentioned the same thing just 3 days ago:

We would need a two-step process: reload groups and then reload Template Sensors (unfortunately, that’s not a service that currently exists)

A reload service for Template Sensors would be a valuable addition. Unfortunately, I don’t have the requisite skills to write that PR.

17

FYI, I tested the new functionality in 0.114.0 and it didn’t work. I’ve opened an Issue.

A Template Sensor relying exclusively on state.light didn’t get any listeners and was flagged in the log:

Template sensor ‘v114_states’ has no entity ids configured to track nor were we able to extract the entities to track from the value, entities template(s). This entity will only be able to be updated manually

In addition, expand('group.lights') was assigned just one listener for the group itself and none of its members.

Basically, it behaves like all previous versions and not how PR Make sure groups are initialized before template sensors by Tho85 · Pull Request #37766 · home-assistant/core · GitHub intended. I posted my observations in the Issue and included the configs I used.