* Add minimum brightness automation and blueprint
* Ignore independent profile event order in test
* Add tested blueprints for sleep, schedules, and daylight
* Register service actions in async_setup for Bronze tier compliance
- Move 'apply' and 'set_manual_control' service registration from async_setup_entry to async_setup.
- Move service handlers to module-level functions in switch.py.
- Update apply_service_schema to support dynamic defaults for transition duration.
- Clean up related unused imports and fix Python 3.10 syntax compatibility.
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Clean up and add tests
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Fix lint errors
* Automated update of generated docs
* Re-add types
* Make transition not required again
* fix: validate global service targets
* fix: document optional apply transition
* fix: derive service docs from schema markers
* docs: clarify service target options
* fix: preserve entity service target handling
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Bas Nijholt <bas@nijho.lt>
* Disable manual control reset on sleep mode change
* adapt test to new behavior
* fix comment
* add switch + test
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Update auto-generated content
* fix: preserve existing sleep-toggle reset defaults
* fix: keep cancelling stale adaptations on sleep changes
---------
Co-authored-by: Bas Nijholt <basnijholt@users.noreply.github.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Bas Nijholt <bas@nijho.lt>
* Fixed outdated info in README.md
The README says to always add an adaptive_lighting: entry in the YAML, where this seems to be no longer needed (or even preferred).
* docs: clarify YAML is optional for UI setup
---------
Co-authored-by: Bas Nijholt <basnijholt@users.noreply.github.com>
Co-authored-by: Bas Nijholt <bas@nijho.lt>
Adds two new read-only state attributes on the AdaptiveSwitch entity:
- manual_control_brightness: list of light entity_ids whose brightness
axis is currently in manual override (i.e. AL is paused for brightness
on those lights).
- manual_control_color: same, for the color axis.
These mirror the existing 'manual_control' attribute (which is a
union of both axes) but expose the LightControlAttributes bitfield
that AL already tracks internally per-light.
Why: the existing 'manual_control' state attribute and the
adaptive_lighting.manual_control event are useful, but neither lets
a template or dashboard see which axis is paused without subscribing
to events. This is especially important with take_over_control_mode:
pause_changed, where one axis can be manual while the other still
adapts. Now a Lovelace card or template sensor can display
brightness/color manual state directly via state_attr().
Test: extends test_manual_control to assert the new attributes
reflect the bitfield correctly.
No new platform, no breaking changes.
Co-authored-by: Bas Nijholt <basnijholt@gmail.com>
* 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.
