feat(drivers): NIBE S-series local REST API driver + opt-in HTTP TLS cert pinning

[HuggeK]

Summary

Adds a read-only NIBE S-series heat-pump driver (drivers/nibe_local.lua) that reads the pump's on-prem Local REST API over the LAN — no cloud, no OAuth — plus opt-in TLS certificate pinning for the Lua HTTP host capability.

Driver

• Auto-detects the device serial, pulls the full ~980-point register map in one request, and emits every point into the long-format TS DB with exact per-point divisor scaling (the local API ships each point's unit + divisor, so no °C×10 heuristic like the cloud driver needs).
• Reuses the same hp_* headline metrics as the MyUplink cloud driver (hp_power_w, hp_hw_top_temp_c, hp_outdoor_temp_c, …) so the heating dashboard works with either source.
• Read-only (no writes); self-heals device detection; per-point type guards + per-size "not connected" sentinel filtering.
• Headline ids default to the S735 and are config-overridable per model; all other points still flow under auto-generated hp_<name> names.

Host: opt-in cert pinning

• capabilities.http.tls_pin_sha256 pins an HTTPS endpoint's leaf certificate by SHA-256, so a driver can reach a self-signed endpoint (the pump) by trusting exactly one certificate — a swapped cert (LAN MITM) is rejected at the handshake — instead of disabling verification.
• Strictly opt-in: drivers without a pin keep standard system-root verification (unchanged for every existing HTTP driver).

Verification

• ✅ Live end-to-end against a real NIBE S735 (serial detected; headline metrics + lifetime COP ≈ 2.55).
• ✅ Hermetic driver test (Basic auth, serial anchoring, exact scaling, sentinel filtering, no double-emit).
• ✅ Unit tests: pin accept / reject / no-pin / malformed + fingerprint normalization.
• ✅ go build ./..., go vet, gofmt clean.

Companion public-driver PR opened against srcfl/hugin-drivers.

Draft: opening for review; happy to adjust headline-id defaults / docs before merge.

🤖 Generated with Claude Code

[HuggeK]

Future work: optional writable mode — Solar PV / smart-energy control

The driver is read-only today (by design). When/if we add an opt-in writable path, the NIBE local API exposes a useful set of Solar PV control holding registers that would let 42w push live PV surplus into the pump (so it stores free solar as heat / hot water / pool instead of exporting):

Register	modbus	Purpose
Modbus TCP/IP Ext. (Solar PV)	2107	Enable — tells the pump an external Modbus source controls Solar PV. Must be on for the rest to take effect.
…Available power (Solar PV)	2109	The available PV power (kW) we feed in — what the pump may divert.
…Include own consumption (Solar PV)	2108	Flag controlling how Available power is interpreted (see below).
Offset heating / cooling / pool (Solar PV)	2668 / 2667 / 2669	How far the pump shifts each target to absorb the surplus.
PV panel affects heating / hot water (EME)	1069 / 1070	EME on/off toggles.

Include own consumption (Solar PV) (2108) — important semantics

• on → we send gross PV production, and the pump subtracts the household's own consumption itself to derive the surplus.
• off → we send the net surplus (already after household consumption) directly.

The flag must match how we computed the number we write, otherwise the wrong amount of surplus gets dumped into heating / hot water / pool.

Caveats for the writable path

• It's a control write — needs the explicit opt-in + safety story we deliberately avoided for the read-only driver.
• The external EME feed times out (~6 min) — Available power must be refreshed periodically or the pump reverts to its own sensors.
• Need a test rig — validating writes safely needs a NIBE test site / spare unit; writing setpoints to a live, in-use pump isn't something to iterate on. (Help wanted.)

[HuggeK]

🔗 Paired with #532 (dashboard UI)

This driver is the data source; the dashboard UI that renders its telemetry is #532. Best reviewed / merged together:

• feat(drivers): NIBE S-series local REST API driver + opt-in HTTP TLS cert pinning #530 (this PR) — the NIBE local-REST driver plus the backend it needs: host.emit_metric's optional title arg (so the UI can explain each of the ~960 signals), generic /api/series range parsing (for the card's 30-day chart + energy-per-period windows), and network-scan probing of port 8443 (so the pump is discoverable in Settings → Scan).
• fix(ui): theme-aware charts + heat-pump card auto re-discovery #532 — the heat-pump card (curated metrics, 30-day temp chart, energy-per-period), the "all signals" detail view (every register + a plain-language explanation), and the Devices-tab setup form for the local-REST driver (host / username / cert-pin).

Without #530 the card has no data; without #532 the telemetry has no UI.

[HuggeK]

Now out of draft (together with the UI PR #532 and the Hugin packaging PR srcfl/hugin-drivers#7). The opt-in writable follow-up — feeding live PV production into the pump's Solar PV registers (2107/2108/2109), later a power cap for the electric add-heat — is planned in #537.

[frahlg]

Reviewed driver boundary, TLS pinning, telemetry/storage behavior, configuration, and tests. Added maintainer fixes so configured pins fail closed and cannot downgrade to HTTP, the ~980-point map records changes plus bounded full snapshots instead of duplicate rows every minute, sanitized-name collisions are stable, and range parsing cannot overflow. Local verify-all and GitHub CI are green.