Add built-in CalDAV server for calendar-based planner constraints

[frahlg]

Feature description

Add a built-in CalDAV server to forty-two-watts so users can add planning constraints from whatever calendar app they already use.

Example calendar events:

• Away mode / vacation mode for a heat pump.
• A departure time where an EV must be fully charged.

Motivation

The planner could use this calendar-derived context to make better decisions ahead of time instead of only reacting to current telemetry and forecasts. This would make common user intent — being away, needing a charged car, or shifting thermal loads — easy to express without requiring a custom UI.

Proposed solution

Expose a local CalDAV endpoint from 42W and map calendar events into planner constraints/intents, such as:

• away intervals for heat pump or household load planning.
• EV departure deadlines with required state of charge.
• Future extensibility for other scheduled energy intents.

The user should be able to use any standard calendar app that supports CalDAV.

Original request

It would be nice if 42W had a built-in CalDAV server where you could easily, through whichever calendar app you use, add things like away mode for the heat pump or a departure where the car must be fully charged, so the planner has more information to work with.

Requested by Hugge in Discord.

[frahlg]

Additional requirement from Hugge in Discord:

The feature should also support calendar subscription/export in the other direction: users may want to subscribe to an iCal calendar, or another CalDAV calendar, provided by 42W.

In other words, 42W should ideally support both:

• inbound calendar input: users create/edit calendar events in their existing calendar app and 42W consumes them as planner constraints/intents;
• outbound calendar publishing: 42W exposes an iCal/CalDAV calendar that users can subscribe to, so planned energy actions, charging windows, away-mode interpretation, or other schedule-derived decisions can be visible in their normal calendar app.

[HuggeK]

Maybe use https://radicale.org/v3.html

[HuggeK]

🚧 Work has started on this (branch worktree-caldav-planner-498).

Approach: Radicale runs as a bundled sidecar container (mirroring the existing Mosquitto block in docker-compose.yml) and owns the CalDAV server correctness; 42W is a CalDAV client that polls the calendar and maps events into existing planner surfaces. This keeps the Go binary pure-Go / single-binary and avoids putting a WebDAV stack behind the owner-auth gate.

Phase 1 — inbound (consume events) first:

• Away / vacation → drives the planner via the existing loadmodel away profile (~25% load) for the interval; no driver commands in this cut.
• EV "charged by departure" → reuses loadpoint.Manager.SetTarget → the MPC's existing target-SoC + deadline penalty, so no planner-core changes needed.
• Event classification by title keyword (configurable for localisation), e.g. "Away", "Charge car 80%".
• New go/internal/calendar polling service + GET /api/caldav/status diagnostics + a Calendar settings tab showing the subscribe URL/credentials.

Phase 2 (follow-up): outbound read-only iCal feed of the plan (charging windows, away interpretation, EV target windows) that users can subscribe to.

Note: went with the Radicale sidecar (per the suggestion above) rather than a native-Go CalDAV server — Radicale handles the hard sync-with-iOS/Google/Thunderbird correctness while 42W stays a simple client.

[HuggeK]

Implemented on branch worktree-caldav-planner-498 — both directions, both phases.

Approach: Radicale runs as a bundled, LAN-only sidecar (compose --profile calendar); 42W is a CalDAV client, which keeps the Go binary pure/single-binary and avoids putting a WebDAV stack behind the owner-auth gate.

Phase 1 — inbound (events → planner): classified by title keyword.

• Away / Vacation → load model's away profile for the interval (planner conserves battery), via an away-aware per-slot MPC predictor.
• Charge car 80% → loadpoint target SoC + deadline (reuses loadpoint.Manager.SetTarget → the MPC's existing deadline penalty).

Outbound — EVSE history: one read-only event per completed charge session ("EV charged 12.3 kWh").

Phase 2 — outbound plan: publishes the MPC's upcoming charge/discharge windows as a read-only calendar, reconciled each replan (PUT changed / DELETE stale) so it never piles up. Intent / history / plan live in separate collections so 42W never re-reads its own output.

Opt-in + fail-soft; entirely LAN-only (never routed through the owner relay). Verified end-to-end against a real Radicale (inbound parse, history write, plan publish + reconcile).

Branch: https://github.com/HuggeK/forty-two-watts/tree/worktree-caldav-planner-498 · commits 6a2af88 (phase 1), 8326680 (phase 2).

[HuggeK]

Heads-up on the calendar feature + Home Assistant add-on — cc @erikarenhill (maintainer of erikarenhill/ha-addon-forty-two-watts).

The calendar feature uses a bundled Radicale CalDAV sidecar. Radicale is GPLv3, so to keep 42W cleanly separable and permissively licensable (we're looking at MIT/Apache-2.0), Radicale has to stay at arm's length — its own container, reached only over the CalDAV network protocol. The compose file just references the public image (pulled at runtime); we never bundle or redistribute Radicale's code.

The consequence: a single-container HA add-on can't host the sidecar, so the calendar feature can't work there as-is. To avoid a confusing half-broken state, 42W now auto-detects the add-on deploy mode and disables the feature, with the Settings → Calendar tab explaining why (commit on branch worktree-caldav-planner-498, PR #531):

• Detection: runningAsHAAddon() checks FTW_HA_ADDON=1 first, then falls back to SUPERVISOR_TOKEN / /data/options.json.
• GET /api/caldav/status returns {enabled:true, available:false, unavailable_reason:"ha-addon"} and the UI shows a clear message.
• Override: FTW_CALDAV_FORCE=1 re-enables it (for anyone running a separate Radicale add-on and pointing caldav.url at it).

@erikarenhill, a small ask: could the add-on set FTW_HA_ADDON=1 in its container env? That's the reliable signal (the Supervisor-token fallback only fires if the add-on requests hassio_api).

TODO — first-class HA OS / HA Supervised support. Two paths worth discussing:

1. A separate Radicale add-on that 42W dials over the Supervisor network (works today via FTW_CALDAV_FORCE=1 + caldav.url).
2. A native, in-process CalDAV server in 42W using emersion/go-webdav (MIT) — no sidecar, pure-Go, single-container, so it'd work identically in the add-on and everywhere else, and it sidesteps the GPL issue entirely. This is the cleaner long-term answer; happy to prototype it behind a config flag.

Which direction makes more sense from the add-on side?