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.
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. 
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.
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?
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?
Here is a thread that discusses this in more detail and gives examples of ways to mitigate it.
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.
Negative, not on a restart. But I can work inside HS all day long without resetting the automation system.
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:
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.
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.
Guys, I’m not talking about reboots, or restarts of the program itself (I don’t believe that was ever a question of mine).
It was indicated to me, in this thread that whenever certain work is done inside HA, the system performs a “global reset”. HomeSeer simply does not do this.
Not technically “global”.
it only resets the parts you are working on.
if you save an automation in UI it reloads all automations and all running automations are reset/cancelled.
but running scripts and timers are unaffected.
if you save a script then scripts are cancelled but automations aren’t affected.
if you reload timers it resets timers but not scripts or automations…etc.
That is not what is happening in my case. I can see when the speaker wakes up via an indicator led (When it is sent audio or tts) . It follows that delay.
If I set the delay for 05 seconds, the audio file is not send for at least 5 seconds.
If I set the delay for 30 seconds, the audio file is not send for at least 30 seconds.
The first action is the sending of the audio file.
that’s definitely not the way it’s supposed to work so there has to be something else going on in your specific system.
try to remove the last action after the delay and see what happens.
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
the initial tone should start right away and then then the automation should continue to indicate it’s still running for the additional 5 seconds of the delay.
I’ll report back tonight.
Thank You for your help.
1 Like
Just to confirm, you’re saying the 20Hz tone only plays after the delay has expired (followed immediately by the TTS message)? Or does the tone never play, just the TTS message?
If it’s the former then that’s odd behavior because actions are normally executed in their defined order so the tone ought to come before the delay. 
That is how it works in every case.
This is not true. The speaker doesn’t wake up for five seconds, sure, but the service call to send the audio file was made before the delay. This is an indication that there is something wrong with your attempt to wake the speaker with the audio file, not that the service call isn’t being made. The speaker is not waking until the TTS command makes it through.
Have you checked for any errors with the service call? Have you ensured that the file is accessible and being played successfully?
1 Like
That’s why I suggested removing the tts and just use the audio file to see if it still “wakes up” after the delay or never.
1 Like
You guys nailed it. and @r-j-taylor you nailed every part of the problem.
I removed everything after the audio file and as you guys suspected, nothing played. no errors in logs that I can determine.
So I tried “http://192.168.1.132:8123/media/music/20Hz1Sec.mp3” in a browser and I get
401: Unauthorized.
I can play files from inside HA via left menu item Media Browser media > music > click on the file and it plays.
If I dump the file inside the root ‘media’ folder I get: (http://192.168.1.132:8123/media/20Hz4Sec.mp3)
Error 404 Not Found
Man, should it be this hard?