zap: read the Zap's data model v2 local API (pv → solar, W → W_ac, ...) #170

Problem

Zap firmware main (d9cefe5, srcfl/srcful-zap-x-firmware#294) serves its local API in data model v2 (srcful-data-models 2.3.0). drivers/lua/zap.lua still reads the 1.x names, so a Zap running that firmware gives FTW no readings:

• emit_meter reads raw.W. That field no longer exists, so the driver emits no meter. FTW loses its P1/HAN site meter.
• PV is no longer found: /api/devices lists the DER as solar, and /data/json keys it as solar, not pv.
• Battery W, SoC, energy, V and A all read nil.

No Zap release carries this yet; the latest release is v2.3.15, still 1.x. The firmware will not be released before NovaCore runs v2 on the target environment. This has to land before a v2 Zap release reaches FTW users.

What changed in the Zap local API

GET /api/devices: ders[].type is solar (was pv) and ev_charger_port (was v2x_charger). rated_power, installed_power and capacity are unchanged.

GET /api/devices/{sn}/data/json: the envelope keys are the v2 DER types, version is "v2", every field of the type is present, and an unread value is null. Names zap.lua reads today:

Signs are unchanged: + import/charge, − export/generation/discharge. The full field list for each type is in the data model REFERENCE, and the Zap's own copy is fw_controller/API.md on Zap main.

What zap.lua needs

1. Read the v2 names. Take pv → solar in both discovery and the data envelope.
2. Accept 1.x as well, because FTW users have Zaps on both firmware lines during the rollout. version == "v2" in /data/json tells them apart.
3. A null stays nil, never 0 (44 drivers emit numbers they never read (null, never 0) #169).
4. Bump the version, then move FTW's drivers/BUNDLED_SOURCE.json pin. The pin is c9de251 today.

Out of scope for the current data model rollout: tracked here so FTW does not fall behind.

🤖 Generated with Claude Code