Wait between action steps

Configuration
#1

I need to wait while my CCA speaker wakes up between tts steps. I do this by playing a 20hz .mp3 before making any tts attempts.

It appears the “delay” action delay’s the entire automation. What are my options? (Home Seer Refugee)

alias: A-Announce_Time
description: ''
trigger:
  - platform: time_pattern
    hours: '1'
    minutes: '0'
    seconds: '0'
condition:
  - condition: time
    after: '09:59:00'
    before: '08:01:00'
action:
  - service: media_player.play_media
    data:
      media_content_id: http://192.168.1.132/media/music/20Hz1Sec.mp3
      media_content_type: music
    target:
      entity_id: media_player.house_audio_group
  - delay:
      hours: 0
      minutes: 0
      seconds: 5
      milliseconds: 0
  - service: tts.cloud_say
    data:
      entity_id: media_player.house_audio_group
      message: ' message:   The time is now {{now().strftime("%-I %p")}}'
mode: single
#2

Use a wait template.

action:
  - service: media_player.play_media
    data:
      media_content_id: http://192.168.1.132/media/music/20Hz1Sec.mp3
      media_content_type: music
    target:
      entity_id: media_player.house_audio_group
  - wait_template: "{{ is_state('media_player.house_audio_group, 'idle) }}"
    timeout: '00:00:30' # 30 sec, adjust as necessary
    data:
      entity_id: media_player.house_audio_group
      message: ' message:   The time is now {{now().strftime("%-I %p")}}'
  - service: tts.cloud_say
mode: single
#3

Thank you, I haven’t gotten to templates yet. :upside_down_face:

That said, this still does not wait for the speaker to wake. The CCA group will respond faster then the time it takes the speaker to wake.

I need to wait out a specific time, regardless of CCA status, and not block the upper actions in the automation.

#4

Then use a different wait template. Instead of waiting for idle, wait for whatever state the speaker takes when it is on.

In answer to your original question:

You can put the delay and TTS in a script and call the script via the script.turn_on service.

https://www.home-assistant.io/integrations/script/#waiting-for-script-to-complete

#5

That is the problem, there is no feedback (connection) to the state of the speaker, only the CCA device attached to it.

#6

I have no idea what a CCA is but just use your delay in a script as I said.

#7

I personally not in favor of long running automations as in any failures/restarts, they will not continue. I would stick with shorter/atomic automations as much as possible.

#8

Agreed. Which is why I went for state based wait. Unfortunately that is not possible and it is only 5 seconds.

1 Like
#9

CCA = Chromecast Audio.

Thank you for all your help, it really is MUCH appreciated. Unfortunately, I’m not a programmer so that’s probably going to take quite some time to learn. It literarily took me 2.5 hours to figure out how to format the time to 12hr for my time zone.

I’m quickly learning what people meant when they talk about the learning curve required and functional resistance in setting up automation in HA. At the rate I’m going It’ll be 2037 before I’m done moving my home from HomeSeer to HA… :crazy_face:

Wait, a simple 10 second delay in an automation is a point of possible failure in HA?

#10

Delays in the order of tens of minutes and more can cause issues. Restarting may catch these automations in the delay and your devices may end up in an unwanted state.

A delay of 10 seconds or so is less likely to fall afoul of this.

#11

Just to clarify…

The only issue is when you restart HA or reload automations (and if you save an automation in the UI editor since that automatically does an automation reload) while an automation is actually running.

So yes, it is technically possible to have issues with the automation that contains a 10 second (or even a 1 second) delay if you happen to do the above two things while the automation is actually running (waiting for the 10 second delay). And this doesn’t just work like that for delays either - wait_for_trigger, wait_template and even timers suffer from the same limitations (except timers aren’t affected by automation reloads but the automation that uses them are cancelled so it’s effectively the same result).

But it will only be an issue for that one automation and only for that specific run. Other non-running automations won’t have any problems.

But the point Tom was making is that the odds of you restarting/reloading during a short duration delay and screwing up the automation is less as the delay in the automation is shorter.

My comfort zone for a delay in any automation that I really want to run accurately is 5 minutes. Or even less if it’s absolutely critical. Anything longer than that I shy away from delays directly coded into the automation unless I really don’t care that much if the automation doesn’t complete on time. Then again I do a lot of tweaking so I am more likely to restart/reload way more often than someone who just “sets it and forgets it”. For those people long delays are perfectly acceptable and won’t cause any issues at all.

State triggers are the best way to mitigate those limitations of timers/delays but if it isn’t possible then the only way to get truly reliable delays is to use an input_datetime to set the actual time that you want the action to run.

So in summary, a 5 sec delay should be just fine the vast majority of time. :laughing:

#12

What is the functionality that you are expecting from a delay and why isn’t the current functionality wanted? Based on all the information you’ve provided, it seems that this would do what you want. I’m just trying to determine what the core problem that you are trying to solve is.

#13

Thanks for that explanation, it’s an eye opener for sure…

It raises a question. I use time based automation a fair amount. IE: If Motion = True, Then turn fan on. If no motion for x time; turn fan off is just one of many time based automation that would be effected by “resetting everything” when work is being done to HA.

Since this is core architectural effect, what are people doing to deal with this? I have to believe there are some clever (most likely extremely complicated) solution to this?

#14

What did you do in Homeseer? Or are you saying that after a restart, Homeseer would resume exactly where it left off within every running script that had been interrupted by the restart?

#15

Here is a thread that discusses this in more detail and gives examples of ways to mitigate it.

#16

Expected.
Trigger fires automation path
Conditions processed
Actions - followed in a liner path (Hence the up and down arrow for placing actions)

Action List
Action Performed 1
< Send an audio file to the CCA device. >
Action Performed 2
< Wait > 5 sec. before continuing to next action
Action Performed 3
< Send tts to the CCA device. >

This is what I expected, but that is not how Wait (as defined in my OP) functions. Wait appears to fire the entire action list when resolved True (wait timer has completed) so Action Performed 1 doesn’t fire.

#17

Negative, not on a restart. But I can work inside HS all day long without resetting the automation system.

#18

What you described as expected is the way the actions are triggered. Actions are performed in order and actions before the delay will not be delayed.

Here is a test automation that has multiple five second delays between turning a toggle on and off:

alias: Test Automation
description: ''
trigger:
  - platform: state
    entity_id: input_boolean.dummy
    to: 'on'
condition: []
action:
  - &ref_0
    delay:
      hours: 0
      minutes: 0
      seconds: 5
      milliseconds: 0
  - &ref_1
    service: input_boolean.turn_off
    target:
      entity_id: input_boolean.dummy
  - *ref_0
  - service: input_boolean.turn_on
    target:
      entity_id: input_boolean.dummy
  - *ref_0
  - *ref_1
mode: single

Here it is functioning:
delay-test

#19

It doesn’t matter if you rarely ever had to restart Homeseer. The point is that if you ever did restart it, any scripts that were in-progress would be cancelled, just like in Home Assistant. Mitigating this is a consideration for both products, arguably more for Home Assistant because of the higher likelihood of a restart/reload.

The mitigation techniques aren’t onerous and often not required if the action’s waiting time is brief.

#20

Delays were points of failure in HomeSeer (HS) as well. HS did not pick up the state where it left off. I use delays in irrigation automation in HA and HS before I made the switch. The delays are up to 10 minutes per zone. I know if my system reboots during the watering cycle that it is not going to complete the automation.

IMO no sprinkler controller can do what home automation can do to save water. I live in the western US so water is precious. The minor downside does not outweigh the benefit. Also why I use ups on rack servers and critical equipment.