SAFETY-136: a gentler loop on a slow meter until the last move shows

On a meter whose readings come 4 s or more apart, the loop runs at half its
gain after a move of 150 W or more, until the meter has fallen by half of the
move or 2 cycles have passed. With readings 10 s late on a 5 s meter the export
falls 44 % over oven, kettle and hob, owner shape, steps; 1-2 s meters are
untouched.

Co-Authored-By: Claude <noreply@anthropic.com>

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

@@ -71,7 +71,8 @@ The fits run all the time; the pull request has the counts.
 **What it costs.**
 - Found 36-68 s after a lag starts at 1-2 s meters; at a 5 s meter 30 s late
   is found within 100 s after it starts (88 s measured) (the loop first moves 100 W after 60 s,
-  SAFETY-129) with the export above -200 W, and 10 s late is not found. Until
+  SAFETY-129) with the export above -200 W, and 10 s late is not found (SAFETY-136 calms
+  the loop at a slow meter instead). Until
   then control is as before. In a quiet house the "readings late" row stays
   about 2 minutes longer after the lag ends (126 s against 32 s on base); no
   harm measured, and it clears as early as on base when the load changes.

goodwe_controller/DECISIONS/SAFETY-136-slow-meter-settle.md

@@ -0,0 +1,73 @@
+# SAFETY-136 - a slow meter gets a gentler loop until the last move shows
+
+**Status: for review.** Code: `app/settle.py`, a call in `Controller.cycle()`
+(`app/ctl_cycle.py`). Tests: `test_safety136.py`. No option, no text change.
+
+**Problem.** On a 5 s meter, Home Assistant readings 10-15 s late are not
+found (SAFETY-129): they look like a slow battery (R2-1), and a hold does not
+help (a perfect one cut the export of the oven by 7 %, SAFETY-129 review).
+With moving loads the loop answers the same stale error at each cycle and
+overshoots: an oven, a kettle and hob, the owner's day or a step export 3-10
+times what they do with no lag. The fix is a calmer loop, not a detector.
+
+**Decision.** After a move of 150 W or more, a loop on a slow meter runs at half
+its gain until the meter has fallen by half of that move, or for 2 cycles.
+Slow is judged from the readings that arrive: the usual gap
+between them, over the last 60 s and at least 5 readings, is over 3.75 s (the
+limit of SAFETY-128's fast meter fit). It counts arrivals, not changes of
+value: on the recorded day at 1-2 s the value-based test (`MeterFit.slow()`)
+called 24 % of the cycles slow, because the recorded house repeats a value
+for 5 s or more, and the commands then differed from base. So there is no
+option. At a 1-3 s meter it is false, the tuning is never touched and the
+commands are those of the tree before. A meter that Home Assistant passes on
+only when its value changes looks as slow as its changes are far apart, as it
+does to SAFETY-128's fits: a 1-2 s meter with a value that holds for 5 s or
+more is then treated as slow, and the loop is gentler for it (the cost below).
+With no lag the meter shows a move at the next reading, so the wait ends at
+once.
+
+**Candidates** (SAFETY-129 sim, real `cycle()`, 5 s meter, sum over oven,
+kettle and hob, owner shape over the oven and over the heat pump, step down,
+step up, flat; export Wh, lag 0 / 10 s / 15 s; base 64 / 340 / 363):
+
+| Candidate, only at a slow meter | 0 s | 10 s | 15 s | Import Wh, 0 / 10 / 15 s |
+|---|---|---|---|---|
+| gain 0.4 | 97 | 201 | 299 | 97 / 224 / 301 |
+| gain 0.3 | 128 | 185 | 322 | 132 / 232 / 293 |
+| step limit 500 W | 118 | 285 | 293 | 110 / 325 / 324 |
+| cut fast, raise slowly (0.6 / 0.3) | 55 | 140 | 226 | 140 / 332 / 345 |
+| ignore 1 cycle after a move | 93 | 216 | 325 | 90 / 240 / 291 |
+| ignore 2 cycles after a move, unless the meter showed half | 69 | 206 | 277 | 62 / 240 / 354 |
+| **half gain for 2 cycles after a move, unless the meter showed half** | **67** | **189** | **296** | **62 / 223 / 288** |
+
+A lower gain for good, a step limit and a fixed ignore all make a 5 s meter
+with no lag worse (export +30-110 Wh, quarter peak up to 150 W): that is the
+common case. Cutting fast and raising slowly moves export to import and peak.
+Waiting only while the last move has not shown costs nothing with no lag.
+Ignoring the meter (the 2-cycle line) was worse than half gain where the plant
+is slow, not the readings late: a 12 s dead time with one inverter went from
+250 to 841 Wh import and a quarter peak of 206 to 1 509 W, so the loop keeps
+following at half gain.
+
+**What it gives** (5 s meter; the pull request and the report have each
+scenario). Export summed over the seven houses: 10 s late 340 -> 189 Wh
+(-44 %, import 363 -> 223), 15 s late 363 -> 296 Wh (-19 %, import 281 ->
+288), together -31 %. At 15 s the oven and the owner's oven are not better
+(92 / 39 Wh against 91 / 37), the kettle and the steps are. No lag: export
+64.4 -> 66.5 Wh (kettle +2), import and peak the same.
+
+**What it costs.** The loop follows a real step more slowly: half gain for up
+to two cycles after each move of 150 W or more. Of the 136 sim runs (every
+SAFETY-129 review scenario and its 15 harm runs), 56 at 4-10 s meters differ
+from base. Together their export is 10 363 -> 9 559 Wh (-8 %) and import
+8 389 -> 7 835 Wh (-7 %). Only 5 export more than 1 Wh and 14 import more:
+export by at most 11.5 Wh (a 10 s battery lag, +10 %), import by at most
+17 Wh (a 12 s dead time, one inverter, +7 %), and the quarter average by at
+most 35 W, once 73 W (10 s meter, 10 s dead time, export -59 Wh). Slow
+batteries with a dead time of 8-10 s export 5-39 % less; a 12 s dead time is
+the same. `READINGS_LATE` holds are the same seconds in every run.
+
+**Does not change.** Meters of 1-2 s: the same commands in all 63 runs (34
+at 1 s, 29 at 2 s), and the recorded-day digests (see the report). The late
+verdict, the hold and the freeze tests. 15 s late is only partly helped, and
+30 s late is the hold's (SAFETY-129).