3 Commits

Include renames

Author	SHA1	Message	Date
glenn schrooyenandClaude Opus 5.5	23a3a3f5b5	UX-10: the last plain-language leftovers: log lines, two table rows, 'Why: Other', red at 0 s ... - test_messages.py part 6: every dynamic part of a WARNING+ line is classified as data or as a built text, and every built text is produced by the real code and checked. This is the gap the 2d scan had: it counted `%s` as one word, so reasons built by loop_clamp_note() and friends were never seen. - Quoted reasons rewritten to STYLE.md (red-alarm shape, codes kept): OUTPUT_CLAMP, METER_FROZEN, CIRCULATING_POWER, STALE_READING, the peak guard (codes now PEAK_GUARD*), the migration report, price feed, price history and gate reasons. Plurals via messages.times()/count(). - Top table: Price history "96 prices over 24 hours for 26 Sep", Tariff "one every 15 minutes or every hour", "not final yet" dropped. - Levels and noise: per-cycle shadow line DEBUG, shadow on/off INFO, aiohttp access log only at log level debug, settings warnings once per start, one plain line per Home Assistant outage (hass.Outage). - INFO jargon and error texts: no "§8.3", ISO times, "banked", "keys ARE", "NOT_OBSERVED", "did NOT land", "AND". - Display bugs: WHY_WINNER covers every winner and safety reason (main.why_key(), part 7 finds them in the code); the meter row is amber "waiting for the first reading" inside its limit after a start; the missing-reading age is counted when the page asks. - STYLE.md and DECISIONS/UX-08-short-notifications.md (UX-10 section). No change to safety behaviour, alarm levels, notification ids, triggers, cadence or the banner cascade. One row colour changes (meter at start), justified in DECISIONS. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 10:58:43 +02:00
adminandClaude Opus 5	5d7e275df4	SAFETY-39: slew_w is a ratio to the rail, and gain is what is still wrong ... `slew_w: 1000` was derived on 2026-08-22 against a clamp of 1500 W, where "capping how far the loop can jump ahead of the inverter" was true because the rail itself bounded the excursion. The live install went to max_w 5000 and the constant did not move, so the loop crosses its whole output range in 10 s against a plant NOTES.md §5.10 measured at ~18 s. Measured on the owner's system 2026-09-05 11:43-11:46: a 3.4 kW export drove the setpoint 380 -> 5000 W in five 2 s ticks, the battery to -5154 W past a 5000 VA rating, and the grid from 3.4 kW of EXPORT to 2.8 kW of IMPORT. Nothing was broken; the rail moved. REPRODUCED FIRST, and one half of it is not reproducible at all. On plantsim.Plant and on an independent in-repo model: the setpoint stepping a full 1000 W per tick to the rail (48 of 51 export steps), and the meter crossing from export into import. The -5154 W figure is NOT reproducible in either model, because both clamp the plant at its rating - so the card's AC "battery no longer exceeds max_w in simulation" is unfalsifiable and was rewritten rather than met. THE DELIVERABLE IS THE RELATIONSHIP. SLEW_RAIL_FRAC = LOOP_TICK_S / PLANT_SETTLE_S = 2 s / 18 s = 1/9 slew_w = 0 now means FOLLOW THE RAIL - SLEW_RAIL_FRAC * max_w - exactly as integrator_max_w = 0 already means follow max_w. It is the shipped default: 222 W at max_w 2000, 556 W at 5000, 1067 W at a ~9600 W two-inverter site. validate.py rule 10 refuses an explicit value faster than that, graded against sum(unit_caps(opts)) - the roster sum, i.e. Controller.site_max_w - so a second inverter moves the bound with no operator action. VERIFIED BY BREAKING IT: restoring slew_w 1000 at max_w 5000 is refused, and the refusal names the rail, the crossing time, the measurement and what to do. Equality, one watt of slack, the live interim 400 and slew_w 0 at every rating all still start. GAIN IS THE CONSTANT THAT IS STILL WRONG, and it is NOT changed here. Over 51 export steps the over-absorption is FLAT in slew (958 W at 1000, 1081 W at 250) and monotone in gain (987 W at 0.6, 876 at 0.3, 435 at 0.2): slew_w bounds the OUTPUT, while the integrator moves gain*error per cycle and reaches a 5000 W rail in under three ticks whatever the slew is. Two control-law constants moving in one release on a running house makes the next measurement uninterpretable. ⚠️ N=2: the site rail becomes sum(max_w) ~ 9600 W (inverter B FROM DATASHEET AND SERIAL, not measured, and sim/plantsim.py's INVERTER_B is A copied), and the enforced ratio produces 1067 W there automatically. But a growing rail LOOSENS this bound, and the >= 900 W symptom goes stale at N=2 the same way the constant did - both stated in the record rather than left to be discovered. Nothing reached the inverter. The live install still runs the interim slew_w 400 applied by hand on 2026-09-05, which rule 10 accepts unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-06 01:10:15 +02:00
adminandClaude Opus 5	7ef3d23245	SAFETY-31: measure circulating power, which nets to zero at the meter ... Inverter A charging at 3 kW while inverter B discharges at 3 kW nets ~0 W at P1. The site reads idle while both packs are cycled through two round-trip conversion losses continuously, for no benefit, and the wear is real. NOTHING EXISTING CAN SEE IT, AND THAT IS STRUCTURAL. Every guard in this add-on is a consumer of the NET figure at the grid connection: SAFETY-02's sign watchdog gates on abs(grid_w) > 300 and the gate never opens at a netted zero; the peak guard and the capacity tariff both bill grid exchange. Circulating power is precisely the component of per-inverter power that the sum destroys, so no threshold on any existing detector could reach it. WHAT ALLOC-01 ALREADY COVERED, AND IS NOT RE-IMPLEMENTED HERE. Its AC 7 shipped the sign-coherence gate (allocator.REFUSE_SIGN, graded by test_alloc.py part 6): an allocation whose shares carry two signs is REFUSED, both units named, no shares returned. That is the COMMAND half - the allocator can no longer command circulating power. This commit is the MEASUREMENT half: circulation the allocator NEVER COMMANDED. app/circulation.py the sensor and the trip main.py site_circulating_w, the evaluation, the claim, the alarm arbiter.py `circulation` classified SCOPE_SITE, with the argument store.py a flat, site-level durable latch mqtt.py sensor.goodwe_circulating_power config.yaml two options, two schema ranges, CFG-03 discipline THE SENSOR: sum(|Bi|) - |sum(Bi)|. Zero when the units pull the same way, 2*min(|Ba|,|Bb|) when they oppose. DERIVED FROM MEASURED PER-INVERTER POWER - Inverter.batt, register 0x0518 - and never from the allocation record. The cheap version would be simpler and worth nothing: ALLOC-01's gate already guarantees the record is sign-coherent, so a record-derived sensor reads zero BY CONSTRUCTION and can only confirm that the allocator agrees with itself, which is the third failure mode MUTATION.md names. What this catches is a unit ignoring or lagging its share, a stale share still being executed, a maintenance or SAFETY-25 pin holding one unit while the loop drives the other, or HW-01's power stage running its last instruction for 6 h 25 m with the comms dead and the allocation record impeccable throughout. batt became per-instance in DEV-02; before that this could not have been written. VERIFIED BY MAKING ONE UNIT IGNORE ITS SHARE, on the TEST-19 two-master rig: S = -2500 W shares a = -1250 W b = -1250 W <- record ok, ONE sign, sums MEASURED A = -1250 W B = +1000 W <- hardware sensor over the RECORD : 0 W sensor over MEASURED power : 2000 W -> trips at 190 s and the card's own scenario, A -3000 W against B +3000 W at zero house load: the meter reads +0 W, the sensor reads 6000 W, and the shipped SignWatchdog's predicate is FALSE on 30 of 30 cycles. WHAT "ACTED ON" MEANS - decided, and recorded in DECISIONS/. The trip files Claim.set("circulation", P_SAFETY, 0.0) on the SITE actuator: every inverter to 0 W, latched. HW-01 established that commanding a wedged inverter achieves nothing, so the remedy is not aimed at it. A circulating loop needs TWO participants and one of them is THIS CONTROLLER, faithfully driving the listening sibling into the one that stopped listening. Stopping (1) halves the loop, which needs no cooperation from the wedged unit, and (2) - the more important half - makes the residue VISIBLE at the meter instead of cancelled at it, where every ordinary guard can finally see it. What it cannot do is stop the wedged unit; the notification says so and names the isolator as the last actuator. SITE-scoped because the quantity is defined over the roster and is identically zero for any one unit - there is no fact of the matter about which of two opposing inverters is the offender, so filing it per-unit would invent an attribution and could park the only unit still listening. THE WINDOW IS FROM THE RIG, NOT A ROUND NUMBER (AC 3). 924 closed-loop runs in which NOTHING is faulty, over both families of legitimate opposition (7 reversals x 5 write staggers; 7 flap periods x 4 amplitudes), swept across the whole range the schema accepts for gain and slew_w. Worst CONTINUOUS legitimate opposition by threshold: 505.0 s at 100 W, 40.0 s at 250 W, 10.0 s at 300 W, 5.0 s at 400 W and above. The knee is 400 W and it is the schema floor - below it, ordinary operation holds the sensor over the line for minutes and no window inside the 900 s billing quarter could tell that from a fault. circulation_w 700 is 1.75x the knee, the headroom bought for inverter B's ramp and lag being PLACEHOLDERS until SPIKE-04 measures them. circulation_hold_s 75 clears three bounds: 15x the worst legitimate episode, 2.5x the firmware's own LINK_STALE_S veto, 12x inside the quarter. A momentary opposition while one unit slews through zero is LEGITIMATE - writes are serialised, so B's number lands up to a cycle after A's - and 0 of the 924 runs trip. THE ALARM SURVIVES AN HA RESTART (SAFETY-34). persistent_notification is in memory, which is exactly how the 2026-09-02 outage went unseen for 6 h 25 m with the detector correct throughout. The latch is persisted to /data as flat site-level keys and the notification is RE-RAISED on the first cycle after every start, through the same code path as a fresh trip - two paths would be two chances for the restart one to rot unnoticed. AT N=1 NOTHING CHANGES (AC 5). |B| - |B| is 0 for every reading including one nobody took, no claim is ever filed, the arbitration is byte-identical, and the status page says n/a rather than claiming to watch something that cannot happen. VERIFIED BY BREAKING IT (AC 4). 18 mutations, all RED on named checks, each on a freshly copied tree with no __pycache__ mounted :ro. M10 - the sensor rewritten to read self.allocation.shares - is the headline: it takes AC 2 red. Three mutations are +0 B, the risky delta, and are marked as such. One equivalent mutant (the max(0.0,...) guard) is ARGUED rather than claimed: searched over 700 000 rosters without a negative. One genuine SURVIVOR was found and closed - publish() turning an unknown into a published 0 W, the sensor's own None rule defeated one layer out. Full ledger in DECISIONS/. arbiter.CLAIM_SCOPE gains its ninth source, so test_peakguard.py's 10f and 10g tripwires and test_arbiter.py's scope table went red on the line the append was written. Updated deliberately, with the argument, as their own comments require. Full 19-file suite green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-04 01:56:23 +02:00