In trying to investigate an issue I documented in the thread Light Groups control order, I made a pair of simple scripts to turn on and off a set of lights and a light template to run it:
Notice I use two different approaches for ‘on’ and ‘off’. ‘On’ uses a single variable defined as a list of entities whereas ‘Off’ uses multiple variables, one for each entity. There is a difference in behavior too.
Turning ‘On’ the switch template results in the underlying entities being turned on in a random order. Additionally, the script takes an extra second or two at the end during which I have no clue what it’s doing. If I attempt to turn off the switch before the script has completed, it results in all of the entities turning off, followed by at least one turning back on, resulting in a mixed state.
Turn ‘Off’ the switch template however results in predictable order execution, always entity_id1, then 2 and then 3. There is no delay at the end.
Does anyone have any ideas that can explain the ‘on’ behavior? This is the syntax I’d prefer to use for reusability among multiple device groups. This behavior is remarkably similar to the behavior of entities in a switch group as I explain in the thread linked above. Hoping to track down the root cause of this.
Otherwise, any suggestions on better ways to pass a variable length list of arguments to a script without explicitly naming each one?
The script had no delays in it, so it should all be instantaneous either way. If its not, then there’s some other problems going on there and he’s just hoping to mask the problem with ‘oh yeah, it’s intentional they come on like that’.
Homeassistant will just loop through the entities in a fraction of a second, and they should all come on at the same time as the microsecond delay between each one is imperceptible.
If there is some kind of network congestion that is causing that delay to be perceptible, then there is no way to guarantee that that congestion will be predictable and always work in a certain order.
The only way to guarantee light 1 > wait > light 2 > wait > light 3 would be to add delays to the script that were definitely longer than the expected delay from network congestion, but tbh I think that would look like you had power problems anyway. A far neater/cooler option for that case (once the fault was fixed) would be a slow transition on light 1, a slightly longer one on light 2, and slightly longer again on light 3, or better yet independent control of each light when it’s actually needed.
Thank you all for your help, but the entire point of this post and my previous post is that it’s not instantaneous.
Light groups can’t guarantee the order, and it seems that whichever device gets in first blocks the others for at least a second. I thought I’ve managed to replicate this behavior with my original ‘on’ example since it exhibits the same behavior. I fixed my ‘on’ example as follows, but it still exhibits the out of order execution:
hall_lights_on:
sequence:
- service: light.turn_on
data_template:
entity_id: "{{ entity_id }}"
mode: single
alias: Hall Lights On
I’m next going to try splitting the entity_id string in here and assigning it to multiple services in the sequence. This should give me execution similar to the ‘off’ example.
As I explain in my original post Light Groups control order, I’m trying to guarantee that the switch with the actual light attached (the load) turns on first. Something funky is going on with the delay of the second and third devices; I’m 100% sure it’s not due to network congestion and suspect it could be due to HA or the ISY integration; although it could be the ISY hardware queueing up commands too, in which case this workaround is the best I’ll do. That’s another issue I’m trying to track down.
Either way, however HA should absolutely be able to control the order of the devices as I demonstrated in the ‘off’ experiment. I just want to use a list syntax similar to ‘on’ so I can reuse the script for multiple device groups.
And yes, that’s exactly what I’m trying to do. If the load comes on first, it will seem instantaneous even if the remotes lag a little bit behind. Ideally everything would come on instantaneously and I wouldn’t care. But it seems like I’m dealing with two problems that together cause an issue for me, and I’m trying to solve at least one of them.
For anyone who experiences similar issues, this is what I ended up with so far. With the YAML repeated node syntax @anon43302295 shared, the template isn’t too bad to duplicate for each light group:
Note the scripts will work for two or three entity arguments. It can easily be expanded to support other light functions (color, etc.) or handle a larger group. I may fiddle around with the script ‘mode’ if I find preemption to be an issue. A variable length argument would have been ideal, but I guess this will have to do. I’ll likely open another thread about the blocking issue.
Also, if you have any thoughts/tips how the template could be optimized further to reduce duplication or otherwise, please share. HA is still new to me and I’m only beginning to scratch the surface. Can this be put into a blueprint? I have a lot of lights .
Thanks.