My guess is the 'randomness' and increase in probability of interruption comes from two factors:
(1) how long the AL loop is (I believe the default one is 90 seconds)
(2) how far along the current loop we are, i.e. how many seconds are left until AL attempts to update the lights again
I have Philips Hue lights and I've been able to reliably reproduce that issue with the config pasted below.
I haver tried this with "detect non-ha" changes OFF and ON and it made no difference. Note that I only issue the 'light turn off' service call from HA anyway but wanted to be sure just in case. Predictably it made no difference.
I can reproduce this with various values for transition, from 5 seconds up to 100 seconds though it doesn't happen every single time for the smaller values but it DOES happen after a few tries.
Interestingly the above service calls gets the lights in one of three states randomly:
(1) sometimes when AL intercepts the transitioning-to-off, it starts fighting with the lights and they go up in brightness but then eventually do DO start dimming and go OFF completely. But HA (and the Hue hub itself!) think the lights are ON even though they are visibly completely OFF. This is by far the craziest case. My guess is that it has to do with a behavior of specifically the software running on the lights themselves and how they interpret conflicting commands from the Hue Hub with long transition times (since both AL and my service call to turn them off have long transition times).
(2) in many cases, AL intercepts the lights and "wins over" somewhere midway through the lights' transitioning-to-off, so the lights suddenly stop dimming and start brightening up again and then remain fully ON as if I had never executed the service to turn them off. AL continues to adapt them as normal.
(3) in some cases, the lights correctly transition successfully to off.
I had the idea to try and set the manual control to true first, then invoke the service call to turn them off with a transition. However, as soon the service call fires, the lights are immediately registered as OFF by HA and the Hue Hub even though they are still gradually dimming and apparently AL has this feature where it resets the manual control list as soon as the lights are off. So it doesn't seem like this does anything.
The only thing left for me to try is to completely turn off the AL switch for the lights, add a delay equal to the transition of the lights + 500s for a bit of a buffer and then turn the AL switch back on. Not very satisfying.
It would be good to examine the behavior of AL around long transition times and how that plays with the internal modeling of HA.
Completely separately, It might also be good to provide an option to DISABLE the clearing of the manual control list when lights are turned off. I understand adding more complexity is probably not good and I understand the reason for this behavior (to cater to 95% of cases where once lights are off, you probably want AL to be reenabled for next time you turn them on). But it would be nice to have that flexibility since I have a lot of manual control settings via automations.
My guess is the 'randomness' and increase in probability of interruption comes from two factors: (1) how long the AL loop is (I believe the default one is 90 seconds) (2) how far along the current loop we are, i.e. how many seconds are left until AL attempts to update the lights again
I have Philips Hue lights and I've been able to reliably reproduce that issue with the config pasted below.
I haver tried this with "detect non-ha" changes OFF and ON and it made no difference. Note that I only issue the 'light turn off' service call from HA anyway but wanted to be sure just in case. Predictably it made no difference.
I can reproduce this with various values for transition, from 5 seconds up to 100 seconds though it doesn't happen every single time for the smaller values but it DOES happen after a few tries.
Interestingly the above service calls gets the lights in one of three states randomly:
(1) sometimes when AL intercepts the transitioning-to-off, it starts fighting with the lights and they go up in brightness but then eventually do DO start dimming and go OFF completely. But HA (and the Hue hub itself!) think the lights are ON even though they are visibly completely OFF. This is by far the craziest case. My guess is that it has to do with a behavior of specifically the software running on the lights themselves and how they interpret conflicting commands from the Hue Hub with long transition times (since both AL and my service call to turn them off have long transition times).
(2) in many cases, AL intercepts the lights and "wins over" somewhere midway through the lights' transitioning-to-off, so the lights suddenly stop dimming and start brightening up again and then remain fully ON as if I had never executed the service to turn them off. AL continues to adapt them as normal.
(3) in some cases, the lights correctly transition successfully to off.
I had the idea to try and set the manual control to true first, then invoke the service call to turn them off with a transition. However, as soon the service call fires, the lights are immediately registered as OFF by HA and the Hue Hub even though they are still gradually dimming and apparently AL has this feature where it resets the manual control list as soon as the lights are off. So it doesn't seem like this does anything.
The only thing left for me to try is to completely turn off the AL switch for the lights, add a delay equal to the transition of the lights + 500s for a bit of a buffer and then turn the AL switch back on. Not very satisfying.
It would be good to examine the behavior of AL around long transition times and how that plays with the internal modeling of HA.
Completely separately, It might also be good to provide an option to DISABLE the clearing of the manual control list when lights are turned off. I understand adding more complexity is probably not good and I understand the reason for this behavior (to cater to 95% of cases where once lights are off, you probably want AL to be reenabled for next time you turn them on). But it would be nice to have that flexibility since I have a lot of manual control settings via automations.