feat(zap): opt-in read of PV and battery from Zap

[frahlg]

Summary

Zap is still the P1/HAN site meter by default. Sites that cannot talk to the inverter from FTW — closed SolarEdge Modbus, no SetApp, or Zap already owning the RS-485 bus — can turn on a read-only ingest of PV and/or battery under Settings → Devices.

That is the Discord case: Zap already had the PV reading, native Modbus did not. Dual-Modbus sites keep the 3.0 path because both flags default off.

The driver never writes. Chargers stay out.

Depends on srcfl/device-drivers#100 (zap 3.1.0). Bundled pin moves to 60021a0. That pin is current device-drivers main plus the Zap change, so the recovery snapshot also picks up nibe_local 1.1.3, foxess_h3_smart 0.9.5 and a small myuplink fix already on main. After #100 merges, move the pin to the merge commit if GitHub squashes.

Operator path

Settings → Devices → Zap:

• Read PV from devices on this Zap
• Read battery from devices on this Zap (telemetry only)

YAML equivalent: config.read_pv: true / config.read_battery: true.

Test plan

• go test ./internal/drivers -run 'Zap|zap|CatalogSourceful'
• go test ./internal/drivers ./cmd/ftw
• node --test web/setup.test.mjs
• make verify (pre-commit)
• Human look at Settings → Devices for a Zap entry (CODEOWNERS web rule)

---

Note

Medium Risk
Touches site telemetry aggregation (double-counting if both Zap and a native driver are enabled) but remains read-only with flags off by default. Bundled driver pin also advances other recovery snapshots.

Overview
Zap stays the P1/HAN site meter by default, but operators can now opt in to read-only PV and/or battery telemetry from devices Zap already talks to (config.read_pv / config.read_battery, also under Settings → Devices). Use this when a native driver cannot reach the inverter (closed Modbus, Zap-owned RS-485). Chargers are still never ingested, and the driver still never writes.

Catalog capabilities now include meter, pv, and battery so Combined can see those DERs; generic disable-PV/battery checkboxes are hidden for Zap so they do not fight the new opt-ins. Tests cover independent PV vs battery ingest, aggregation across inverters, and no synthetic meter on inverter-only sites. Bundled drivers pin moves to pick up Zap 3.1.0.

^{Reviewed by Cursor Bugbot for commit 5e7ac82. Bugbot is set up for automated code reviews on this repo. Configure here.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5e7ac82aaa

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Gate ingest switches on the active Zap capability

When an existing site still resolves drivers/zap.lua to a managed or local pre-3.1 driver, these filename-only controls remain visible even though that driver does not implement read_pv or read_battery. Saving either switch therefore succeeds but produces no telemetry, misleading the operator into believing ingest is enabled. The repository deliberately gives managed/local drivers precedence over the newly pinned bundled copy, so render these controls only when the active catalog entry/version declares the corresponding capability.

Useful? React with 👍 / 👎.

[cursor]

Approved. Cursor Bugbot completed successfully and reported no findings that need human review. No reviewers assigned.

  

_{Sent by Cursor Approval Agent: Pull Request Router and Approver}