If I’m calling multiple actions in an automation, are they run sequentially or in parallel? For example, I’ve written an automation that calls both image.processing and camera.record; will camera.record not start until image.processing is completed?
1 Like
They run in parallel unless you specify a wait_template or delay.
They run sequentially, but you might need a wait_template or delay to ensure that the next action doesn’t interrupt the previous one before it completes. There are a few examples with reasons why below.
Inside a single automation it is sequential, with the exception that if you call a script it will run in another thread and therefore in parallel. You can test this by calling the same script back to back in an automation and you will get errors over “Script already running”
Multiple automations can run in parallel. I vaguely recall a discussion that it’s setup to have 10 threads to do this so not sure what happens if more than 10 automations to run at once, perhaps they block or new threads get spawned. I tried to find this discussion just now but could not.
Maybe I misunderstood what OP asked, but I’m under the impression that the actions are carried out effectively at the same time. For example, if I were to call a tts service to a speaker and have media_player.media_stop immediately after it in the automation, it will not wait for the tts to complete before stopping the media.
I don’t think we’re disagreeing here, I just wanted to clarify what I meant.
I think you are both right.
If there are sequential actions they are started in sequence but so fast and in parallel that they appear to have been started simultaneously.
The fact that most hardware / communications takes some milliseconds to complete, demonstrate this apparent simultaneity.
IMHO anyways (not that I’m ever humble 
)
1 Like
That makes sense with TTS as it simply sends the text to a cloud service to convert to a mp3 that it then plays by sending to the playback device you specify (Alexa, Sonos, etc). Once HA tells the device to play it assumes it’s done and moves on to the next action in the automation. The stop command does what you expect, it stops the playing. That whole chain is asynchronous in that many parts going on outside of HA. In this regard media playback is like a script as it gets started but then executes in parallel.
A good test is a simple automation that turns light A on, then turns light B on, then light B off, then light A off. The lights will respond in sequence as expected.
1 Like
True, but those would happen very quickly. So it is indeed sequential but could appear to be in parallel. So if I were to call light.turn_on with a transition of 5 seconds and have a light.turn_off command right after it, it will interrupt the transition and turn the light off instead of waiting for the transition to complete. Just tested this to make sure I’m not going crazy 
Probably, depending on type of light. Since the transition is handled by the light hardware (likely hub) it is up to that firmware developer if an off command will wait for a transition to complete before executing or will pre-empt the transition and turn it off. So not a 100% test as we’ve got “other” firmware in the mix.
Also as Zwave/Zigbee itself is serialized as it’s a radio link that sort of guarantees things happen in order unless a message gets dropped and resent, etc.
Ah fair point. I’ll update my original reply.
The answer probably should be “It depends…” as it certainly can feel/behave like it’s all happening in parallel.
It gets even more interesting when you have scripts calling scripts that are calling off-HA services… All bets are off as to what happens first
1 Like
1 Like
So, if I call camera.record to record a 30s video, HA will not wait until the video is finished recording before launching the next action?
It depends on the action. But if you find that it doesn’t wait, and you know how long the action is, you can add a delay for that time.
they are run sequentially, non-blocking. You can make them ‘blocking’ with a wait template.
1 Like
^ this…
I could have sworn I said that 
While this is true several things inside HA are serial such as the zwave and zigbee modules so you do have things queue and the automation/script will complete before the actual commands get sent and executed.
Even putting a wait_template after such service calls will lie, and indicate it’s completed even if it’s still sitting in a queue to be sent.
These things start to become annoying on larger systems where more load on slow radio networks makes the latency even higher.
The question was about scripts though. Scripts themselves in home assistant (ignoring hardware) are sequential and non-blocking. Other devices that have their own network will behave differently but it’s not the scripts fault, it’s the hardwares’ protocol. I.E. The script will be finished but the hardwares protocol could still have all the calls in it’s queue (which is what happens with zigbee and zwave). I’m giving a succinct answer in regards to what OP asked, using the lingo he used.
that was the difference…
The OP did not mention scripts at all so it certainly was not a succinct answer.
The challenge is with so many integrations of different hardware and platforms consistency of behavior is a problem. It would be nice to have service calls have some option to indicate you want them to block until completely executed, or allow the fire-and-forget that we have now. This would make a lot of automation logic easier to implement.