Is it intended that action targeting multiple entities breaks sequence?

Configuration
1

I have noticed that in my automation that has an action targeting 2 light entities, that action seems to be done in parallel with the next step of the automation and not finished before the next step. Or at least it seems so to me. Let me explain.

I have this:

  1. Turn lights A and B on with minimum brightness.
  2. Turn lights A and B on with maximum brightness and transition set to 600 seconds.
  3. Delay 10 minutes
  4. Check if the light B was on for the last 10 minutes.

Check fails every time, because light B was turned on one second (or probably a fraction of a second) later than the delay started, according to the automation trace.

Hereā€™s the actual yaml:

actions:
  - metadata: {}
    data:
      color_temp_kelvin: 2000
      brightness_pct: 1
    target:
      entity_id:
        - light.lampa_w_sypialni
        - light.kula_w_sypialni
    action: light.turn_on
  - metadata: {}
    data:
      color_temp_kelvin: 2000
      brightness_pct: 100
      transition: 600
    target:
      entity_id:
        - light.lampa_w_sypialni
        - light.kula_w_sypialni
    action: light.turn_on
  - delay:
      hours: 0
      minutes: 10
      seconds: 0
      milliseconds: 0
  - condition: state
    entity_id: light.lampa_w_sypialni
    state: 'on'
    for:
      hours: 0
      minutes: 10
      seconds: 0

I have already changed this to use light group instead of entities, so I expect it to be fixed (will know for sure tomorrow), but I was wondering if this is a bug or intended behaviour.

I was expecting the third step (delay) to start only after the second step is finished, even if internally within the first step the 2 actions were done in parallel.

2

Pretty positive it doesnā€™t wait for the transition to complete. It ā€˜sends the commandā€™ and then moves on.

1 Like
3

Of course, I wouldnā€™t expect it to wait. But the light is turned on at the start of the transition, not at the end. The issue here is that it doesnā€™t wait for the command to be sent/received by the device. My suspicion is that the action targeting 2 entities is simply 2 actions processed in parallel and the next sequential step in the automation is done after the first of those active are done, not when all of them are done. I donā€™t know if this is just to be expected or is a big to report.

But maybe Iā€™m wrong and itā€™s something else, like a delay due to how they integration handles multiple requests (itā€™s Hue integration).

4

Actions are just one-way, it doesnā€™t wait for any kind of confirmation that the entity it was sent to ā€˜receivedā€™ and correctly acted on it. Thereā€™s lots of things that could add a delay between the action being sent and the entity reacting. Also, I can confirm that sending multiple ā€˜parallelā€™ actions to Hue bulbs does NOT result in them reacting in sync (although generally they all react pretty quickly, as in less than a second of each other).

Youā€™ll have to add extra checks for confirmation that the command was received if you want/need that.

5

Transition must be supported by the end device. Some lights do not support transition at all and others support only a limited transition time, defaulting to 0 when an out-of-range value is sent as part of the action.

Are you sure your devices support such a long transition?

6

Yep, that part works perfectly fine in general.

7

Are you sure about it? Iā€™m quite confident I had automations stop in the middle with an error in the automation trace, because shitty Tuya devices bugged out.

But alright, if you are saying this is to be expected and not a bug, itā€™s fine. It should not happen when I target the light group and not individual entities (itā€™s a Hue light group, those do work perfectly in sync).

8

Pretty positive. An error would occur if the device is for instance offline when it tries to send it a command.

9

Thatā€™s a stop action, itā€™s designed specifically to stop a sequence. Otherwise it would simply fire and keep going. The only actions that Iā€™m really aware of that wait to complete before moving to the next action is when you call a script directly with action: script.my_custom_script instead of action: script.turn_on, and delay:.

Also I couldnā€™t find it just now but Iā€™m pretty sure Iā€™ve read in the docs that any list of entities always get processed in order and not in parallel, only groups do that.

10

But you can add code to wait for a specific state:

11

ZHA or Zigbee2MQTT ?
They function differently with respect to waiting for actions to complete.

12

Neither. Itā€™s Hue integration. But itā€™s interesting to know this depends on integration.

13

Today the automation run again, after I changed the action from targeting individual entities to targeting a group. And I was surprised to see the group state to 2 seconds to update, according to the automation trace.

This is all quite surprising to me, because originally (a couple years ago) when I first created this automation, I only had one light in it and it worked fine. Must have stopped working fine when I added the second light a few months ago, I just didnā€™t notice until now.

14

Yeah, this is a good idea, I might do that before the delay step to make sure order is kept.

15

If HA can see the device it will always assume a command sent to it succeeds.
You will have to check the state is suggested by busman to react to an actual change due to the command being sent.
Also a command with a transition is just a single command. The transition is handled by the device, so from HAā€™s point of view the command have succeeded once it has been sent.

If the device/entity is not available or otherwise reported as faulty in HA, then it will fail sending the command, which will break the automation.
I think the continue_on_error command from the script documentation can also be used in automations to force HA to execute the rest of the script/automation.

16

Ok, thanks for the additional information.

As a curiosity - I just tested this with Hue integration and it looks like the Hue bulbs do not report as unavailable in HA when they are in fact unavailable. This must be the integration design, likely intentional due to how people may use those bulbs with physical light switches. But the side effect is that even when they are unavailable, HA will happily process automation without any errors.

17

I have implemented and tested this, it works as expected. Thanks again.

18

I am pretty sure my Hue devices report as unavailable when they are offline.

Remember that this will never be an instant state change, because Ethernet is not aware of the devices actually network connection and the device will not send a message that it is now offline (mainly because it will usually happen due to an error or due to a power cut).
This means a device might take some time to ā€œdieā€ in HA. How long varies from integration to integration and also from connection type to connection type and even device type to device type.
Zigbee devices might have a different timeout for dead devices than WiFi and Zigbee can also have different timeouts for mains-powered and battery-powered devices.

19

Ah, I see. Alright, indeed it took over a half a minute until it switched to unavailable, and HA was happily changing the state during this time. (edit: and it takes 4-5 seconds to make it available in HA after it was powered on again, and then another second for HA to update its state to the correct one)

Make sense, I just thought non-battery devices report much more often, and so their unavailability would be discovered pretty much right away.

20

Yes, I found out about it yesterday when I tried to trigger an automation error by turning on the LED on an offline ESP board. At first I was surprised, but then I realized it was probably a necessity.

Out of curiosity, I tested calling services via the REST API: 1) turning on a light thatā€™s online and already on, and 2) turning on a light thatā€™s offline/unavailable. The response HA sees is the same in both cases:

content: []
status: 200

(this content variable contains a list of entities whose state changed during the execution of the action; they may not be associated with this action at all)