Device identity should be the serial, not the IP — and a path to multiple Wall Connectors

[zebraengine]

The DB has no device dimension: every table implicitly describes "the one charger" at --host. That assumption deserves to be made explicit and defended, because if a second Tesla device ever answers at the configured address (DHCP reshuffle, multi-WC household, power-sharing group), its telemetry blends silently into the thermal fit, degradation trend, sessions, and lifetime counters — per-install models corrupted with no warning.

Phase 0 — serial pinning (protective, cheap, benefits single-device installs today)

• On first contact, store the device serial (from /api/1/version) in settings; verify on startup and periodically.
• On mismatch: raise an alert and stop recording rather than blend histories.
• Show the device (serial tail or user label) in the UI header and in notifications.
• --discover (planned) lists all units found, never assumes one.
• Once identity is serial-based, --host is just transport: on unreachable, discovery can re-find the charger by serial and heal the config.

Phase 1 — multiple WCs via process-per-device

• One instance per charger: own DB, own port, systemd template unit (wallmonitor@<name>.service).
• Keeps every model per-install by construction; needs docs + service template, no schema change.
• Limitation: no cross-device dashboard.

Phase 2 — native multi-device (only if demand appears)

• devices table keyed by serial; device_id on all sample tables; per-device pollers and calibrations; UI device switcher; migration backfills existing DBs as device 1.

Open question: power-sharing groups — per-unit vitals are fine, but automatic amp control against a group leader/followers needs design before anyone automates it.

[zebraengine]

Status as of 0.2.x → main:

• Phase 0/A — done (LAN discovery and device identity: --discover, serial pinning, --label #11): --discover LAN sweep with /api/1/version fingerprint; serial pinned on first contact and verified before the first vitals sample of every run; mismatch raises Different charger at this address and suspends recording; --label shown in header, tab title, notifications.
• Phase 1/B — done (Multi-instance comfort: --peer header switcher, installer --name, VLAN note #12): --peer LABEL=URL header switcher; deploy/install-service.sh --name gives each charger its own unit, database and label; docs cover the cross-VLAN firewall prerequisite.
• Phase 2/C — parked. Native multi-device (devices table, device_id on every sample table, per-device pollers/calibrations, cross-device dashboard) is deliberately not built: process-per-device with the switcher covers the need, and every model stays per-install by construction. Reopen if power-sharing users ask for a single-process view.

Leaving this open as the tracker for Phase C.