* 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>
* feat: restore missing Russian option labels
Restore the translated option labels from PR #1277 that are still absent on current main. Existing Russian values and stale descriptions remain untouched.
Co-authored-by: belozorov_sv <belozorov_sv@magnit.ru>
* fix: drop ambiguous Russian brightness timing labels
---------
Co-authored-by: belozorov_sv <belozorov_sv@magnit.ru>
Removed a superfluous "Swedish: " from the description of the manual control option.
Co-authored-by: Bas Nijholt <basnijholt@users.noreply.github.com>
Co-authored-by: Bas Nijholt <bas@nijho.lt>
* Enhance Danish translation description for adaptive lighting
Updated the description in the Danish translation for adaptive lighting settings to include documentation and webapp URLs.
* Update custom_components/adaptive_lighting/translations/da.json
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Co-authored-by: Bas Nijholt <bas@nijho.lt>
This avoids running this action on forks, since they likely won't have
issues or topics enabled, and shouldn't need them.
Co-authored-by: Bas Nijholt <basnijholt@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>
Spread recurring updates with a deterministic per-switch offset while keeping turn-on adaptation immediate. Register the delayed listener on Home Assistant's event loop and cover cancellation, reconfiguration, and cadence with real timer tests.
Closes#939.
Co-authored-by: Bas Nijholt <basnijholt@gmail.com>
* Exclude 'service' lights (entity_category) from area intercept turn-on
Fixes#1510
When Adaptive Lighting intercepts an area/label-targeted light.turn_on, the
intercept rewrites the call to target only the managed lights (see
modify_service_data), so Home Assistant's own handler turns on only those.
AL then re-issues light.turn_on for the remaining 'skipped' (unmanaged)
entities so they still come on.
The problem: HA excludes entities with an entity_category (config/diagnostic,
e.g. the Home Assistant Voice LED ring) from area/label expansion, but AL's
re-issue did not, so AL was the sole thing turning these service lights on.
Changes:
- Keep re-issuing skipped lights so unmanaged normal lights still come on,
but filter out 'service' lights (entity_category set) from that re-issue.
- Add _is_service_light helper (registry-based) and divert a *managed*
service light to 'skipped' in _separate_entity_ids, so it is excluded from
the intercept turn-on while still being adapted when on.
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Add toggle regression test for service light exclusion from area intercept
Mirrors test_service_light_excluded_from_area_intercept_turn_on but uses
light.toggle: a service light (entity_category set) in an area must remain
off when AL intercepts an area toggle. The managed lights still toggle on.
Refs #1510, PR #1511.
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Only exclude service lights from indirect (area/device/label) expansion
Previously _is_service_light filtered service lights unconditionally, which
also excluded a service light explicitly named in `entity_id`. Home
Assistant only excludes such lights from indirect area/device/label expansion
and turns them on when directly targeted, so AL must mirror that: service
lights are now excluded from the intercept/re-issue only when not directly
targeted (`direct_entity_ids`).
Adds a regression test for the direct-target case.
Refs #1510, PR #1511.
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Use if/elif/else for indirect service-light exclusion; inline check
Address review: collapse the two separate `if is_service`/"if not
is_service" into an `if/elif/else` chain (ruff PLR5501) and inline the
service check as `self._is_service_light(...) and entity_id not in
direct_entity_ids`, which conceptually is `is_indirect_service`.
Matches HA's indirect-only exclusion and keeps the flow simple.
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Filter service lights directly in _get_entity_list expansion
Move service-light filtering to the single expansion site
AdaptiveLightingManager._get_entity_list. Area/device expansion is the
only place where HA excludes entity_category lights, so filtering there
mirrors HA and makes the later direct_entity_ids / skipped_normal guards
unnecessary. Explicit entity_id targets bypass expansion and therefore
still turn on service lights, matching HA.
Fully reverts the direct_entity_ids / skipped_normal addition per review.
---------
Co-authored-by: mueslo <mueslo@users.noreply.github.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Bas Nijholt <basnijholt@gmail.com>
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>
Handle missing polar sunrise and sunset with a shared fallback. Bound offsets between actual solar anchors while preserving the daily lighting cycle and configured time behavior.
Co-authored-by: Oscar Pacheco <oscar@gigadefense.com.mx>
* Adopt has_entity_name to fix duplicated entity ids on HA 2026.4+
Since HA core 2026.4 (PR 166246) composes entity names as device name +
entity name, and only strips the device prefix when the entity name
starts with it. Adaptive Lighting's names ('Adaptive Lighting Sleep
Mode: stairs' on device 'Adaptive Lighting: stairs') never match, so
new installs get ids like
switch.adaptive_lighting_stairs_adaptive_lighting_sleep_mode_stairs.
Adopt has_entity_name: the main switch takes the device name
('Adaptive Lighting: <name>'), the simple switches use their role
('Sleep Mode', 'Adapt Brightness', 'Adapt Color'). Unique ids are
unchanged, so existing installs keep their entity ids via the registry.
Fixes#1459
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Test the new entity ids and that existing ones survive
The renamed constants were defined but never asserted, so neither the
fresh-install ids nor the registry-preservation claim were covered.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* test: keep the apply-service test light on
Avoid generating brightness zero in the attribute-change helper, which turns the light off and makes the test depend on the current adaptive brightness.
---------
Co-authored-by: proscar87 <proscar87@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Bas Nijholt <bas@nijho.lt>
Co-authored-by: Bas Nijholt <basnijholt@gmail.com>
* fix: clamp() collapsed to minimum when min_brightness > max_brightness
A user can intentionally set min_brightness > max_brightness (or the
equivalent for color temperature) for an inverted timescale -- e.g. a
porch light that should be brighter at night than during the day.
clamp()'s max(minimum, min(value, maximum)) assumed minimum <= maximum;
when inverted, min(value, maximum) is always <= maximum < minimum, so
max(minimum, ...) always returns minimum. linear and tanh brightness
modes -- both of which end in a clamp(brightness, min_brightness,
max_brightness) call -- got stuck returning one fixed value regardless
of the time of day.
Fixes#1421
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* test: accept current Home Assistant brightness validation errors
Keep asserting the maximum brightness limit without depending on the validation library's dictionary-path wording.
---------
Co-authored-by: Oscar Pacheco <proscar@MacBook-Pro-de-Oscar.local>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Bas Nijholt <bas@nijho.lt>
Co-authored-by: Bas Nijholt <basnijholt@gmail.com>
When the auto-reset timer fired, its callback called manager.reset(),
which pops the timer and calls timer.cancel() - cancelling the very task
that was running the callback. The manual_control flag was cleared, but
the re-adaptation that should follow was silently cancelled, so the light
only changed on the next interval pass (with the normal transition).
_AsyncSingleShotTimer.cancel() now never cancels the task that is
currently running its own callback. The trailing assert in the callback
is removed because it is reachable now and could trip when a new manual
change comes in while the re-adaptation is still running. The existing
auto-reset test also checks that a light.turn_on with the 'autoreset'
context is sent.
Fixes#1233
Co-authored-by: Dennis-Dekker <>
Co-authored-by: Bas Nijholt <bas@nijho.lt>
* Fix options flow changes being silently discarded for UI-configured entries
validate() merges config_entry.options then config_entry.data, on the
assumption that data only ever holds YAML-imported settings (which should
win) or, for UI-created entries, just the entry name (harmless to apply
last).
That assumption doesn't hold for entries created before data/options were
split: their data still carries the full settings snapshot from initial
setup. Applying it after options means any change made through the options
flow for a key that already exists in data (e.g. adding a light) is
silently ignored, even though the options flow reports success and the
entry reloads without error.
Reproduced on a real entry: added a light via the options flow, entry
reloaded cleanly, but the light was never picked up by the switch's
service-call interceptor ("No switch found for entity_id=...") because
data still held the old light list and clobbered the updated options.
Fix: only let data win over options for genuinely YAML-imported entries
(config_entry.source == SOURCE_IMPORT), matching the existing use of that
check elsewhere in this file. For UI-configured entries, apply options
last so changes made through the options flow actually take effect.
* Add focused tests for the data/options merge order in validate()
Covers both source-specific contracts the merge logic relies on, per
review feedback on this PR:
- SOURCE_USER: options must win over data (this PR's actual fix - proven
to fail against the pre-fix code, verified locally by reverting
switch.py and re-running).
- SOURCE_IMPORT: data must keep winning over options (the existing,
intentional YAML-precedence behavior - unchanged by this PR, verified
to already pass against the pre-fix code too).
Verified against a real Home Assistant instance's test harness
(pytest-homeassistant-custom-component + the actual installed
homeassistant package), not just reasoned about statically.
---------
Co-authored-by: Bas Nijholt <bas@nijho.lt>
