Core: Script with condition and delay/wait_template never resets to 'off'

[jbcodemonkey]

Make sure you are running the latest version of Home Assistant before reporting an issue.

You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:

Home Assistant release (hass --version):
0.40.0.dev0

Python release (python3 --version):
3.5.2+

Component/platform:
Script with 'delay' or 'wait_template' and 'condition'.

Description of problem:
When using 'delay' or 'wait_template', the tile launch option is a toggle.
When using a condition that evaluates to false, the toggle remains 'on'.

Expected:
When the condition evaluates to 'false' and halts the script, the toggle should reset to 'off'.

Problem-relevant configuration.yaml entries and steps to reproduce:
script: tv_plex: sequence: - condition: template value_template: > {% if is_state('media_player.tvliving', 'playing') %} false {% elif is_state('media_player.tvliving_2', 'playing') %} false {% else %} true {% endif %} - service: broadlink.send_packet_192_168_3_80 data: packet: - "JgBQAAABK5MSExI4EjgSExITEhQRFBE5ETkRFBE5ERQRFBEUERQRFBE5ETkRORE5ERQRFBEUERQSExITEhMSExI4EjgSOBI4EgAFngABKUoSAA0FAAAAAAAAAAA=" - wait_template: "{{ states.device_tracker.hostone.state == 'home' }}" timeout: 00:00:30 - delay: 00:00:04 - service: broadlink.send_packet_192_168_3_80 data: packet: - "JgBQAAABKZUSExI4EjgSExITEhMSExQ2EjgSExQ2EhMSFBEUERQRFBEUERQTNxEUETkRFBEUERQRORE5ExIROREUETkSOBI4EgAFnQABKUsTAA0FAAAAAAAAAAA=" - "JgBQAAABKZUSExI4EjgSExITEhMSExQ2EjgSExQ2EhMSFBEUERQRFBEUERQTNxEUETkRFBEUERQRORE5ExIROREUETkSOBI4EgAFnQABKUsTAA0FAAAAAAAAAAA=" - "JgBQAAABKZUTEhI4EjgSExITExISFBE5ETkRFBE5ERQRFBEUERQSExA6ERQROREUETkRFBEUERQRFBE5ERQRORMSEjgTNxM3EgAFngABKEsTAA0FAAAAAAAAAAA=" - "JgBQAAABKZUSExE5ETkSExEUERQRFBE5ETkSExE5EhMSExITEhMSExITEhMTEhI4EzcTEhIUERQRORI4EDoRFBEUETkSOBE5EQAFngABKEwSAA0FAAAAAAAAAAA="

[oakbrad]

I am having this issue as well. I have not seen any examples of working configs anywhere either. I know my template is correct and returning true/false as expected, I can see it in the console.

I'm on 0.47.1

    - service: switch.turn_off
      entity_id: switch.radio_npr
    - delay: 00:00:02
    - service: script.tts_morning_info
    - wait_template: "{{ states.media_player.vlc_tts.state == 'idle' }}"
    - service: switch.turn_on
      entity_id: switch.radio_npr

[rbflurry]

Wanted to bump this and see if it is still not working for all?

I also found conflicting information as to what the timeout feature does.

does timeout continue the rest of the automation/script or cancel/terminate the script?

Can I kindly tag @pvizeli for his assistance?

[rbflurry]

I just did some testing and found this to work.

- wait_template: "{{is_state('input_boolean.test', 'on')}}"

and after the timeout period the script does not continue but quits instead.

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[OmenWild]

I can verify that this sequence works. Also, when the timeout is hit the actions ABORT. It would be nice to have both options, maybe timeout_abort: and timeout_continue:. My goal of this testing was to figure out how to turn the motion triggered lights off after motion stops, but I would also like to have a fallback timeout and have the lights turn off, just in case.

Either way, the docs should be clear exactly what timeout: does.

- alias: "Backyard LEDs Motion TEST" trigger: - platform: state entity_id: input_boolean.backyard_leds_motion_triggered to: 'on' action: - service: notify.syslog data_template: message: "ON: {{ trigger.entity_id }}" - wait_template: "{{ is_state(trigger.entity_id, 'off') }}" timeout: 00:01:00 - service: notify.syslog data_template: message: "OFF: {{ trigger.entity_id }}"

