draft(foxess_h3_smart): battery control via the remote-control block — hardware-validated, pending the control-tier pipeline (#70)

[Leitet]

Draft on purpose — do not merge. This is the control implementation behind the hardware findings posted on #70, made reviewable. It builds on the read-only driver in #69 (this branch includes those commits) and must not land before (a) #69 merges and (b) the #70 control-pipeline questions have answers — the signed channel builds write-inert read-only artifacts today, so this driver cannot ship through the existing release path at all. It currently runs as a local operator override on the 1K5 site, per Fredrik's own-driver-at-own-risk guidance.

What it does

driver_command("battery", power_w) drives the H3-Smart remote-control block: enable 46001=1, timeout 46002, i32 setpoint 46003/46004 (vendor discharge-positive; site charge-positive setpoint negated on the way out). Base work mode stays Self-use — remote control is an overlay, and Self-use is what the inverter reverts to on timeout.

Safety posture (all hardware-exercised)

• Vendor timeout 60 s, refreshed every 5 s poll — the inverter reverts itself within a minute if the driver dies. The 60 is load-bearing: the master samples the RC block slowly, and a 15 s session expires before it acts — writes land, read back correctly, and do nothing, with zero error surface. This trap cost half an evening; the comment in the driver preserves it.
• Driver-side 60 s command lease — a silent EMS releases remote control rather than refreshing a stale setpoint forever.
• Explicit release in driver_default_mode and driver_cleanup; the disable is only written if this driver enabled the session, so a FoxESS-app strategy period is never stomped (the app uses these same registers — operators must not run app schedule periods alongside).
• Charge into a full pack refused at the driver (SoC ≥ 99% guard) — the inverter ignores its own Max SoC under remote control.

Evidence

Closed-loop dispatch on a 1K5-HI-10-V1: FTW passive-arbitrage targets ≈ −630 W, battery tracking through the slew ramp (−184 → −465 W), grid import driven 413 → 150 W toward the zero target, SoC descending from 94%. Register state during operation read back as exactly this driver's writes (1 / 60-s window / live setpoint). Mock-harness suite in the session covered enable ordering, refresh, two's-complement setpoints both directions, lease expiry, idempotent release, and full-pack charge refusal — the harness tests are not in this diff and would come with the real control PR once the pipeline shape is known.

Known open items for the real PR: DRIVER/DRIVER_MANIFEST still say read_only in package metadata terms the channel can accept (this build flips the Lua flag only), no structured command results, no lease integration with FTW's control-v2 path (srcfl/ftw#738/#741), and version/manifest sync deliberately not run.

🤖 Generated with Claude Code

[Leitet]

Branch updated through v0.5.0 — the setpoint semantics turned out to be inverter AC active power, export-positive (proved on hardware when a naive discharge command curtailed PV in full sun; confirmed against nathanmarlor/foxess_modbus, whose charge path documents the import-displaces-PV behaviour). Discharge is now hardware-validated in daylight; charge ships behind four guards adapted from the reference (BMS-ceiling cap with 200 W margin, daylight split by string voltage, sign-crossing pause, release-on-uncomputable). Full story in the commits.

[Leitet]

CI status is now definitive: dco, drivers (full suite incl. control-claims), signed-channel, history, boundary all green. Manifest and package metadata are fully synced and declare the truth: control: true, modbus.write, a typed battery command, vendor_autonomous default via driver_default_mode, and the bounded lease the driver actually implements (5 s heartbeat / 60 s max / return-to-default — the schema's lease model matched our hardware-derived design 1:1 without modification).

The single remaining red is packages, failing at exactly one line: ftw-core: control requires driver_default_mode_v2. That's the answer to this issue-#70 question about pipeline readiness: the control-package schema is complete and validates, and the only missing link is the v2 command contract on the FTW side (srcfl/ftw#738/#741, unmerged). When v2 ships, porting this driver's two entrypoints is the last step to a fully signed control artifact.