core: Template editor hangs Home Assistant

The problem

testing templates in editor in 115.0-115.3 very tricky -making mistake in template you are getting hanging system, only container restart via portainer helps. below you can find log at the moment of testing. I think test environment should not lead to system reboot at any case

Environment

Home Assistant Core release with the issue: 115.3 (same on 115.0 - 115.2)
Last working Home Assistant Core release (if known): 144.4
Operating environment (OS/Container/Supervised/Core): Ubuntu Supervised (same on deb10 supervised)
Integration causing this issue: ??
Link to integration documentation on our website:

Problem-relevant `configuration.yaml`

evaluating this kind of templates leads to system hangs (even not able to save config files from IDE addon)


      - service: notify.telegram
        data_template:
          message: >
            {% set time_limit = as_timestamp(now())-4*60*60 %}
            {% set missing = states | selectattr('attributes.last_seen', 'defined') | selectattr('attributes.linkquality', 'defined')| selectattr('attributes.last_seen','<', time_limit*1000 ) | map(attribute='attributes.device.friendlyName') | unique | list  | join(', ') %}
            {% set missing_count = states | selectattr('attributes.last_seen', 'defined') | selectattr('attributes.linkquality', 'defined')| selectattr('attributes.last_seen','<', time_limit*1000 ) | map(attribute='attributes.device.friendlyName') | unique | list | count %}
            {% set z2m_uptime = ((states('sensor.zigbee2mqtt_bridge_uptime')|int) / 3600)|round(1) %}
            {% set z2m2_uptime = ((states('sensor.zigbee2mqtt2_bridge_uptime')|int) / 3600)|round(1) %}

            {% if missing_count >0 %}{{"\U0001f4f6"}} 4 часа (аптайм z2m: {{z2m_uptime}}ч, z2m2: {{z2m2_uptime}}ч) нет ответа от: {{ missing }}
            {%else%}{{"\U00002705"}}Все устройства доступны!{%endif%}

Traceback/Error logs

Additional information

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 5
Comments: 34 (21 by maintainers)

Most upvoted comments

@bdraco This may be related, I’ve noticed that listeners are set to all states when using states.domain.object_id with an object_id that is not present on the system (i.e. a typo). Is this intended or a bug?

@Petro31 That is intended because we don’t know if the entity is about to be added. If it really is a typo it doesn’t cost much since its storing a dict key/value that which has near O(1) performance and since we will never get a state changed event for an entity that doesn’t exist its not really an issue.

bdraco on Sep 28, 2020

Please do not spam this issue with discussion about entity_id being brought back. I’ve hid these comments. Next occurrence will result in a ban. This is the issue tracker, not for feature requests. The only thing you guys are achieving is that you are harassing someone who is actually trying to solve the problems. That’s not something we accept in this community.

balloob on Sep 26, 2020

disabling the all states listener by default and implementing a flag allow_all_states_listener to turn it on seems a reasonable path forward

Instead of creating a new option, called allow_all_states_listener, which serves a single purpose, why not simply restore entity_id and allow it to accept states as a valid value? It would allow for more flexibility than a new, one-trick pony.

For example, this would, by default, not assign listeners to all entities:

  value_template: >
   {{ states | selectattr( ... etc ...

whereas this would (because entity_id overrides the default behavior for listener assignment):

  entity_id: states
  value_template: >
   {{ states | selectattr( ... etc ...

Alternately, this would assign a listener exclusively for sensor.time and replicate the behavior of all past versions:

  entity_id: sensor.time
  value_template: >
   {{ states | selectattr( ... etc ...

tdejneka on Sep 26, 2020

maybe optionally add entity_id back - if it’s specified use it (114 style), if not - than new 115 style

The template tracking is used in bayesian sensors, template entities, automation triggers, universal media players, and the websocket api (the case you are reporting). This would handle the template entities case but it doesn’t solve the issue you are reporting.

it will. my system will not hang on template testing. as of now - i need to restart container each time when i have an error. plus - to be honest - do we really need this “feature”? it was working just fine in the past. and not it’s enchanted meaning broken.

to4ko on Sep 26, 2020

revert the change that added listeners for all states but that isn’t going over very well as other users rely on this

I think that’s a good compromise. Out of curiosity, who are the users relying on states getting listeners? That capability never existed prior to 0.115 so there can only be very few users who took advantage of it in the past week (since 0.115 was released). In addition, those who are relying on it might also be experiencing decreased performance (re: Marius’s post above).

I think the old way of handling states (no automatically assigned listeners; use another entity, like sensor.time, to periodically update the template) was an effective (and efficient) technique. That was an unspoken advantage of entity_id, namely the ability to control the listeners assigned to a template.