goodwe-addon/goodwe_controller/DECISIONS/SAFETY-128-late-readings.md

SAFETY-128 - a reading that does not answer the last command is not current

Status: FIXED on release/1.0 (after 0.20.0). Code: app/lateness.py, control.compute(hold=, hold_w=), peakguard.cap_floor(), Controller._readings_late(). Tests: test_safety128.py (tools/safety128_rig.py, TEST-23's plant).

Cause (SAFETY-127 report). Home Assistant can deliver readings late but still changing. Every gate judges arrival (SAFETY-01) or a value that stops changing (SAFETY-18, SAFETY-37), so a late reading passes all of them. The loop then corrects, each cycle, an error its last command has already fixed: a loop with a dead time far longer than its cycle, which swings and grows. The peak guard projects the quarter from the same late figures and pushes to the inverter limit in its last seconds (OPT-34 rig F-2).

Rule.

1. Find late readings. Delay fits, every 4 s over the last 40 s of new meter values, how long after a power request the meter shows it: the meter is the house less the batteries, so meter(t) + request(t - d) is flattest at the right d. Over DELAY_S the readings are late (late_seen). The fit counts only if the requests explain half the meter's swing; a late d only if it fits 30 % better than any fresh one and better than a slow battery answering at once (10 or 20 s lag, the SAFETY-85/94 rigs). A silent meter adds no values (SAFETY-99/125). A battery that gives nothing under its ask, or refuses, spoils the fit and is left out for 40 s. With no fit for 120 s (a steady site shows nothing) the verdict is dropped. Nothing below acts unless late_seen, so with readings on time control is unchanged.
2. Hold. While late_seen, a request more than ANSWER_W from the battery reading is pending until that reading comes within ANSWER_W of it, or half way. Meanwhile the loop may not lead the reading by more than ANSWER_W that way (compute(hold=, hold_w=); it may come back), and the peak guard's floor is capped at the request that stands (cap_floor()). The loop is not held while a battery gives nothing under its ask or refuses: SAFETY-52/94 need it to go on asking.
3. Late. Pending for LATE_S with no reading moving ANSWER_W towards it is the late verdict: control holds, then after stale_input_s goes to 0 W ("readings late"), as for a missing input. It ends when a reading starts towards the request.
4. Seen. While late_seen an amber row says "Home Assistant readings arrive about N seconds late, so control holds the batteries." (NL too), and "every inverter is at 0 W" past the hold. One WARNING (READINGS_LATE) and one action-log line per episode, and one when it ends.

Constants (app/lateness.py).

	Value	Why
ANSWER_W	100 W	control.PROBE_ANSWER_W: a reading this far towards the ask has answered it (SAFETY-52's probe).
DELAY_S	8 s	freshness.PLANT_SETTLE_S 6 s + one LOOP_TICK_S 2 s: a fresh meter shows a request within the plant's settle (SAFETY-75's 6 s dead time) and one meter tick. The fit reads 0 s at 1/2/5 s meters, 5-7 s with a 6 s dead time, 9 s at 10 s late.
LATE_S	23 s	2 x PLANT_SETTLE_S + PUBLISH_PERIOD_S 10 s + READ_PERIOD_S 1 s: SAFETY-75's 6 s dead time, the 6 s settle, one publish and one read, the slowest healthy battery answer.
FIT_S, FIT_EVERY_S	40 s, 4 s	Short enough to find 10 s and 30 s late within 50-60 s of the start (the swing has not grown yet); one 2 s cycle in two.
MAX_DELAY_S	90 s	F-2 measured 17-78 s.
FIT_SHARE, FIT_BETTER	0.5, 0.7	Below these a battery that stops following (a refusal at N=2) was read as 23 s late.
SLOW_TAUS_S	10 s, 20 s	The SAFETY-85/94 lagging battery: without this check 16 of 36 of its reversals read as 11-56 s late.
FIT_GONE_S	120 s	The verdict outlives the lag by at most FIT_S + this when the site goes steady.

What it costs.

• Late readings are found only after the requests have moved 100 W and the meter has shown it late: 48-68 s after the lag starts in the tests. Until then control is as before.
• The row can stay up to 160 s after the readings are on time again, while the site is steady.
• A battery that cannot follow while readings are late (at a limit, not reading 0 W) is held, then set to 0 W after 38 s, until it moves.
• The fit costs about 93 x 20 sums every 4 s.
• With readings late, a large step is followed in steps of the lag: the loop waits for each request to show before the next.

Left out. The round trip setpoint -> Home Assistant: the fitted delay gives the same figure from readings the add-on already has. The arbitrage charge's own sizing on late readings (charge_room_w()) is not capped here; the test shows it swinging while the peak guard holds (see the pull request).