Roadmap: future enhancements for wallmonitor

[zebraengine]

Tracking list of enhancement ideas for the monitor. Split items into their own issues as they get picked up.

Data lifecycle

• Retention / pruning job — Optional retention: trim old raw JSON, keep every column forever #20 (v0.4.0): --retain-raw-days N blanks the raw JSON on samples older than N days in a daily chunked pass, every extracted column kept forever; --compact VACUUMs once. Off by default — with compressed backups (below) measured at ~12× on a real database, keeping everything is the recommended default.
• Backup helper — feat: one-shot verified, compressed database backup into any directory #26: wallmonitor --backup DIR takes a verified (integrity-checked) online snapshot while running, compresses it (1.4 GB → 111 MB gzip in ~20 s), places it atomically, and rotates by date in the filename. Destination is any directory the user chooses; nothing is scheduled unless the installer's opt-in --backup-dir is given.
• CSV/JSON export — download endpoints for sessions and telemetry ranges, for spreadsheet analysis.

Features

• Charge-cost estimates — configurable utility rate (including time-of-use) → cost per session / per day on the Energy tab.
• Neutral-current chart / phase-imbalance visibility — currentN_a is recorded but not charted.
• Alert-code decoding — map Wall Connector alert names/codes to human-readable explanations (community-sourced, same unofficial-label caveat as EVSE states).
• Local-only notifications for actionable events — Local-only actionable notifications: predicted derate, device alerts, drift tesla-wall-connector#27: predicted derate with a suggested charge-current cap, device alerts, drift/inspect-wiring, charger unreachable; delivered via browser notifications from an open dashboard tab (SSE-fed, no push service) and an optional LAN webhook (WM_NOTIFY_URL).
• ntfy-formatted webhook + deploy recipe — ntfy webhook format + self-hosted ntfy deploy recipe tesla-wall-connector#29: --notify-format ntfy posts warnings directly to a self-hosted ntfy topic (title/priority/tags headers, predicted derate at urgent), with deploy/ntfy/docker-compose.yml for running ntfy alongside the monitor. Field-verified on a real install: instant phone pop-ups with message content staying on the LAN (iOS instant delivery uses the documented content-free upstream wake-up ping; strict-local mode remains the shipped default).

Thermal model

• Ambient for segments that start with a hot handle (cool-down-tail ambient) — Cool-down-tail ambient for segments that start with a hot handle tesla-wall-connector#30: when no flat idle window exists before a segment (stop/resume, post-derate resume), ambient is read from the previous charge's cool-down tail — the closed-form asymptote of the decay at the install's fitted τ, gated on tail length, a visible drop, and decay-fit RMSE. Fits report ambient_source (pre_idle / cooldown_tail) via /api/thermal, so the hardest-working segments now feed the degradation watch instead of being excluded.
• Per-install idle-offset calibration — Idle-offset calibration is one install's numbers — make it per-install (auto-calibrate with a sensor; carry the uncertainty without one) #24: the handle-proxy offset is still one install's constants; auto-calibrate from any ambient sensor present, carry an explicit uncertainty term on sensor-less installs, mark recalibrations on the rise chart.

Local control & sensing (ESP32 nodes)

Small LAN-only ESP32 nodes (e.g. M5Stack AtomS3 Lite) extend the monitor from observing the thermal story to instrumenting and acting on it. Everything below stays on the local network by design.

