adaptive-lighting/custom_components
Bas Nijholt 3638fb3013
fix: don't cancel adaptation when a light group turns on via a member with a reused context (#1483)
* fix: don't cancel adaptation when a light group turns on via a member with a reused context (#1378)

When a member of a light group is turned on (e.g., by a motion sensor
automation) while the group is off, the group turns on as a side effect,
but Home Assistant may reuse the context of the earlier turn_off call for
the group's state change. just_turned_off() saw matching context IDs and
treated the state change as a polling artifact, cancelling adaptation.

- Check whether the off->on state change comes from a light.turn_on call
  before the matching-context polling-artifact check, so automations that
  turn a light off and back on with a single (automation) context adapt
  correctly.
- For light groups, allow adaptation when a member's turn_on event falls
  between the group's on->off and off->on state changes, bounded on both
  sides so stale member events are never treated as explanatory.
- Document that integration-level groups (e.g., Zigbee2MQTT groups) should
  not be nested inside HA Light Groups managed by Adaptive Lighting.

* fix: time-bound the same-context turn_on check instead of reordering

Address review findings:

- Reordering the turn_on-service check above the matching-context check
  reintroduced stale-event false negatives: turn_on_event entries are never
  cleaned up, so a 'turn_on -> delay -> turn_off(transition)' automation
  (one shared context) would defeat the polling-artifact guard and AL could
  turn a light back on right after it was turned off. Restore main's check
  order and instead add a time-bounded own-turn_on check inside the
  matching-context branch, symmetric with the group-member check. This
  also avoids emitting the 'should not happen' warning for self-context
  polling artifacts.
- Add a regression test for the stale same-context turn_on case.
- Add an end-to-end test driving the event-bus listeners for the #1378
  scenario (group kept in manager.lights, as in the reported setups).
- Docs: drop the inaccurate 'expands only one level deep' claim; explain
  that integration-level groups cannot be expanded and nested groups make
  tracking unpredictable.
2026-07-02 08:08:14 -07:00
..
adaptive_lighting fix: don't cancel adaptation when a light group turns on via a member with a reused context (#1483) 2026-07-02 08:08:14 -07:00