The lighting group (or multiple light bulbs) seems to be activating “turned on” triggers when the turn off transition is set to a longish period (10s or longer). Meaning the light doesn’t turn off.
First, purpose of this automation: to sync light with scenes based on input_select light mode no matter how the light is turned on.
So, logically, the trigger should be “when light is turned on”
trigger:
- platform: state
entity_id: light.stairway_bulbs_all
id: stair
from: 'off'
to: 'on'
- platform: state
entity_id: light.hallway_bulbs
id: hall
from: 'off'
to: 'on'
Then call turn-off with long transition on any of those lighting groups, this trigger is activated. Short (1s) or no transition does not activate this trigger. Sometimes lights doesn’t turn on, but in the log file this automation does get triggered. Sometimes light turns back on.
So I thought might be Deconz light group that’s confusing HA? I created light group of same bulbs in HA and same trigger behaviour is observed.
The bulbs are Ajax colour GU10 for hallway and Ikea white spectrum GU10 for stairway. So shouldn’t be the bulbs.
Any ideas? Any other trigger method for turn-on events in a foolproof way that doesn’t get false positives?
Is a 1 second delay acceptable? If so could add for: 00:00:01 to it ignore state change flickers.
If not then I would consider watching the actual light devices as opposed to the virtual light group. I assume the physical devices do not have this issue and it’s coming from effectively rounding errors when averaging the state over the group.
Yes, that is my line of thinking, perhaps some sort of rounding error that caused glitches. I tried for: 200 millisecond, the automation still get triggered. Not sure why though. The delay is undesirable from usability point of view.
I’ve also experimented with monitoring single bulb out of the group. Seems to get same problem, might be bulb related? But I find it strange bulbs from different brands (Ajax and Ikea) behave the same. However, monitoring a LEDadvance colour bulb (my test bulb in the study) does not observe the same behaviour. Hence I thought it was more to do with light-group.
Currently I’m getting around it by disabling the automation for same or longer duration as transition. For example 20 second transition, so turn off the automation for 21 seconds. This works as originally intended but this feels like a bodge rather than using a more robust trigger method.
If it’s happening when listening for state changes on the actual physical devices then I think you might have found a bug with transition. I can’t really fathom how it could be going from off back to on during a transition to off. Think you should report it here.
Even the behavior with light group sounds like a bug tbh I just felt like the rounding error thing might be an explanation for that. But it still shouldn’t turn on during a transition to off.