• Closed-loop derate response — BLE charge-current cap. Shipped: contrib/derate_amp_control.py + backtest_derate_amp_control.py, see docs/amp-control.md. Original design notes kept below for the record. The derate forecast (feat: calibrate the idle-offset model per install from its own sensor history #27) already computes a suggested safe current; today it only notifies. A garage ESP32 running esphome-tesla-ble, paired as a charging-only BLE key (CHARGING_MANAGER role — the vehicle itself rejects everything but charging commands), lets a small contrib/ daemon apply that cap mid-charge. Design settled: cap on predicted derate; restore on the observed charge-completion event (MQTT charging-state transition or the wirebox current dropping to zero — projections go stale the moment the cap changes the charge time); re-assert the correct current at next session start as the safety net for unplug-and-drive. Guard rails: hysteresis around the trip threshold, restore-on-crash, never raise above the user's own limit, dry-run mode like the TeslaMate bridge (#38).
• Structure heat-soak sensor node. The drift watch's biggest confounder is multi-day heat soak of the building/cable — invisible to any single air reading. One ESP32 with an air sensor (BME280/SHT30) plus a strap-on probe (DS18B20) against the wall/conduit near the connector posts both to the existing /api/ambient ingest under distinct source tags. Air-vs-structure divergence measures heat soak directly, turning the rise-vs-ambient scatter's "residual environment effect" from inference into data — and could eventually enter the thermal model as an explicit environment term.
• Garage door state → events + alert. A reed switch on the door feeds open/close transitions into the events stream. Two uses: correlate door state with fitted cool-down τ (a passively vented space cools very differently with the door open), and a local-only ntfy nudge when the door is left open past a configurable duration. Cheapest possible sensor, disproportionate explanatory power for the thermal history.
• (Speculative) Active cooling loop. The AtomS3 Lite carries an IR transmitter; paired with a fan/AC unit it could close the loop from the other side — derate forecast triggers cooling instead of (or before) throttling the charge. Parked until there's powered ventilation to command.

Setup & device identity

• LAN discovery — wallmonitor --discover (LAN discovery and device identity: --discover, serial pinning, --label #11): port-80 sweep of one private subnet + /api/1/version fingerprint; Tesla-OUI neighbours first; never leaves the LAN.
• Serial pinning — LAN discovery and device identity: --discover, serial pinning, --label #11: identity is the serial, verified before the first sample of every run; a different unit at --host alarms and pauses recording.
• Several chargers, one instance each — Multi-instance comfort: --peer header switcher, installer --name, VLAN note #12: --label, --peer header switcher, installer --name. Native single-process multi-device remains parked in Device identity should be the serial, not the IP — and a path to multiple Wall Connectors #10.

Session page

• Forecast hindsight — feat: forecast hindsight — predicted plateau on the session temperature chart #8: the predicted plateau at each 30 s tick drawn against the measured handle curve; gap-aware (Break the forecast line across charging gaps #13) and basis-styled (Forecast overlay: faint model-only ticks, legend says what the line means #15).
• Faster loads — Faster session pages: diagnostics as columns, gzip, rounded JSON #14: diagnostics as columns with a one-time backfill, gzip, rounded JSON.
• Session-end precompute — cache a completed session's downsampled series at close_session so the longest sessions (60k+ samples, ~0.3 s of bucket aggregation) load instantly. Deferred: only worth it if the remaining wait registers after Faster session pages: diagnostics as columns, gzip, rounded JSON #14.

[zebraengine]

Feature idea: thermal-derate prediction (alert 40)

From live telemetry of a real alert-40 event, the trigger is fully deterministic: the alert raises when handle_temp_c reaches 65 °C, derates current to 50%, clears at ~60 °C, and the derate persists for the rest of the session. The handle's heat-up follows a clean exponential (τ ≈ 12 min, ~+36 °C steady-state rise over ambient at 48 A, fit RMSE < 0.1 °C), and idle handle_temp_c sits ~2 °C above ambient, so the monitor already has an ambient proxy without any extra sensor.

That makes prediction feasible with data already collected:

• At charge start, estimate time-to-derate: t ≈ τ·ln((T∞−T_now)/(T∞−65)) with T∞ ≈ ambient + 36 (scale the rise by (A/48)² for lower currents).
• Warn in the UI (and eventually via notifications) when a session is on track to hit 65 °C, or pre-emptively when idle handle temp implies ambient is above the ~29 °C point where a full-current session will always trip.
• Fit τ and the steady-state rise per-install from recorded sessions instead of hardcoding.

Pairs with the future notification feature (mechanism TBD, local-only).

[zebraengine]

Notification mechanism implemented in zebraengine/tesla-wall-connector#27, scoped to actionable warnings (predicted derate with a suggested current cap, device alerts, drift/inspect-wiring, charger unreachable). Two local-only delivery paths: browser notifications from an open dashboard tab (SSE-fed, no push service) and an optional LAN webhook (WM_NOTIFY_URL) for Home Assistant / self-hosted ntfy / Node-RED while no tab is open.

Adding to the checklist:

• Local-only notifications for actionable events — Local-only actionable notifications: predicted derate, device alerts, drift tesla-wall-connector#27