Control tier for foxess_h3_smart (1K5 / H3-Smart): proposal and mapped control surface

[Leitet]

Follow-up to #68 / #69 (read-only foxess_h3_smart). Opening this to take the control question to the team rather than assuming an answer.

Why

A live FTW site runs a 1K5-HI-10-V1 as its only DER. Telemetry works, but FTW's planner requires a controllable battery — the read-only driver keeps the control pool empty, so the planner is (correctly) skipped and the site runs on the inverter's internal logic. Every FoxESS H3-Smart-map site will sit in this state until a control tier exists.

What the register map offers

From the same source the read-only driver was built against (nathanmarlor/foxess_modbus, Inv.H3_SMART profile), all holding registers, mapped from source but not yet written to on hardware:

• 46607 / 46608 — max charge / max discharge current, 0.1 A steps
• 46609 / 46610 / 46611 — min SoC, max SoC, min SoC on-grid
• 46616–46617 — export power limit (W, i32 pair)
• 46501–46502 — import power limit (W, i32 pair)
• 49203 — work mode
• foxess_modbus additionally implements a "remote control" force-charge/discharge path with power setpoints; whether and how it applies to the H3-Smart map needs verification before it can be the dispatch lever

A useful v1 lever for FTW's driver_command("battery", power_w) is probably the narrowest one that works: the charge/discharge current window (with the SoC window as bounds), leaving work-mode writes and the remote-control path as later stages once HIL evidence exists.

What policy requires (as I read AGENTS.md / CONTRIBUTING.md)

• Control is a separate change, never bundled with telemetry review; community-tier review alone is insufficient.
• Safe default mode, bounded leases, structured results, HIL acceptance per target host.
• The signed public channel is read-only, so this ships as a signed control package (com.sourceful.driver.* with exact version + artifact SHA pinned in FTW's driver control block).

Questions for the team

1. Is FoxESS control wanted on the roadmap now, or parked until there are more H3-Smart-map sites?
2. What is the current state of the control-package pipeline — has any driver shipped through it yet, and is there a reference to follow?
3. Is the current-window lever an acceptable v1 dispatch mechanism, or is the remote-control path a hard requirement for planner-grade control?

Offer

A 1K5-HI-10-V1 on a live site (with its owner operating it) is available as the HIL rig — the same unit that validated the read-only driver's telemetry against V×A cross-checks and grid CT balance.

🤖 Drafted with Claude Code

[Leitet]

Hardware update from the 1K5-HI-10-V1: remote control works, and the register recipe is now confirmed on real hardware — with one trap that explains why naive attempts fail silently.

• The block is exactly foxess_modbus's H3_SMART remote-control spec: 46001 enable (value 1 works — no magic values needed), 46002 timeout seconds, 46003/46004 i32 setpoint, discharge-positive. Work mode can stay Self-use; 44000 legacy block is absent (reads time out).
• The trap: the manager (ESP32 front-end) and the master sample asynchronously. Writes land instantly and read back correctly, but the master acts on the remote-control state on a slow cycle — a 15 s timeout expired before the master ever looked, so the session was accepted, stored, verified by read-back… and did nothing, with zero error surface. With timeout = 60 s (refreshed every 5 s poll) the inverter executes setpoints and a closed control loop converges (grid-zero tracking observed live: targets ≈ −630 W, battery following, import driven 413 → 150 W).
• The FoxESS app's own scheduler Force Charge/Discharge uses these same registers (observed live: enable 1, timeout = period length 2520 s, setpoint 500) — so vendor-side scheduling and a local controller contend for one register block, last-writer-wins. A control driver should document that operators must disable app schedule periods.
• Safety posture that worked in practice: fallback work mode Self-use, vendor timeout 60 s as the inverter-side dead-man, plus a driver-side 60 s command lease so a silent EMS releases control rather than refreshing a stale setpoint; explicit release in driver_default_mode. Charge-into-full refused at driver level (the inverter ignores Max SoC under remote control, per foxess_modbus).

This is running as a local operator-risk build per Fredrik's guidance; happy to shape it into the signed control package when the pipeline questions above have answers.

🤖 From the HIL session on the offered rig.

[Leitet]

The implementation behind the recipe above is now reviewable as draft PR #71 — running live on the 1K5 site as a local override, explicitly not mergeable until the pipeline questions here have answers.