Template loop detected. Is it a real problem?

Configuration Frontend
1

Hi,

I have this binary sensor:

      - name: "Hive heating doors/windows open"
        state: >
          {{
            states.binary_sensor
            | selectattr('entity_id', 'search', '(doors?|window)_contact')
            | rejectattr('entity_id', 'search', 'bedroom_[a-z,1]|ensuite|front')
            | selectattr('state', 'match', 'on')
            | list  
            | count 
          }}
        attributes:
          influence: >
            {{
              states.binary_sensor
              | selectattr('entity_id', 'search', '(doors?|window)_contact')
              | rejectattr('entity_id', 'search', 'bedroom_[a-z,1]|ensuite|front')
              | selectattr('state', 'match', 'on')
              | sort(attribute='name')
              | map(attribute='name')
              | list
              | join(',\n')
              | replace(' contact', '')
            }}

The sensor always works but every so often I get a warning like:

2023-09-10 19:53:52.927 WARNING (MainThread) [homeassistant.components.template.template_entity] Template loop detected while processing event: <Event state_changed[L]: entity_id=binary_sensor.hive_heating_doors_windows_open, old_state=<state binary_sensor.hive_heating_doors_windows_open=on; influence=Kitchen doors,

In the above case, the number of doors/windows opened goes from 2 to 3.

Is this self-referencing because it is both a binary_sensor and it begins with states.binary_sensor?

Is there anything I could/should do about it?

2

Yes it is.

Have you tried rejecting the template binary sensor from your template?

EDIT: actually, are you sure that is/should be a template binary sensor and not a template sensor?

It appears to be returning a count, which is not a binary state.

3

Thanks for replying!

No, I haven’t as I assumed it was effectively being rejected via the use of:
| selectattr('entity_id', 'search', '(doors?|window)_contact')
…do I need to explicitly reject it? …I’ll give that a go, thanks.

Yes, I was trying to get a binary_sensor with the principle that a count of 0 is off and any positive integer is on. Is that bad coding?

4

Nope. As long as that’s what you were after it is fine.

1 Like
5

Hmmm. Yeah that should have rejected it.

1 Like
6

Thanks again.

Should I just ignore the warning when it crops up?

7

The warning will appear regardless because you’re using the states function, which will access the state object and trigger the warning.

Personally, I make an automated group that does this periodically and use the group in my template sensors.

- alias: Make Group
  trigger:
  .... add whatever trigger you want
  action:
  - service: group.set
    data:
      object_id: doors_and_windows
      entity_id: >
        {{ states.binary_sensor | map(attribute='entity_id') 
            | select('search', '(doors?|window)_contact')
            | reject('search', 'bedroom_[a-z,1]|ensuite|front')
            | list }}

then just use that group in your template sensors

      - name: "Hive heating doors/windows open"
        state: >
          {{ state_attr('group.doors_and_windows','entity_id') | select('is_state', 'on') | list | count }}
        attributes:
          influence: >
            {{
              expand('group.doors_and_windows')
              | selectattr('state', 'match', 'on')
              | sort(attribute='name')
              | map(attribute='name')
              | list
              | join(',\n')
              | replace(' contact', '')
            }}
2 Likes
8

Thanks!

Other than avoiding the template loop is there an additional advantage that the group is only updated periodically whereas my sensor was being updated all the time (I’m thinking CPU load etc)?

9

Yes, if you go states.<domain> routine in a template entity, it will only update at most once per second. If you go the group route, it will update whenever there is an update. Minor difference in this regard. If you just use states in your template, the template is throttled to at most 1 update per minute.

1 Like
10

Doesn’t it update according to the trigger?

11

the group updates according to the trigger in the automation. But we aren’t talking about that, we are talking about the template sensor that uses the group.

1 Like
12

ugh, sorry. I was being dumb thinking the automation was a template sensor with a trigger.

1 Like
13

folks, sorry to resurrect this.

I do have the same log error, although I’m excluding it, will it still log if I’m initally fetching it? I’m certain that I’m not using it, otherwise the value would keep increasing exponentially, which isn’t the case.

{

% set power_sensors = 
              states.sensor 
              | rejectattr('entity_id', 'equalto', 'sensor.total_w_consumption')  
              | selectattr('attributes.unit_of_measurement', '==', 'W')
              | selectattr('attributes.device_class', '==', 'power')  
              | map(attribute='state') 
              | select('is_number') 
              | map('int') 
              | sum 
%}
{{ power_sensors }}
14
1 Like
15

Got it! I though it was due to it being referred.
Are you aware of any good solution for that?

16

Yes, the post marked as a solution gets rid of the warning

1 Like
17

The expand did the trick! Thanks for your help!