Wait for trigger not working in scripts/automations

[naich11 (Tom)]

Hi guys!

I have a running and working setup of Zwave-JS-UI and HA. Everything is working fine and as expected so far.

The only thing i might be too stupid to get working is using wait_for_trigger in scripts. I have some Fibaro Roller Shutter 2 (FGR222) devices i want to work with in scripts.

So what i am trying to accomplish: Wait for a Cover to change to “closed” and then do some stuff in a script. But the wait_for_trigger always times out. But HA (in developer tools) reports ‘closed’ just as expected.

alias: testcover
sequence:
  - device_id: d75cba3cd07d400f5e12996a40a3e728
    domain: cover
    entity_id: 7eb67ca0717b09fedcbb8e378bbda07b
    type: close
  - wait_for_trigger:
      - platform: state
        entity_id:
          - cover.ez_raff01
        to: closed
        for:
          hours: 0
          minutes: 0
          seconds: 3
    timeout:
      hours: 0
      minutes: 0
      seconds: 20
      milliseconds: 0
    continue_on_timeout: false
  - service: notify.signal_tom
    metadata: {}
    data:
      message: action after trigger
mode: single

It does not matter which platform i use (state/device/template) for wait_for_trigger. In Step Details i always just see:

Executed: March 24, 2024 at 11:39:05
Result:

wait:
  remaining: 0
  trigger: null
timeout: true

Am i doing something wrong with the use of wait_for_trigger here or is there some sort of limitation i did not see in the docs?

I am thankful for any hint in a right direction as i am just all out of ideas.

Thx, Tom.

[PeteRage]

@naich11

  - device_id: d75cba3cd07d400f5e12996a40a3e728
    domain: cover
    entity_id: 7eb67ca0717b09fedcbb8e378bbda07b
    type: close

I’ve never seen this construct before. Most would use the cover.close_cover service call

Cover

I would try this. Also the for close may be unnecessary for the script. As it looks like you want it to close within 20 seconds. So having it be closed for 3 seconds, it the same as having a 17 second timeout.

@naich11

  - wait_for_trigger:
      - platform: state
        entity_id: cover.ez_raff01
        to: closed

[naich11 (Tom)]

hi pete!

thanks for your answer!

regarding the first thing…yeah this is just what HA does if you pick the device in the UI instead of a service call.

regarding for: …yes, i just want to make sure the state closed is set for 3 sec. the 20 sec timeout is just there because i was unsure what happens if i use no timeout at all…the closed state is reported withing 1-2 sec in my tests according to HA.

alias: testcover
sequence:
  - service: cover.close_cover
    metadata: {}
    data: {}
    target:
      entity_id: cover.ez_raff01
  - wait_for_trigger:
      - platform: state
        entity_id:
          - cover.ez_raff01
        to: closed
    timeout:
      hours: 0
      minutes: 0
      seconds: 20
      milliseconds: 0
    continue_on_timeout: false
  - service: notify.signal_tom
    metadata: {}
    data:
      message: action after trigger
mode: single

this version has exactly the same problem.

BR
Tom

[PeteRage]

The syntax on wait for trigger looks incorrect. Try removing the hyphen on the entitiy id and moving it back up to the prior line like in my example.

Closed could be the wrong state to test for. Take a look in developer tools / states to see what the value is. It may be on or off and the “closed” is the UI translating it based on the device class.

[naich11 (Tom)]

alias: testcover
sequence:
  - service: cover.close_cover
    metadata: {}
    data: {}
    target:
      entity_id: cover.ez_raff01
  - wait_for_trigger:
      - platform: state
        entity_id: cover.ez_raff01
        to: closed
    timeout:
      hours: 0
      minutes: 0
      seconds: 20
      milliseconds: 0
    continue_on_timeout: false
  - service: notify.signal_tom
    metadata: {}
    data:
      message: action after trigger
mode: single

Exactly the same problem. Not triggered.

closed is the string shown in developer tools.

BTW, i also tried triggers on attributes…they are not working either. Same with the template platform.

[PeteRage]

Quote the closed string. “closed”

[naich11 (Tom)]

If i do, HA changes is back to unquoted after save.

[PeteRage]

I looked in my code for an example. Here’s what I’ve used that does work.

          - wait_template: "{{ is_state(entity_id,'on') }}"
            timeout:
              seconds: "{{ timeout_seconds * repeat.index }}"
            continue_on_timeout: true

Test your cover state template in developer tools / templates.

[naich11 (Tom)]

@PeteRage

Test your cover state template in developer tools / templates.

i did! works just fine…returns True/False… all the time. only wait_for_trigger is not working. Maybe i should add that i use wait_for_trigger in a lot of automations with other integrations than zwave. they all work just as documented and expected.

