Repository navigation
Control tier for foxess_h3_smart (1K5 / H3-Smart): proposal and mapped control surface #70
Description
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 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 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 drivercontrolblock).
Questions for the team
- Is FoxESS control wanted on the roadmap now, or parked until there are more H3-Smart-map sites?
- What is the current state of the control-package pipeline — has any driver shipped through it yet, and is there a reference to follow?
- 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
Activity
Leitet commentedon Aug 3, 2026
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.
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).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).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 commentedon Aug 3, 2026
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.
wip(foxess_h3_smart): 0.2.0 local control build — hardware-validated …
chore(foxess_h3_smart): sync manifest and declare the package as control
Merge pull request #71 from srcfl/local-foxess-control-build