fix(sunsynk,deye): make Freeze Export actually reach the inverter

[springfall2008]

The bug

Freeze Export was a silent no-op on both Sunsynk and DEYE. Predbat expresses it by turning the forced-export window off and calling adjust_charge_rate(0), because both SunsynkCloud and DeyeCloud declare has_timed_pause: False and that is the only lever execute.py has left. But charge_rate maps to the per-window battery_schedule_charge_power, which derive_control_state only reads inside an enabled charge window — and a freeze export has none. The zero was dropped and the component wrote a settings object byte-identical to plain Demand.

The freeze_export branch meant to catch this keyed on the export SoC entity reaching FREEZE_EXPORT_SOC, which Predbat never writes: discharge_target_soc is only written during a real force export, always as reserve_percent. So the branch was unreachable — and had it fired, it wrote the 99 sentinel as cap{n}, telling a Selling First inverter to drive the battery to 99%.

Net effect on a live system: Predbat says "Freeze exporting", the inverter sits in self-use, and surplus PV charges the battery instead of being exported.

The fix

A freeze export is Selling First, Sell on, slot rate 0, cap at the RESERVE. The original code had three of those four right; only the cap was wrong.

• a zero charge rate against a non-zero export rate derives the freeze (the signal Predbat actually sends)
• the cap is the reserve, not the sentinel
• the slot baseline is derived rather than assumed idle, so the fillers carry the freeze too — Predbat never says when a freeze ends, so a self-use filler would otherwise defeat it the moment the clock reached it

Evidence

Settled on live hardware (Sunsynk inverter 2405116013, 2026-08-20) rather than inferred. The decisive result is a controlled pair differing in one field:

mode	sell	rate	cap vs SoC	battery
Selling First	0	8000	3% below	drained to grid at 4283–4715 W
Selling First	1	0	5% below	held at 7, 1, 28, 1, 10 W

So the slot rate is the sell-rate cap, which is what makes a cap below the SoC safe, which is what lets the cap sit at the reserve so the battery keeps the room to cover the house.

Supporting runs:

• Zero-export-to-CT fills the battery from the surplus — a 99% battery still took 540 W of PV while the rest exported. So the mode has to change.
• A zero slot rate does not stop charging, so it cannot stand in for the mode swap: rate 0 written and read back, battery carried on at 554 W until it simply reached 100%.
• The production payload (m0 p0 c20 s1) was then written live with the cap at the real 20% reserve — 80% of headroom below it — and the battery held at −1/0/3/6/3 W while the export tracked PV minus load (5148 − 257 = 4891 W vs pac −4711 W).

Also resolves the VERIFY@SPIKE on the Sunsynk grid_power sign. No behaviour change — it is correct as it was, pac is negative when exporting so the negation stands — but it was an unverified DEYE-parity guess and is now pinned to a live sample and a regression test: pac −1939 W against a computed 2047 W surplus, with the day's counters at 0.0 kWh imported against 2.8 kWh exported. The comment warns off re-deciding it from a low-power sample, which points the opposite way and is pure noise.

DEYE

Identical bug in identical code, so the same three changes. Its grid sign needs nothing — already confirmed live by the counter cross-check (TotalGridPower +25 W with DailyGridFeedIn 0.00 kWh).

Marked VERIFY@SPIKE for DEYE specifically. The parity argument is stronger here than it was for the grid sign — a sign convention is a cloud presentation choice and so had to be measured per cloud, whereas slot-rate and work-mode behaviour is inverter firmware, and both clouds drive the same Deye registers. But it is still inherited rather than measured. If DEYE's rate is not the sell-rate cap, a freeze export would drain the battery to the reserve, so one live DEYE run watching battery power against the solar surplus should confirm it.

Not verified

• The discharge half. That the battery still covers the house under Selling First when the load exceeds the solar. Every run was midday sun against a ~250 W house, so the battery never needed to cover a shortfall. The cap at the reserve is what should allow it and nothing observed contradicts it, but it rests on reasoning — recorded as such in the docstring. An evening run settles it.

Also

Corrects a stale comment in both files: they asserted "Zero power IS the freeze — the battery neither charges nor discharges", and the charging half is now disproven. They record what is actually known, including that the effect on discharge to the house was never measured — which is why the _self_use_slot guard stays exactly as it was.

The test fixtures needed a sweep in both components: a disabled window in the real control entities still carries Predbat's rate, so fixtures that left the charge rate at zero were silently describing a freeze rather than the demand state they read as.

Testing

New regression tests for the freeze-export payload and the sentinel in both components, plus the Sunsynk grid-sign sample. Full --quick suite green, pre-commit clean.

🤖 Generated with Claude Code

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.