but let me try your approach because i used platform template in wait_for_trigger

[naich11 (Tom)]

ok. this is strange.
wait_template is working:

alias: testcover
sequence:
  - service: cover.close_cover
    metadata: {}
    data: {}
    target:
      entity_id: cover.ez_raff01
  - wait_template: "{{ is_state('cover.ez_raff01','closed') }}"
    continue_on_timeout: false
    timeout: "20"
  - service: notify.signal_tom
    metadata: {}
    data:
      message: action after trigger
mode: single

So, this means wait_for_trigger is not working but wait_template is working.

The questions is why is wait_for_trigger not working?

[PeteRage]

Two possibilities.

First, wait for trigger requires that the trigger happens. So if it is already closed before that the script gets to the trigger it will not trigger. Because zwave service calls do seem to wait for the command to complete in on the zwave network. It would not be surprising for the state to already be updated in HA.

You could test this by adding a call to

                - service: system_log.write
                    data:
                      level: info
                      message: "turn_on {{states('cover.my_cover')}} {{now().strftime('%H:%M:%S.%f')[:-3]}}"
                      logger: service

And see what’s in the log. You may need to make it a warning to show up.

The template, on the other hand, evaluates when it executes, and then will wait if it’s not true for the timeout.

Second, a weird issue with “closed” not be quoted. Likely not the issue though.

[Stiltjack]

@naich11

this is just what HA does if you pick the device in the UI instead of a service call.

Nevertheless, it’s hard to think of a good reason for using device ids.

Why and how to avoid device_ids in automations and scripts

Don’t forget that the first post in a community guide is a wiki - feel free to add to it or correct it. This guide was written with reference to: Home Assistant 2023.8.3 Supervisor 2023.08.1 Operating System 10.5 Frontend 20230802.1 - latest Background When you start writing automations, a device trigger seems the obvious choice. Everybody knows what a device is and it comes at the top of the UI dropdown list. [image] It works… but it is certainly not a “great way to start” because it …

Rather than using wait for trigger, have you considered two or more separate automations? Easier to write and easier to maintain.

[Hellis81]

The issue is probably that it’s already closed.
I find it really strange but HA needs it to switch to closed while it’s waiting, it can already be closed.

The workaround is to use a if else.

If closed 
   Do something, preferably a script
else
  wait for trigger
    Do something, preferably a script
end if

[mcarty (Arturo)]

Then why are you using wait for trigger if is already closed?

@Hellis81

I find it really strange but HA needs it to switch to closed while it’s waiting, it can already be closed.

That is the purpose of wait for trigger, wait something to happen.

[armedad]

this is the correct solution. and it’s not strange. quite explainable.

as @PeteRage said, if the state of the cover is closed already by the time it enters this wait, then the trigger won’t happen in the non-template case because that other method is saying “wait for this change to happen”.

@Hellis81 i would recommend against the “if” check around the wait. this may be mostly hypothetical, but the if check closes the window of vulnerability, but theoretically if the cover achieves close between the if check and the else clause execution (remember there’s no promise that these are atomic) then it can still fail. odds of that happening are very small, but why chance it… negative code beauty points and the template method doesn’t have that vulnerability.

[Hellis81]

@mcarty

Then why are you using wait for trigger if is already closed?

@Hellis81

I find it really strange but HA needs it to switch to closed while it’s waiting, it can already be closed.

That is the purpose of wait for trigger, wait something to happen.

No shit! Aren’t you clever.
Well what if the entity is a device tracker that glitches every now and then and you want to wait for a phone to disconnect from the cars Bluetooth when they are in the home zone.
The device tracker says you are at work even though you are home, the Bluetooth disconnects then the device tracker updates.

Oh? That failed?? Gosh…

In Node red the wait for trigger looks at the current state also which is in my opinion the way it should work.
The wait for trigger in HA makes it complicated for no good reason.

[naich11 (Tom)]

Alright. Thank you so much for your help and the enlightening discussion guys.

It is exactly as @PeteRage pointed out. Right after the service call cover.close_cover the state of the cover changes to closed even though the cover is not really closed yet. If the cover is already very nearly closed before this goes mostly unnoticed. If the cover is mostly open though you can clearly see that right after the service call it changes to closed and just a few seconds later back to open until it is really closed.
I think this is called opportunistic in HA?!

This is the point the for: directive from wait_for_trigger comes in handy. Is there any way to make some sort of for in wait_template/jinja2?

BR
Tom

[ShadowFist]

@naich11

I think this is called opportunistic in HA?!

I think the word you’re looking for is optimistic

[naich11 (Tom)]

Right! Not editing, to expose my stupidity.

[ShadowFist]

Just blame it on autocorrect