Skip to content

fix: drop the stored auto-reset delay when autoreset_control_seconds is 0 - #1635

Open
BrawnyBravo wants to merge 1 commit into
basnijholt:mainfrom
BrawnyBravo:fix/1631-autoreset-off
Open

BrawnyBravo wants to merge 1 commit into
basnijholt:mainfrom
BrawnyBravo:fix/1631-autoreset-off

Conversation

@BrawnyBravo

Copy link
Copy Markdown

What

AdaptiveLightingManager.set_auto_reset_manual_control_times() returned early when the time was 0. The manager outlives config entry reloads (as long as another profile stays loaded), so the delay stored by the previous configuration stayed in auto_reset_manual_control_times, and set_manual_control_attributes() kept scheduling the auto-reset timer with it. Changing autoreset_control_seconds to 0 therefore had no effect until Home Assistant was restarted.

The setter now removes the light's stored delay when the time is 0 (and still logs the change, e.g. "from 60 seconds to 0 seconds").

I did not cancel a running timer in the setter: a reload already cancels the old profile's timers, and the next manual change calls _handle_timer() with delay=None, which cancels any leftover timer.

Why

With v1.32.0 the auto-reset re-adapts the light immediately (#1506), so a leftover delay is now visible: a manual brightness change gets undone after the old delay even though the option says 0.

How tested

  • New test test_disabling_autoreset_takes_effect_on_reload in tests/test_switch.py: sets up a profile with autoreset_control_seconds: 60 plus a second profile that keeps the manager alive, makes a manual change, updates the options to 0 (which reloads the entry), then makes another manual change and checks that no delay is stored, no timer is created and autoreset_time_remaining is empty.
  • The test fails on main ({'light.light_1': 60} is still stored) and passes with the fix.
  • Full suite as in CI (HA core 2026.9.1, Python 3.14): 493 passed. Coverage 91.2% lines, 84.0% branches.
  • pre-commit (ruff, black, whitespace hooks) passes on the changed files.

Possible behaviour change

When one light is in several profiles and one of them has autoreset_control_seconds: 0, the last profile to set up now wins for 0 as well, the same as already happens between two non-zero values. Before, a 0 profile never overrode a non-zero one.

Fixes #1631

🤖 Generated with Claude Code

…is 0

set_auto_reset_manual_control_times() returned early for a time of 0, so
the delay stored by a previous configuration stayed in the manager. The
manager outlives config entry reloads, so after changing the option to 0
lights kept being auto-reset with the old delay until Home Assistant was
restarted.

Remove the light's stored delay instead, and add a regression test that
reloads a profile with the option set to 0 while another profile keeps
the manager alive.

Fixes basnijholt#1631

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@greptile-apps

greptile-apps Bot commented Oct 10, 2026 •

Copy link
Copy Markdown
Contributor

RetriggerConfidence Score: 5/5

[Medium impact] The PR appears safe to merge.

Summary

Removes a light's stored auto-reset delay when autoreset_control_seconds becomes 0.

  • Setting auto-reset to zero stops future manual changes from starting a timer.

Reviews (1) · Last reviewed commit: "fix: drop the stored auto-reset delay wh..." · Reviewed by Greptile

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Setting autoreset_control_seconds to 0 has no effect until Home Assistant restart

1 participant