[bug] esphome-dsmr: per-phase fuse data missing on ESPHome name-derived object_ids

[tommylindgren]

What happened?

The fuse row falls back to a PV-based amp estimate (~22 A) instead of real per-phase current when esphome-dsmr is the site meter on ESPHome DSMR firmware that exposes name-derived object_ids (e.g. current_phase_1, power_consumed_phase_1).

/api/status returns phase_amps: [] even though the ESPHome device serves current_phase_1..3 over HTTP. The driver only probed Sourceful-style ids (current_l1, power_consumed_l1, …) and got 404.

Steps to reproduce

1. Configure esphome-dsmr as site meter against ESPHome DSMR YAML with friendly entity names (current_phase_1, not current_l1).
2. Confirm http://<device>/sensor/current_phase_1 returns a value.
3. Open dashboard fuse row or curl /api/status.
4. Observe phase_amps: [] and a single aggregate fuse estimate from PV.

Expected behavior

phase_amps and phase_powers populated from the meter; fuse row shows L1/L2/L3 with real amperage and per-phase W.

Version

master (pre-fix)

Deployment

Local dev (make dev)

Hardware / drivers in use

SlimmeLezer+ (ESPHome DSMR 2022.10.1), drivers/esphome_dsmr.lua as is_site_meter.

Root cause

ESPHome object_id derived from entity name: vs Sourceful Zap explicit ids. Not SlimmeLezer-specific.

[frahlg]

The live SlimmeLezer+ result now has a canonical and signed release path.

Evidence:

• alias implementation and primary tests merged in fix: add ESPHome DSMR object ID aliases device-drivers#9
• FTW artifact host API regression merged in fix: emit one DSMR host API range device-drivers#10
• version 1.0.2 release metadata merged in fix: release ESPHome DSMR 1.0.2 device-drivers#11
• drivers-beta commit: 2939543a2041a29566e6cf27a4eb5e4c69924de8
• signed manifest SHA-256: dec2ea2e8ddf5c94635dd1f7fce99e9e2bb6ea7fa5ab5fda6602d962307a0190
• signed 1.0.2 asset SHA-256: c415e507f4371c859fbf60827cc0704c5e24ad122dca1a9e5e1f190d67e852d1
• beta catalog: 62 drivers; the only addition against the locked 61-driver stable catalog is esphome-dsmr@1.0.2
• FTW recovery and host tests: fix: sync ESPHome DSMR recovery snapshot #627, green on all required checks

The live evidence still covers name-derived phase IDs such as current_phase_N and power_consumed_phase_N. The canonical driver also retains explicit Sourceful aliases and delivered/returned totals. Drivers-stable remains locked to 78c61ce731b7420ac65e437b2529d4249c4773e9 until the v1.10 pilot passes.