[davmoz]

Problem

A Zap that updates to firmware 7.x serves its local API in data model v2. zap 3.1.1 read only the old names (W, L1_V), so FTW got no power reading from the Zap and lost its site meter. An owner reported it after a Zap got the new firmware. Zaps are being updated now.

Change

• Moves the pin to srcfl/device-drivers@d662c3eb (fix(zap): read the meter DER under Zap's data model v2 local API device-drivers#208). main there was at the current pin before that merge, so only zap changes.
• Adds two tests with the payload a Zap-HAN on 7.0.3 sent: the meter reads, and a null power stays unknown.
• Adds a changeset.

Tested

• go test ./internal/drivers/ -run Zap and ./internal/fleetping/ pass. The new tests fail against 3.1.1.
• scripts/sync-bundled-drivers.sh --check and --behind pass.
• On real Zaps on 7.0.3, through FTW's Lua host, GET only:
  • Zap-HAN with a real meter, 3.1.1: no meter, site-meter payload unavailable. This reproduces the report.
  • Zap-HAN with a real meter, 3.1.2: meter reads, with phase V/A/W and energy totals.
  • Zap-P1 with a simulated Solis (a Modbus simulator on the LAN), 3.1.2: the Solis meter DER reads, export negative. The firmware and its payload are real; the inverter is not.
• 7.x signs phase current with its power. phaseCurrentsA and fuse_phase.go take the absolute value, so fuse handling is unchanged. The Home Assistant bridge publishes the value as it is, so phase_1_a is negative during export on 7.x.

Not run on a full FTW site, and not tested on a Zap on older firmware. For the old names, the unit tests cover that path.

Not covered

read_pv and read_battery on a Zap with firmware 7.x still read nothing. That follows in device-drivers and a new pin bump (srcfl/device-drivers#170).

🤖 Generated with Claude Code