feat(climate): climate schedules, plus fan only and front defrost modes

[joszz]

Pull Request

Summary

Climate schedules: switch climate on at a set time on chosen weekdays, or once, so the car is warm (or cool) when you leave. The saic gateway has charging and battery-heating schedules but none for climate, so GarageStack runs them itself. The climate popup also gains the gateway's two other climate modes: fan only and front defrost.

• Schedules page (sidebar, built like Maintenance): a list of cards and one form to add, edit, switch off or delete a schedule.
  • Start time on a 24-hour clock (hour and minute selects, minutes in steps of five).
  • Weekday chips with Weekdays / Weekend / Every day shortcuts. No day picked runs once, then the schedule switches itself off.
  • Climate mode, temperature, seat heating and rear defroster, reusing the climate popup's controls.
  • Optional "only when it is cold or hot", judged by the car's outside temperature from the last 3 hours. Without a recent reading the schedule runs anyway.
• Climate popup: mode chips (climate, fan only, front defrost) while climate is switched on, and a "Climate schedules · N active" row that links to the page.
• Dashboard: an optional "Climate on" card with the next start, hidden by default.
• Push notifications: one per run in a new "Scheduled climate" type, switchable per device. They say climate started, the car refused (with its reason), or the car did not answer. Skipped and missed runs send nothing.

How it runs

• The Api keeps the schedules (/api/vehicles/{vin}/climate-schedules) and works out each next run on save. A schedule keeps its start time on the clock in the IANA time zone the browser had when it was made, so 07:30 stays 07:30 across daylight saving time.
• The Worker looks for due schedules every 15 s and claims each one before running it, so a restart never runs a schedule twice. A run found more than 10 minutes late is recorded as missed instead.
• It sends the commands one at a time: temperature first (with climate off the gateway only stores it), then the climate mode, then the extras. It stops at the first one refused or unanswered.
• Only the Api publishes MQTT, so the Worker asks for each command on a new pg channel, vehicle_command_requested. The Api sends it through the same checks and one-at-a-time gate as the browser does, and handles it apart from its LISTEN loop so the command_result that frees the gate never queues behind it. The Worker waits for the gateway's answer itself.
• The Api (edits) and the Worker (claims and outcomes) both write a schedule; a Version concurrency token keeps them from overwriting each other.

Shared pieces (reused rather than rewritten)

• VehicleCommands moves to Core so the Worker can name a command's topic. VehicleCommandSender is now the one place a command is checked and published.
• The Maintenance form classes become shared .form-stack/.form-row/.form-group/.form-control, and .maintenance-list becomes .status-card-list.
• The trip-purpose buttons become ChipGroup, which also drives the mode chips and WeekdayPicker.
• useDistanceField becomes useMeasureField(units, quantity), used for the °F/°C thresholds as well.
• The climate popup's slider and switch rows become RangeControl and DetailListSwitch. Its temperature and seat labels move to useClimateLabels.
• StatusCard takes an optional note line under its value.
• Each theme now declares color-scheme, so the browser's own widgets (date pickers, select dropdowns, the icons inside inputs) follow dark mode. This also fixes the Maintenance date picker.
• tzdata is named in the Api, Worker and all-in-one images. All three bases ship it today; this keeps time zones working if a base drops it.

Type of Change

• Bug fix (native pickers and dropdowns were drawn light in dark mode)
• New feature
• Refactor / cleanup
• Documentation
• Dependency update
• Other

Related Issues

None.

Checklist

• Tests added or updated: daylight-saving and multi-zone calendar cases, skip conditions, command plan, validation per error code, repository concurrency, request handler, answer waiter, runner (each outcome and its push), service (claim, missed, interrupted, one run per car), end to end in AuthenticationFlowTests; frontend specs for the utils, API, store, ChipGroup, WeekdayPicker, RangeControl, TimeOfDaySelect, the form modal and the climate popup.
• Linting passes (pnpm lint, pnpm type-check, Prettier, dotnet build, dotnet format --verify-no-changes, no pending model changes)
• No secrets or personal data committed (synthetic VINs only)
• Responsive on mobile (checked 390 and 1440 px in light and dark, no horizontal overflow)
• i18n keys added for any new UI strings (en and nl in parity, notification texts in both resx files)
• If unraid/garagestack.xml changed (it did not; no new environment variables)

Verification

• 889 backend and 815 frontend tests pass.
• End to end against PostgreSQL 18 and Mosquitto in Docker, with the real Api and Worker and a fake gateway answering each /set on /result:
  • A one-off schedule fired within seconds of its time, the Api published temperature 22, climate on, then seat level 1, the schedule switched itself off, and a "Climate is on" notification was written.
  • Against a gateway refusing climate (Failed: vehicle offline), a daily schedule stopped before the rear defroster, recorded failed with the car's reason, moved to the next day, and sent "Climate did not start".
• Both migrations (AddClimateMode, AddClimateSchedules) apply on PostgreSQL 18.
• Demo mode: screenshots of the page, form, popup and dashboard card at both widths and themes; Maintenance and the trip log look unchanged after the CSS moves.

Known limits

• The gateway's answers carry no request id. A command sent by hand at the moment a schedule runs can count as that run's answer: the command still reaches the car, only the recorded outcome can be off.
• In English the dashboard card shows "7:30 AM · Sat" and cuts the day short on narrow cards, as the climate card does; the tooltip has the full text.
• Demo mode has no Worker, so schedules can be edited but never run.
• Not addressed here: the Worker logs "Unmapped telemetry topic" for every /set the Api publishes. This already happens on main for manual commands.

Upgrade note

Two migrations run on Api start. Update the Api and Worker together: the Worker's scheduled commands need an Api that LISTENs on vehicle_command_requested.

🤖 Generated with Claude Code