adminandClaude Opus 5
186a044a3a
Reviewed on the pull request and merged there. Retargeted from TEL-10 to release/1.0 after #92 merged, and NOT merged on the inherited green: retargeting alone left the old `skipped` conclusion attached to a6af332 and the combined status still read success, so the required context was satisfied by a workflow that had never run. Run 799 is a genuine pull_request execution on the merge into release/1.0 - all five steps, the add-on's own tests occupying 08:56:58 to 09:04:47 UTC.
THE CAP MOVING A SATURATION-FROZEN INTEGRATOR IS ACCEPTABLE, NOT MERELY DISCLOSED. The disclosed figures reproduce exactly against the committed capture - 79 160 frozen ticks, 1095 moved, 679 further out on the side they were already on, worst 2424 W - and the worked tick in the comment is present with exactly the numbers written down and is the worst of that subset. What decides it is where the integrator lands rather than which way it moves: on the shipped configuration integrator_max_w is unset, so target == i_w after the bounds and the cap holds |i_w - slewed| to one slew step on every slew-limited cycle, frozen ones included. Measured over the whole 256 251-tick recording the carried integrator never stands more than two slew steps from the command on the wire - 800 W against release/1.0's 9200 W. On the frozen path this replaces an integrator bounded only by integrator_max_w with one bounded at two steps, so the loop is less wound up on those ticks and not more. The same-cycle command cannot be affected at all, the cap moving i_w after slewed is decided.
THE ALTERNATIVE IS REFUSED FOR A MEASURED REASON. Gating the cap with `if frozen: _lead_cap = float("inf")` reproduces all four of section 5's corrected figures - export 34.71 kWh, wasted 3.49 kWh, worst quarter 3434 W, worst observed lead 4961 W. The gate does leave the bound with a hole large enough to make the card pointless.
NOTHING FALSE FOUND. Section 3a's lag table reproduces cell for cell, including the rows that say the peak improvement is absent at every lag at or below 5.0 s; the card does not claim a capacity-tariff benefit and says so in four places. Form A is committed nowhere, so it was rebuilt from section 3's prose alone and reproduces all seven figures - 34.43 / 110.62 / 2656 / 2.99 / 3934.59 / +2.73 / +991.53 - which makes section 3 a specification rather than a summary. The one-sided cap was swept against the two-sided band over 136 080 states on an independent grid: 0 differences, corroborating habit 22's retraction.
MUTATION EVIDENCE RE-DRIVEN, EVERY COUNT EXACT, on purged cp -a trees one file at a time: L2 zero bytes 4+3, L4 one red in test_telemetry with test_control GREEN as claimed, L5a zero bytes 5+5, L6 zero bytes 6+3.
SUITE RE-RUN BY THE REVIEWER on the merge rather than the branch tip: release/1.0 29/29, this merge 30/30, exit 0.
One non-blocking note left on the pull request: "worst case 2424 W" is scoped to the 679 further-out ticks, while the largest move over all 1095 is 4220 W. That case is benign - the cap pulling a stale positive integrator down to follow a charging command, magnitude falling - which is why it is a note and not a finding.
Merging is not deploying. The live install still runs release/1.0's control law and slew_w 400 applied by hand; this merge authorises no deploy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU
GoodWe RS485 Controller — Home Assistant add-on repository
Replaces a GoodWe battery inverter's vendor controller with a local one: holds net grid exchange at zero by emulating the inverter's smart meter over RS485, and runs the monthly battery maintenance cycle the vendor box was doing.
repository.yaml add-on repository metadata
goodwe_controller/ the add-on
config.yaml manifest + options schema (the per-site config form)
app/ the controller
control.py the control law — pure functions, no I/O
maintenance.py the monthly cycle state machine
hass.py Supervisor/Core API access
store.py persistent state in /data
mqtt.py optional status entities
web.py ingress UI — routes only, status and configuration
config_page.py the configuration page's markup, style and script
configui.py its field model, built from the Supervisor's own
schema + translations — owns no key, label or rule
selfconfig.py reading and writing this add-on's own options,
with the validate-first / compare-and-swap gate
main.py orchestration, heartbeat, failsafe behaviour
test_control.py runnable checks — no framework needed
test_maintenance.py runnable checks — walks a full cycle in fake time
DOCS.md the add-on's documentation tab
MUTATION.md how to run a mutation so the result means something
tools/mutation_run.sh the mutation harness - purges bytecode, then grades
tools/supervisor_selfapi_probe.py what the Supervisor really permits and
returns, run against its own release image
firmware/goodwe-master.yaml ESPHome config for the T-CAN485
estop/rs485_log.py optional RS485 e-stop / bus witness
docs/GoodWe-RS485-Field-Guide.pdf the guide techs carry (10pp, A4)
docs/build_guide.py its single source - rebuilds the HTML and PDF
FIELD-GUIDE.md how to edit and rebuild the guide
Picking this up after a break? Read HANDOVER.md first — current state,
what is known broken, and what to do next.
Install
Settings → Add-ons → Add-on store → ⋮ → Repositories → add
https://gittea.kammenstraatha.duckdns.org/admin/goodwe-addon
then install GoodWe RS485 Controller.
⚠️ The repository must be PUBLIC for this to work. Home Assistant clones it
anonymously; against a private repo the store shows nothing and gives no useful
error. If it must stay private, install locally instead: copy
goodwe_controller/ into the machine's /addons/ folder, then
ha store reload — it appears as a Local add-on.
⚠️ Bump version: in goodwe_controller/config.yaml for every change.
Supervisor keys the built image by that version, so without a bump it silently
reuses the old image and your fix appears not to work — on your bench and on
every client's machine.
Requires Home Assistant OS or Supervised. Add-ons cannot be installed on HA Container or Core.
Read this first
The inverter holds its last command forever. It has no meter-timeout of its own — a controller that dies mid-command leaves the battery running until a human intervenes. Measured on real hardware: 5 kW of discharge held for 113 seconds after a controller went silent.
Three layers exist because of that, and only the third covers the Home Assistant machine itself dying:
- ESP32 watchdog — no fresh setpoint for ~30 s → command 0 W, and keep commanding it.
- Wind-down before firmware updates — 0 W written before the update starts.
- RS485 e-stop (optional) — writes 0 W after 30 s of total bus silence.
Sites sold without the e-stop must have the acknowledgement in FIELD-GUIDE.md
§10 signed.
Development
The control law and the maintenance machine are pure Python with no Home Assistant imports, so they run anywhere:
cd goodwe_controller
python3 test_control.py
python3 test_maintenance.py
Both must pass before shipping any change. To prove a check bites - the way
almost every claim in this repository was established - mutate the module and
run tools/mutation_run.sh, which clears __pycache__ first. It is not
optional: a same-size edit reverted inside one second leaves CPython reusing the
old bytecode, and the run grades code that is not there. goodwe_controller/MUTATION.md
has the mechanism, the measurement, and what the flags do not do. They are not unit-test theatre —
each assertion corresponds to a rule whose absence produced an observed failure
on real hardware, and the comments in control.py say which.
Compatibility
Check the serial number, not the model name. Characters 6-8 of the serial are the platform tag:
| tag | platform | verdict |
|---|---|---|
ESU EMU ESA BPS BPU EMJ IJL |
105 — ES/EM/BP, AA55-era meter bus | supported |
SPB SPN |
745 — SBP G2 (GW…-SBP-20) |
no |
ESN ESC |
745 — ES G2 (GW…-ES-20) |
no |
ETU EHU BTU … |
205/745/753 — ET/EH/BT hybrids | no |
SDT DST MSU NSU … |
PV-only inverters — no battery to control | no |
A "-20" or "G2" suffix means a different platform with a different meter
protocol. The tags come from the goodwe library's PLATFORM_105_MODELS, which
is also what Home Assistant's own integration uses to pick a protocol.
- GoodWe ES / BP family inverters (AA55 / RS485 meter-bus generation)
- The protocol is reverse-engineered. There is no vendor contract, and a firmware change on GoodWe's side could break every installation at once. Say so when you sell it.