Repository navigation
Control tier for foxess_h3_smart (1K5 / H3-Smart): proposal and mapped control surface #70
Description
Activity
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_SMARTremote-control spec:46001enable (value 1 works — no magic values needed),46002timeout seconds,46003/46004i32 setpoint, discharge-positive. Work mode can stay Self-use;44000legacy 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.
- The block is exactly foxess_modbus's
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_SMARTprofile), all holding registers, mapped from source but not yet written to on hardware:46607/46608— max charge / max discharge current, 0.1 A steps46609/46610/46611— min SoC, max SoC, min SoC on-grid46616–46617— export power limit (W, i32 pair)46501–46502— import power limit (W, i32 pair)49203— work modeA 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)
com.sourceful.driver.*with exact version + artifact SHA pinned in FTW's drivercontrolblock).Questions for the team
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