Promote drivers-stable so FTW 2.x and 3.x can get zap 3.1.3 #211

Why

A Zap that updates to firmware 7.x gives zap older than 3.1.2 no meter reading, so FTW loses its site meter. zap 3.1.3 fixes the meter, PV and battery (#208, #209, #170).

Native 0.x has the fix in v0.158.2-beta.1. FTW 2.x and 3.x get no new Core, and drivers-stable is still at 489c9373 from 2026-09-25, with zap 3.1.0. Owners on those lines can only switch to native 0.x or run a local driver override.

What to do

Promote the signed stable channel, as in step 5 of the release path in FTW's AGENTS.md:

gh workflow run ftw-drivers-release.yml -R srcfl/device-drivers --ref main -f channel=stable

It refuses if main has moved past drivers-beta. Both were at d1c6a2e3 when this was written. If main has moved, publish beta first with -f channel=beta.

This has not been run, because cutting a release is the owner's step.

Check first: can a 2.x or 3.x box take it?

Not tried. Both lines have the install API and stable discovery on by default, and the manifest allows hosts from 2.0.0. But v2.3.2 and v3.8.0-beta.1 bundle this driver with DRIVER.id = "sourceful-zap", and the channel now serves it as zap. If Core does not match the two, promoting does not help those boxes. Try it on one box, or tell owners to switch to native 0.x instead.

What else it publishes

A promotion moves the whole catalog: 38 drivers differ from stable, 6 of them new. Nothing installs by itself, but owners will see these as stable versions. That includes saj-emanager, added today in #210.

50-125k-svk 0.2.3 -> 0.2.4
50-125k-svk-ac-slew 0.2.4 -> 0.2.5
50-125k-svk-slew 0.1.12 -> 0.1.13
acuvim 0.4.2 -> 0.4.3
ambibox_v2x 1.1.0 -> 1.1.1
ctek 0.3.2 -> 0.3.3
ctek_hybrid 0.3.1 -> 0.3.2
ctek_v2 0.3.2 -> 0.3.3
deye-svk 0.2.1 -> 0.2.2
easee_cloud 1.3.3 -> 1.4.0
esphome_dsmr 1.0.3 -> 1.0.7
ferroamp_dc2_v2x 2.1.0 -> 2.1.1
ferroamp_modbus 2.1.2 -> 2.1.3
foxess_h3_smart 0.9.5 -> 0.9.6
fronius_smart_meter 2.1.2 -> 2.1.3
heishamon 0.5.0 -> 0.8.0
home_assistant_vehicle new -> 0.1.0
huawei 2.1.2 -> 2.1.3
konja-261-svk 0.3.1 -> 0.3.2
myuplink 1.2.2 -> 1.2.4
nibe_local 1.2.0 -> 1.2.1
pixii 2.1.4 -> 2.1.9
pixii_pv 0.3.1 -> 0.3.3
remne_p1ib new -> 0.1.0
saj-emanager new -> 0.1.1
sdm630 2.0.1 -> 2.0.2
solaredge_legacy 0.3.2 -> 0.3.3
solaredge_pv 1.2.1 -> 1.2.2
solis_string 1.1.2 -> 1.1.3
sungrow 1.5.8 -> 1.6.1
tesla_cloud new -> 0.2.0
tesla_vehicle 0.2.2 -> 0.2.6
tesla_wall_connector 0.1.0 -> 0.1.2
teslamate_vehicle new -> 0.2.0
vag_vehicle new -> 0.3.0
zap 3.1.0 -> 3.1.3
zaptec_cloud 0.1.0 -> 0.1.1
zuidwijk_p1 1.1.1 -> 1.1.2

What zap 3.1.3 has been tested on

Firmware 7.0.3, through the Lua host on FTW master, not a 2.x or 3.x host:

• Meter: a Zap-HAN with a real meter.
• PV and battery: a Zap-P1 with a simulated Solis, not a real inverter.