fix: disarm schedule slot after momentary runs and settings saves - #35
Conversation
|
Warning Review limit reached
Next review available in: 30 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
set_scheduler always wrote slot 0 as an enabled 00:00-23:59 schedule for all seven days and nothing ever disabled it, so any Run Once press or Save Settings press switched the device into permanent scheduled operation: the app shows Schedule ON, status sticks on diffusing, and power re-enables itself (issue #31). Deleting schedules in the app only helped until the next press. - set_scheduler gains an enabled flag; durations are persisted either way - run_diffuser disarms the slot when the run ends (or when turn-on fails) before sending the off command, so the device cannot re-activate itself - Save Settings persists durations with enabled=0 instead of silently enabling 24/7 operation - the set_scheduler service keeps enabled=true by default and now accepts enabled: false to clear a stuck schedule Fixes #31 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
b2d8018 to
877f0b1
Compare
Covers the configurable SSL bypass (#32), the Power/Fan control split and API reference (#33), schedule disarming after momentary runs (#35), the stale-poll shield (#36), the restored count sensors with long-term statistics (#37), and the MIT license adoption. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Summary
Fixes #31 — pressing the momentary action (Run Once) flipped Schedule mode ON in the Aroma-Link app, leaving the device permanently "diffusing" with power re-enabling itself; schedules deleted in the app reappeared on the next press.
Plan / root-cause write-up: https://plan.dalem.dev/p/s3egdgad
Root cause
set_scheduleralways wrote schedule slot 0 asenabled: 1, 00:00–23:59, all 7 days, and no code path ever disabled it. Perdocs/API.md: "All slots must be disabled (enabled=0) to stop scheduled operation — otherwise the device will auto-toggle power based on time windows." Both Run Once and Save Settings wrote that always-on slot and left it armed.For reference, the original Memberapple/ha_aromalink does the same thing — its momentary run just felt schedule-free because it hardcoded a 5s run and a 900s pause, so the leftover schedule only pumped every 15 minutes. This fix goes beyond both repos by actually cleaning the slot up.
Changes
set_scheduler(..., enabled=True)— slot 0 is written with the requested enabled state; work/pause durations are persisted to the device either way.run_diffuser— when the timed run ends, the slot is disarmed before the off command (so the device can't re-activate itself in between); if turn-on fails mid-sequence the slot is disarmed immediately.enabled=0instead of silently enabling 24/7 scheduled operation.set_schedulerservice — unchanged default (enabled: true), new optionalenabled: falseto save durations with scheduling off, which is also a first-class way to clear a stuck schedule (the manual app workaround from the issue).Behavior change to be aware of
Anyone who used Save Settings as an implicit "run 24/7" toggle must now use the Power switch (manual
onOff=1uses the saved durations perdocs/API.md) or theset_schedulerservice.Verification
workSet(enabled=1) → onOff=1 → workSet(enabled=0) → onOff=0; turn-on failure disarms the slot; invalid durations still short-circuit before any API call.Rollback
Single revertable commit; no config/entity migrations involved.
🤖 Generated with Claude Code