[pponce]

Problem and result

Imported schedules need local execution while preserving their native timer links and cleaning settings. This change builds on virtitnerd's scheduler in #179 and adds native timer verification, durable occurrence claims and capture-compatible job handling.

Dependency and review order

This branch includes the original #179 commits with attribution preserved. Please coordinate with #179 rather than treating this as an independent replacement. Preferred order: merge #179, then review/merge the remaining hardening here. If #179 is squash-merged or changed, I will update this branch so its diff contains only the remaining changes.

What this adds beyond #179

#179 supplies the schedule store, job API, local scheduler and native start command. My additions are:

• Check the matching native timer is on before dispatch and recheck the job/deadline after the network wait.
• Remove native-start fallback to an ordinary clean on refusal, so a rejected timer cannot be bypassed.
• Persist occurrence claims across restart/cloud refresh and skip missed recurring occurrences rather than draining historical work.
• Preserve the complete imported settings payload and unknown fields.
• Add explicit DST policy, persistence/error validation and regression tests.
• Synchronize native schedule enablement across clients, preserving job IDs, cleaning settings and occurrence claims. Reject stale or ambiguous updates and avoid re-enabling consumed one-time schedules during background polling.

These include behavioral choices (at-most-once dispatch, missed-run and DST policy) for maintainer review, not claims of complete cloud parity.

Changes

• Job CRUD APIs, timezone-aware next-run calculation and local dispatch from Add server-side scheduling that runs jobs the way the cloud does #179.
• Preserve complete settings, unknown fields and the distinction between HTTP job IDs and native timer names.
• Forward native server_timer RPCs unchanged; keep the legacy timer compatibility view separate.
• Read the native timer before dispatch; off, missing, ambiguous or unreachable state prevents a start.
• Never substitute an ordinary clean after a refused or timed-out native scheduled start.
• Persist occurrence claims before sending, retain claims across cloud refresh, and recheck edits/deadlines after network waits.
• Add API, persistence, clock/DST, dispatcher and timer regression coverage.

Validation

I tested with a Roborock S7 (roborock.vacuum.a15, firmware 02.16.12). The local server successfully started the vacuum at its scheduled time. I used LocalRock and the OEM Roborock app for schedule control. This is a confirmed scheduled-start scenario.

Python 3.11/3.13 tests and the Docker build passed at d5ada08d: [passing checks](https://github.com/pponce/local_roborock_server/actions/runs/40226190127).

The new enablement synchronization has automated coverage for native MQTT forwarding, HTTP updates, concurrent edits, lost acknowledgements and one-time schedule handling.

Scope and companion PRs

• Admin dashboard, schedule editor and per-vacuum MQTT credential recovery: Add standalone admin schedule editor and per-vacuum MQTT recovery #214. That PR depends on this server work.
• LocalRock schedule UI and verified enablement synchronization: Manage server schedules and verify native enablement synchronization DonSidro/LocalRock#60. It requires the server schedule API/executor but does not depend on the admin dashboard.

Preferred merge order: coordinate and merge #179, then the remaining hardening in this PR. Afterward, #214 and the agreed LocalRock integration can proceed independently.

The local server now synchronizes native schedule enablement across clients: changes made through Homebridge, LocalRock, or the OEM app for example are reconciled with the saved server job after a fresh robot timer read. Background reads recover missed updates, while HTTP job updates that supply enabled verify the native timer before saving.

[virtitnerd]

Thanks for building on #179 and for keeping the original commits attributed. Since this branch carries the #179 commits and is meant to merge right after them, would you open it as a PR into the #179 branch (virtitnerd:feat/schedule-store) instead of a separate PR to main? I'll review it there and merge it, so your commits land in #179 with your authorship and the maintainers get one schedule PR to review, with one merge in the right order.

Nothing in the description needs to change for that. The native timer check before dispatch, no fallback to an ordinary clean after a refused start, persisted occurrence claims and the DST policy can all go in as the hardening section of #179.

Two small things while it moves: the schedule-tests.yml workflow probably should not ride along, since the LocalRock owner turned down per-PR workflows there and the same may apply here. And the LocalRock side (#37 and #60) will read the jobs API and need #213's behaviour, so I'll note #179 plus the hardening as the minimum server version over there.

[pponce]

I’ve submitted a separate PR into @virtitnerd’s feat/schedule-store branch so this hardening can land through #179 as one combined scheduling contribution. The tests are retained; the feature-specific schedule-tests.yml workflow is excluded.

I’m keeping #213 open as a reference until the combined work is merged.