House load remains unavailable when loadpoint retains a nonexistent EV driver name #1744

Summary

On FTW v0.152.1-beta.1 (new 0.x Docker deployment), House remains unavailable in the web UI, while Grid/Battery/PV readings are fresh. The local GET /api/status provides a precise root cause:

load_w: null
history_reason: missing:easee:ev
load_estimate:
  watts: null
  reason: missing:easee:ev
  method: reported_energy_balance_v3

The site's charger driver and loadpoint are bound under different names:

drivers:
  - name: easee_cloud
    lua: drivers/easee_cloud.lua
    disabled: false
loadpoints:
  - id: Laddbox
    driver_name: easee

An operator also tried removing the Easee device in Settings, but the missing-house symptom persisted. The exact edit/save sequence for that removal was not captured; the read-only configuration inspection above confirms the current broken binding.

Reproduction / verified observations

1. Configure an EV-capable driver named easee_cloud.
2. Keep a loadpoint bound to the old/nonexistent name easee (this was found in a live setup after device changes).
3. View Live Energy Balance / House and GET /api/status.
4. House displays —; both load_w and load_estimate.watts are null, with missing:easee:ev, even though live grid, battery, PV and charger aggregate readings are available.
5. Switching the site meter between Zap and Pixii did not change the symptom. It is not a meter-specific issue.

Sample status from this site (signed FTW power convention):

grid_w = -109.96
bat_w = -3874
load_w = null
history_reason = missing:easee:ev
load_estimate.reason = missing:easee:ev

An instantaneous residual with PV and EV at zero would be about 3.76 kW; that is not a qualified HomeUseEstimate, and the current fail-closed behavior is preferable to reporting unverified consumption as exact.

Likely code path

• go/cmd/ftw/forecast_measurements.go — forecastMeasurementTopology adds an expected DerEV flow using every loadpoints[].driver_name, without ensuring it resolves to an existing configured EV driver or known OCPP charge point.
• go/internal/telemetry/forecast.go — measurementLocked marks absent readings["easee:ev"] as missing:easee:ev.
• go/internal/api/api_history_quality.go — invalid household balance sets load_w = null; the same error is propagated into load_estimate.
• web/settings/tabs/loadpoints.js — the Chargers dropdown can show a nonexistent driver as a saved connection, but the persisted invalid relationship is apparently not conspicuous enough to correct during device removal/rename.

Expected behavior / requested fix

1. Prevent or clearly flag dangling loadpoint bindings when an EV driver is renamed, removed or disabled. At least warn in Settings → Chargers, ideally with an actionable relink to an available EV driver.
2. Do not silently leave a no-longer-resolvable loadpoints[].driver_name that invalidates House indefinitely. Preserve explicit fail-closed semantics for genuinely unknown EV power; do not substitute 0 W for a missing but physically connected charger without evidence.
3. On missing:<driver>:ev, surface which loadpoint expects that source, rather than only displaying — in House.
4. Add regression tests for remove/rename of a charger driver with a retained loadpoint, and verify expected household-balance quality and the Settings UX. Avoid assuming a renamed charger can safely continue to receive dispatch commands.

Status

Root cause evidenced; remediation not yet verified. The operator has been advised to rebind the Laddbox loadpoint from easee to easee_cloud in Settings → Chargers, then retest /api/status. Please treat the outcome of that proposed relink as unconfirmed.

Related but distinct: #1667 covers transient power-balance mismatches invalidating historical household totals. This report concerns a persistent, dangling EV source identifier invalidating current household-load availability.