Are automations with the same trigger started in parallel?

Disclamer: while premature optimization is the root of all evil, I would like to get a better understanding of how automations are triggered before jumping into a large refactoring and realize at the end that I can brew a coffee waiting for a light to switch on. I am already treading on thin ice when lights in my house are available 70% of the time only, and a wife highly skeptical about home automation.

I have automations for ~10 lights which rely on the state of a sensor set though MQTT. Each automation has a condition “is the state equal to XXX”, where XXX is an indication of the source of the signal, and if that particular light automation matches, the light is toggled.

This means that there are 10 automations which need to be ran, out of these one (to simplify things) will eventually run until the actions stage.

How are such automations which depend on the same trigger started? Specifically: are they threaded or do they run sequentially?

From experience: should I care?

If I understand the question properly then in my experience, no.

I think they get scheduled in an event loop:

However this is for things that are not “thread safe”. I guess it depends what functions the automation calls as to whether that is true or not.

Disclaimer: so far out of my depth here I cant see the bottom.

There’s a queue that everything gets dropped into. If you want it to have everything run in unison, try using a scene to control your lights with a single automation. Otherwise it will fire in an order that may or may not be visible depending on your hardware.

so this would be alright? I’ve asked in the other thread but maybe it got snowed under. twice the same script, that both could take some time to complete. Probably the first call hasn’t finished before the second starts?

  - delay: 00:{{ range(5,11) | random | int }}:00
  - service: script.home_mode_locked_lights
      random_group: group.home_mode_locked_lights_1
      random_entity_id: >
        {{ state_attr('group.home_mode_locked_lights_1','entity_id') | random }}
      light_count_limit: 4
  - service: script.home_mode_locked_lights
      random_group: group.home_mode_locked_lights_2
      random_entity_id: >
        {{ state_attr('group.home_mode_locked_lights_2','entity_id') | random }}
      light_count_limit: 3

It is less a worry on the orchestration (so that things stard/end on the right time/sequence) and more the fact that if I have 10 automations which are triggered by one element (a sensor state), they would take a lot of time to run all together.

Actually they may run fasted in threads than sequentially (or not, it really depends on how this is coded) so I wanted to anticipate the delays / latency.

And since I do not have experience with automations in HA I do not know whether this is something I should worry about for 10 or 20 lights, with HA running on a real server (not extraordinary but much faster than a RPi).

I wouldn’t worry. Worse case is that you’ll see a delay on a slow system like a raspi. If you move to something with power, you won’t notice it at all.


Also, they don’t run sequentially in that sense. Each automation isn’t waiting for the other automation to finish. It’s like this:



1 Like

They should be fired without care if they are different scripts. If they are the same script, and you try to fire it while it’s running, nothing will happen. Your case has the same script twice in a row. You’ll run into issues like this.

thanks, I will rename them then, using the group names as identifier for the internal logic of it all.