Skip to content

v2.0.39 — Schedule enforcement bounded to a 5-minute window

Latest

Choose a tag to compare

@github-actions github-actions released this 09 Jun 12:39

Refine: Schedule-rule enforcement bounded to a 5-minute window so humans can override

Symptom (user-reported after v2.0.38): the new continuous enforcement was too aggressive. After a 10:30 PM OFF rule fired, the scheduler kept turning the device off every 10 s if anyone touched it later in the evening — treating deliberate human override as drift to be corrected. Light-switch behaviour felt possessive.

Fix in packages/homebridge-plugin/lib/scheduler.js

  • New constant ENFORCEMENT_WINDOW_MS = 5 * 60 * 1000.
  • _pollDeviceHealth now checks Date.now() - intended.since < ENFORCEMENT_WINDOW_MS before re-asserting. Past the window, the _intendedState entry is deleted so it isn't even re-examined on subsequent polls.
  • _seedIntendedState records since as the actual fire time today (dayStart + entry.targetSecs * 1000), not Date.now(). Entries already past the window aren't seeded at all — a Homebridge restart at 11 PM after a 10:30 PM OFF rule no longer re-engages enforcement and respects whatever state the human chose during the gap.

Behaviour now

Time after fire What happens
0 – 5 min Scheduler re-asserts intended state on every 10-second health poll. Catches silent SOAP failures, confirm-read races, fast accidental toggles.
5+ min Scheduler stops watching this device until the next Schedule fire. Human flips light → light stays in the state the human chose.

The 5-minute window is generous enough to mop up every realistic transient failure (Wemo radio asleep, SOAP timeout, confirm-read race), and tight enough that a deliberate human override is honored quickly.

AlwaysOn rules retain their unbounded enforcement — turn-on is unambiguous, no window needed. Schedule rules are the only ones with the new window.

Affected packages

All monorepo packages bumped to 2.0.39 in unified versioning. Functional change is confined to homebridge-dibby-wemo@2.0.39; every other surface gets the version bump but no functional change beyond carrying forward v2.0.38's enforcement infrastructure, v2.0.37's location-search hybrid response, v2.0.36's DwmStore atomic writes, and v2.0.35's Synology Docker root-fallback.

Upgrade

  • Homebridge: npm install -g homebridge-dibby-wemo@2.0.39 → restart Homebridge. Same [enforce] log lines on drift inside the 5-minute window; nothing in the log outside it.
  • Synology Container Manager / Docker: Stop → Build → Start (:latest now points at 2.0.39; no functional change vs 2.0.38).
  • Synology .spk: download the new .spk for your arch → Package Center → Manual Install (no functional change).
  • Node-RED: npm install -g node-red-contrib-dibby-wemo@2.0.39 (no functional change).
  • HACS: ⋮ → Reload data → Dibby Wemo → ⋮ → Redownload → 2.0.39 → restart HA (no functional change).
  • Desktop installers for Windows / macOS / Linux ship a version bump only; no functional change vs 2.0.38.