Template loop detection broke my cover template

Configuration
1

Hi all!

I have a really basic icon_template on all my covers to correctly display the shutter icon as open/close.
This was all working well until 0.115, when template loop detection was introduced.

Template loop detected while processing event: <Event state_changed[L]: entity_id=cover.office, old_state=<state cover.office=open; friendly_name=Persiana, icon=mdi:window-shutter-open, supported_features=11, assumed_state=True @ 2020-09-30T21:28:36.338367+01:00>, new_state=<state cover.office=closed; friendly_name=Persiana, icon=mdi:window-shutter-open, supported_features=11, assumed_state=True @ 2020-09-30T21:30:30.871884+01:00>>, skipping template render for Template[{% if is_state('cover.office', 'open') %} mdi:window-shutter-open {% else %} mdi:window-shutter {% endif %}]

So, my code:

cover:
  - platform: template
    covers:
      office:
        friendly_name: "Persiana"
        open_cover:
          service: switch.turn_on
          data:
            entity_id: switch.office_blinds_up
        close_cover:
          service: switch.turn_on
          data:
            entity_id: switch.office_blinds_down
        stop_cover:
          service: switch.turn_off
          data:
            entity_id: switch.office_blinds_up
        icon_template: >-
          {% if is_state('cover.office', 'open') %}
            mdi:window-shutter-open
          {% else %}
            mdi:window-shutter
          {% endif %}

I do understand the issue, I’m self-referencing cover.office and unfortunately even after the change in template loop detection (this and also this) I’m still affected - all my templates are self-referencing.

I have 5 covers like these and was trying to use some sort of binary_sensor and use it in the icon_template to avoid self-referencing, but it was getting too messy so I stopped and came here asking for help/suggestion on an easier (cleaner) way.

Help? :grinning:

Thanks!!

felgy

2

Instead of self-referencing, why not refer to the state of the switches?

3

The covers are controlled via 433 MHz Livolo switches, so one-way only.

4

Then use another entity, like an input_boolean, to serve as a proxy. For example, open_cover turns on the switch and an input_boolean. close_cover turns off the switch and the input_boolean. Use the input_boolean’s state to determine which icon to display.

5

Thanks! That is more a less what I was trying o achieve with a binary_sensor.

I understand the importance of loop prevention, but for simple templates (like mine), it adds complexity,

6

My suggestion is hardly complex and has an additional benefit: it can be used to provide a value_template for your cover.

7

I understand @felgy 's frustration. I have dozens of sensors like this one.

    nest_connected:
      friendly_name: Nest Connected
      icon_template: "{{ 'mdi:smoke-detector' if is_state('binary_sensor.nest_connected','on') else 'mdi:alert-circle' }}"
      device_class: connectivity
      value_template: >
        {{ is_state('binary_sensor.upstairs_thermostat_online','on')
            or is_state('binary_sensor.upstairs_nest_protect_online','on')
            or is_state('binary_sensor.upstairs_nest_protect_online','on') }}

So really my only option here is to more or less repeat the value template in the icon template. At the end of the day it’s not the end of the world but the code certainly isn’t as pretty.

This caught me by surprise. If there was any mention of this change I can’t find it anywhere in the release notes. Literally the only search results are the two git issues posted and this thread. I’m kinda surprised more people haven’t had a problem or mentioned it.

Anyway, as far as I can tell, this only throws a warning in the log, the templates still actually work. But the warnings bug me so now it looks like I’ve got a bunch of templates to fix. :roll_eyes:

8

Don’t get me wrong, it was my laziness speaking :sweat_smile:
I’ll implement your suggestion, thank you!

9

In your case it still works because you have more than 1 template and only 1 is self-referencing. But I feel your pain with the warnings… even if it still works!

10

OK, I’m trying the input_boolean approach, but I can’t find a way to perform two action at once. This is, when I open the cover, I activate the switch AND update input_boolean status.

I do see a way via automation, but I’ll need 10 of them to cover all 5 blinds (open/close).

What I would like is something like this:

open_cover:
          service: switch.turn_on
          data:
            entity_id: switch.office_blinds_up
          service: input_boolean.turn_on
          data:
            entity_id: input_boolean.office_cover_status

But this doesn’t work :slightly_smiling_face:

Can you help?

11 
        open_cover:
          - service: switch.turn_on
            data:
              entity_id: switch.office_blinds_up
          - service: input_boolean.turn_on
            data:
              entity_id: input_boolean.office_cover_status
12

Sorry, I pasted wrong here, open_cover is spaced correctly.

I don’t believe we can issue more than one service in this template. I don’t get any error, but it just ignores the 1st one (switch.turn_on) and just changes the input_boolean.

13

Oh… The dashes!! :sweat_smile: :sweat_smile:

Thanks a lot, @123!!

1 Like
14

You’re welcome!

Please consider marking my post (above) with the Solution tag. It will automatically place a check-mark next to the topic’s title which signals to other users that this topic has an accepted solution. It helps others users find answers to similar questions.

1 Like
15

Should be fixed here https://github.com/home-assistant/core/pull/41013

3 Likes
16

Don’t forget that by using the input_boolean to track the cover’s states, you can use it to provide your cover with a value_template.

      value_template: "{{ 'open' if is_state('input_boolean.office_cover_status', 'on') else 'closed' }}"
1 Like
17

Thanks @bdraco!

All in all, the changes @123 suggested allowed me to overcome the issue with loop detection and also keep the cover state even after HA reboot (something that I was struggling with). So… Not so bad then! :grinning:

1 Like