[kloggy]

I can not get
wait_template
to work at all in a script but it seems to work fine in an automation in the format
- wait_template: "{{ is_state(trigger.entity_id, 'off') }}"

It would be nice to see this fixed.

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[kloggy]

I'm happy for this to be closed.

[OleksandrBerchenko]

It would be great to have that fixed.

Today I have spent X hours trying to understand why my wait_template doesn't work. Proposed workaround might work, but 1. it's still a workaround, 2. it's not clear for new users, 3. it doesn't allow writing something more complicated than just checking some state.

Thanks!

[OleksandrBerchenko]

Oops... is_state workaround doesn't work for me inside scripts.

[OleksandrBerchenko]

Well... I have debugged HA code and found what actually happens:

1. I'm not sure about the original case - possibly, it's already fixed. At least, the following code works fine inside scripts:

- wait_template: "{{ states.script.test1.state == 'off' }}"

1. At the same time, the following code doesn't work:

- wait_template: "{{ states.script['test' + states.input_text.test.state].state == 'off' }}"

Yeah, the name of the script to watch is dynamic.

1. helpers.event.async_track_template function has the following code:

    return async_track_state_change(
        hass, template.extract_entities(variables),
        template_condition_listener)

It takes the template and extracts entities to watch for. In the first case it extracts script.test1 (that's correct), but in the second case it (unsurprisingly) extracts input_text.test that won't change and completely ignores script.test1.

Inside extract_entities method there is the following code:

_RE_GET_ENTITIES = re.compile(
    r"(?:(?:states\.|(?:is_state|is_state_attr|state_attr|states)"
    r"\((?:[\ \'\"]?))([\w]+\.[\w]+)|([\w]+))", re.I | re.M
)

...

extraction = _RE_GET_ENTITIES.findall(template)

When I changed my code to:

- wait_template: "{{ states.script['test' + states['input_text']['test'].state].state == 'off' }}"

HA extracted * (nothing found, watch for everything) and behaved correctly.

1. Possible solutions:

• Improve extract_entities method to detect entities obtained after "eval". I realize that may be very complicated.
• Always assume * for wait_template.
• Leave it for now and just add a GOOD explanation to documentation.

Thanks!

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[alexmannuk]

Is this still an issue you are experiencing? Can you please try upgrading to the latest version of Home Assistant (0.90) and report back if this is still a problem? Thanks!

[OleksandrBerchenko]

Yes, it's still actual.

I believe the right fix (it's not mentioned above) is to add an optional entity_id configuration variable to wait_template (like for https://www.home-assistant.io/components/sensor.template/).

Thanks.

[Swamp-Ig]

I'll have a go at fixing it :grin:

[Swamp-Ig]

Working on this, it shouldn't be too hard to implement a fix using the optional entity_id parameter. I'll fix some other similar issues at the same time.

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[OleksandrBerchenko]

Yes, it's still actual.

Like I said, I believe the right fix is to add an optional entity_id configuration variable to wait_template (like for https://www.home-assistant.io/components/sensor.template/).

Thanks.

[Swamp-Ig]

I was working on this, but it's kinda stalled for the moment due to other things being a priority. Will get back to it eventually. Issue #22587

[OleksandrBerchenko]

@Swamp-Ig Thanks!

[kloggy]

I think @OleksandrBerchenko is right about an entity_id.
See this forum discussion for more info.
https://community.home-assistant.io/t/repeatable-bug-in-wait-template/122802

[Swamp-Ig]

Kinda, there's a better algorithm that I've come up with which means you don't need to list any entity IDs, I was getting on with implementing it when it stalled because other priorities came up. If there's anyone interested, if you read through the stuff in #22587 for more details.

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[OleksandrBerchenko]

Yes, it's still actual.

Thanks!

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[OleksandrBerchenko]

Yes, it's still actual.

Thanks!

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[OleksandrBerchenko]

Yes, it's still actual.

Thanks!

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[OleksandrBerchenko]

Yes, it's still actual.

Thanks!

[bdraco]

Fixed via #38802 and bugs in that fixed in https://github.com/home-assistant/core/pull/38940