55 Commits

Include renames

Author	SHA1	Message	Date
glenn schrooyenandClaude Opus 5	ab6fbe2f9e	SAFETY-25: record the owner's decision - option a, with alloc-01 as the revisit trigger ... The product owner answered SAFETY-25's §1 on 2026-09-02: OPTION A. The BMS cut-out is the DELIBERATE and only backstop for demand-driven discharge on the grid-following loop, and Option B - a loop-side reserve floor - is DEFERRED rather than rejected. Option A is the shipped behaviour, so this is a recording, not a change. `app/` is touched in exactly two places and both are comments that claimed the question was still open (freeze.py's finding, peakguard.py's point 2). No setpoint, no claim, no option, no default moved. The 17-suite run is green on the same numbers as before. WHY DEFERRING IS THE SAFE DIRECTION. Option B's proof - bms_soc_floor < loop_soc_floor <= peak_soc_floor, run through the real arbiter in test_peakguard.py part 10d - has an unstated premise: the reserve predicate and discharge_permitted() read the SAME state of charge. With two packs they read different numbers. The reserve binds on the emptier pack and files hi = 0; the peak guard, reading the other pack or an average, files lo = excess > 0; lo > hi is arbiter clause 3 and the answer is 0 W - the battery parked in the billed quarter, which is the failure the memo itself marks fatal. And no config validator can catch it: it is a runtime divergence between two readings, not a config ordering, so CFG-01's shape of check passes on the exact tree that parks the battery. Option A's cost is energy; Option B's cost built too early is the one quarter of the month that sets the bill. THE REVISIT TRIGGER IS ALLOC-01, recorded in §0c. Under ARCH-01's host-side allocator the two claims stop sharing a list: the loop floor becomes a per-inverter `hi` consumed as an INTERVAL at stage A, while the peak floor stays a site `lo` at stage B. Different claim lists, different stages, structurally unable to cross - a stronger argument than the ordering rule, because it makes the crossing unreachable rather than harmless. That is the shape in which Option B becomes safe to build. WHAT HAS TO BE RE-EARNED AT N=2 is stated plainly in §0d rather than left for someone to discover. SAFETY-27 now names five floors across two packs, so "the SoC" stops being a scalar the config can bound. And part 10f - the pin that made SAFETY-25 mergeable - CANNOT EXPRESS TWO PACKS: its dynamic half is a scalar 0-100 % SoC sweep against a single-series capture, and a two-pack exposure lives in the DIFFERENCE between two readings, which that sweep visits at no resolution. Its static half, the AST scan pinning the eight claim sources, still bites at N=2; the dynamic half goes silent. Merging a two-pack reserve on 10f's current green would be merging on a check that cannot see the failure. The options analysis is kept intact on purpose - §1-§7 stand exactly as written, including §5's "(recommended)" on Option B and §6's recommendation, with a new §0 saying what was decided and §6 marked as answered. A memo that recorded the verdict and deleted the reasoning is the failure this DECISIONS/ directory exists to prevent. Part 10e's check moved with the memo: it used to pin the honest "Status: OPEN" line and now pins that the memo names the option, the date and the trigger AND still carries both options and the recommendation. The tripwire itself stays - a ninth claim source in Controller.cycle() still takes 10f red on the line it is written, and "deferred" is precisely the state in which someone builds Option B by accident. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-02 00:46:54 +02:00
glenn schrooyenandClaude Opus 5	acbdf41248	TEST-13: grade record_block()'s policy argument, and the two import spellings SAFETY-20's check could not see ... Two survivors from TARIFF-01's review, closed in test_tariff.py only. app/ is untouched and no shipped behaviour changes. Two further items on the card were already closed in shipped code and are struck rather than re-implemented. ITEM 1 - the per-phase reduction's PLUMBING was unobservable. Mutating PeakStore.record_block()'s `billed_w(block, policy)` to `billed_w(block, POLICY_NET)` (+4 B) leaves all 17 suites green. Measured three times now: by TARIFF-01's reviewer, re-run through TEST-15's purge harness this session, and re-run again here on a clean uncontended tree. The product code is correct - tariff.py:363 really is `def record_block(self, block, policy: str = POLICY_NET)` and it really does forward the argument. What was missing is any check that could tell that apart from a hardcoded call, and the reason is the third instance of one shape: A STIMULUS EVALUATED WHERE THE QUANTITY IT GRADES IS DEGENERATE, after WITNESS-02's span normalisation and TARIFF-01's own DST window. billed_w() short-circuits to block.offtake_avg_w whenever per_phase_offtake_avg_w is absent. Every block reaching a store anywhere in the suite was single-phase or built as _CB(..., None) - so NET, SUM and MAX collapsed onto one number and the argument could not be observed at the call site. Section 7 grades the FUNCTION on an unbalanced fixture and says nothing about its CALLER. So section 7's own (3000, 500, -200) W block - whose three reductions are 3300 / 3500 / 3000 W, asserted distinct three lines above - is now round-tripped THROUGH the store under each policy and read back from both tables (peak() and recompute_month(), so both writes in that single transaction are graded). record_block() with no policy is checked to bank the NET figure. An anti-degeneracy pin is stated over the three BANKED numbers, not over vals, because it is the banked ones this triple is made of. Direction, which is why this is worth plumbing-testing: NET is the SMALLEST of the three here, because the exporting phase nets off. A store that quietly billed NET while asked for MAX would UNDER-record the month's peak, and an under-recorded peak is maximum headroom for SAFETY-07 - the same under-guarding direction as the getattr(..., 0.0) default SAFETY-07 already removed from project(). ITEM 2 - the SAFETY-20 import grader claimed more than it checked. It collected `m.module for m in walk(tree) if isinstance(m, ImportFrom)` and matched a literal list of six spellings. That is blind to two of Python's three import forms: * `from . import arbiter as _ab` is an ImportFrom whose .module is None - the dots are in .level and the module name is in .names - so it collected "" and matched nothing; * `import app.arbiter` is an ast.Import node the walk filtered out entirely. Both were added to app/tariff.py and the shipped suite stayed GREEN, with the _names half not firing either (an alias import creates no Name node). Low severity: any USE of either alias still produces an Attribute the _names half catches. But the printed sentence "it imports nothing from arbiter, clamp or control" was false for two forms out of three, and a check that overclaims is worse than one that claims less, because the next reader stops looking. _imported_modules() now walks Import as well as ImportFrom and joins `from . import X` onto its base. _forbidden_imports() matches per dotted SEGMENT, not by substring: `app.arbiter` must not hide behind a package prefix, and `clamps` / `arbiters` / `controller` must not be falsely flagged - `controller` is not hypothetical, this package is goodwe_controller. Five evasion spellings and eight innocent ones grade the grader itself, and both the name half and the import half are shown non-vacuous against main.py, which carries all three import forms and really does import all three modules. ITEMS 3 AND 4 - ALREADY CLOSED. STRUCK, NOT RE-IMPLEMENTED. Item 3: app/tariff.py:266-267 is `def is_observed(self): return self.state == OBSERVED`, already false for NO_RECORD. Nothing to do. Item 4: app/tariff.py:672-680 reads `held = max(averager.held_net_w, 0.0)` with NO getattr default, and carries a comment naming TEST-13 item 4. Fixed by SAFETY-07 in 616b62d; held_net_w is a documented public property on QuarterAverager (p1.py:290), so a rename raises AttributeError on the first cycle instead of crediting 0 W held. A projection crediting 0 W held reads LOW, which is the under-guarding direction for SAFETY-07's floor. Restoring a default would re-open a money guard. And the recorded NON-finding stays a non-finding: removing clear_partial() is still green and that is a PASS. quarter_start is the PRIMARY KEY and the upsert carries `ON CONFLICT ... WHERE excluded.offtake_avg_w > quarter_blocks.offtake_avg_w`, so a replay is a structural no-op. That demonstrates TARIFF-01's "double counting is answered structurally, not by care" claim rather than contradicting it. EVIDENCE - all through tools/mutation_run.sh (recursive __pycache__ purge, python3 -B, tree re-read from disk, mutated line grepped off disk, byte delta recorded), in the goodwe-addon-ci image against a :ro mount. baseline, 17 suites, before any edit ............................ 17 PASS baseline, 17 suites, final tree ................................. 17 PASS A1 billed_w(block, policy) -> billed_w(block, POLICY_NET) +4 B 5 RED the 'sum' and 'max' round-trips, both tiers, and the distinctness pin A2 billed_w(block, policy) -> billed_w(block, POLICY_MAX) +4 B 6 RED the 'net' and 'sum' round-trips, both tiers, the default, and the pin B1 add `from . import arbiter as _ab` to app/tariff.py +29 B 1 RED the import sentence. SHIPPED suite on the same tree: GREEN - the hole. B2 add `import app.arbiter` to app/tariff.py +19 B 1 RED the import sentence. SHIPPED suite on the same tree: GREEN - the hole. B3 add `from .control import compute` (the form the OLD grader DID catch, as a regression control) 1 RED C1 delete the ast.Import branch from _imported_modules() 1 RED names the two spellings it MISSED, so the grader-grader is live C2 segment match -> substring match (`any(f in m for f in ...)`) 1 RED names clamps / arbiters / controller as falsely flagged CONTROL, and the point of the whole ticket: A1 graded by the SHIPPED test_tariff.py is green, and A1 graded by all 17 SHIPPED suites on a clean uncontended run is 17 PASS, rc=0. The survivor is real and it is now closed. ONE THING THE REVIEWER SHOULD KNOW. During the first (contended - two docker containers at once) run of that 17-suite survivor sweep, test_peakguard.py reported FAIL once. It has passed 8 times since on the identical tree, including three concurrent runs and one clean uncontended full sweep, and its tail was lost to a grep so I cannot say which check it was. I believe it is a timing-sensitive check under CPU contention and NOT related to this change - this commit touches no product code and no peakguard fixture - but I could not reproduce it, so I am recording it rather than asserting it away. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 08:40:09 +02:00
glenn schrooyen	6ea84a46f6	Merge remote-tracking branch 'origin/release/1.0' into TEST-16 ... # Conflicts: # goodwe_controller/CHANGELOG.md	2026-09-01 07:54:52 +02:00
glenn schrooyenandClaude Opus 5	20f9f4969d	TEST-16: pin the two one-sided arbitrage rungs, and un-mask them from each other ... SAFETY-26's AC4 gave the same tolerance mutation to every price and quantity boundary in arbitrage.py and static_tariff.py. Everything in arbitrage.py went red - `price < 0`, `soc <= floor_pct`, `soc >= ceiling_pct` are each red under +/-5. Two survived, both in static_tariff.py, and this card closes them. D `spread == 0.0` (:912) weakened to `spread <= 0.001` SURVIVED at +2 B. F `len(firm) < 2` (:901) weakened to `len(firm) < 1` SURVIVED at +0 B - the delta MUTATION.md names as the risky one. THE DEFECT IS NOT EITHER ROW, IT IS THE INTERACTION. D and F MASK EACH OTHER. A single firm hour also has a spread of 0.0, so with F weakened the flat rung refuses the stimulus anyway; with D weakened the small-but-real spread is still refused, only for a lie. Each rung's failure is absorbed by the other, so BOTH can be weakened together and a suite grading `kind == "refused"` reports nothing. That is structurally invisible to single-mutation testing, which is how this pair came through four rounds of review on TARIFF-03 and FCST-03 - and it is the arrangement in which the next edit to either rung opens a real hole with nothing to report it. D is not cosmetic either. With the tolerance in place a series priced 0.20000 / 0.20050 - a REAL 0.0005 EUR/kWh spread - flips ALLOWED to REFUSED at min_spread_eur_kwh=0.0, a value arbitrage()'s own docstring documents ("pass 0.0 to mean any positive spread, explicitly") and its validator at :861 accepts on purpose. At a shipped threshold the outcome does not move, but the operator reads the false sentence "the tariff is flat - every one of the 2 firm hours costs 0.2000 EUR/kWh" about a tariff that is not flat. WHAT WAS ADDED. test_static_tariff.py section 9, and the shape of it is the argument: * THE REASON IS GRADED, NOT THE VERDICT. The masked case refuses CORRECTLY while reporting the wrong sentence, so a check asserting only "refused" passes on a broken tree. A `rung9()` helper names which refusal answered, from the sentence the operator would read; an unrecognised refusal reports itself as UNATTRIBUTED rather than quietly matching nothing. * EACH RUNG IS GIVEN A STIMULUS THE OTHER CANNOT ABSORB, or the pinning is circular. The flat rung gets a THREE-firm-hour flat series, which no `len(firm) < N` a person would write can reach. The firm-pair rung gets a ONE-FIRM-HOUR series, which the flat rung CAN reach - so its attribution is the whole check, and that is why it is written as a rung name rather than a verdict. * AC1 is a sweep of small-but-real spreads (0.0005 down to 0.000001) all ALLOWED at min_spread_eur_kwh=0.0, with the exactly flat series on the other side still refused BY THE FLAT RUNG - without that mirror the sweep would also pass for a rung deleted outright. 1e-6 is the floor because the shipped line rounds the spread to 6 decimals; that quantisation is graded in the open as its own row rather than left unstated. * AC3 is a five-row table graded on rung attribution, which denies the masking from both sides at once. * The firm-pair count is also pinned from ABOVE (`< 3`) and BELOW (`< 0`), which the criteria do not ask for but which is what stops this section being one-sided in exactly the way it was written to fix. EVIDENCE. Eight rounds through TEST-15's tools/mutation_run.sh, used UNCHANGED: recursive __pycache__ purge before each run, python3 -B, the tree re-copied FROM DISK between rounds, the mutated line grepped out of the file before the run, byte delta printed, test_static_tariff.py and test_arbitrage.py graded each time. Baseline green. baseline, shipped +0 B PASS D1 `spread == 0.0` -> `<= 0.001` +2 B RED, 3 checks D2 `spread == 0.0` -> `<= 0.000001` +5 B RED, AC1 alone D3 `spread == 0.0` -> `< 0.0` (rung gone) +0 B RED (section 2 as well) F1 `len(firm) < 2` -> `< 1` +0 B RED, 3 checks F2 `len(firm) < 2` -> `< 3` +0 B RED, 6 checks F3 `len(firm) < 2` -> `< 0` (rung gone) +0 B RED (ValueError) D1+F1 BOTH AT ONCE - THE TICKET +2 B RED, 5 checks Four of the seven are +0 B, the delta MUTATION.md names as the one stale bytecode can hide. All are REDS, the direction that defect cannot fabricate - but they were run under the purge anyway, because "it went red so the cache cannot have lied" is a conclusion and not a procedure. NO SHIPPED BEHAVIOUR CHANGED. app/ is untouched; both rungs were correct all along, and the card is explicit that a rung found actually wrong is a stop-and- report rather than an edit. Also updated: MUTATION.md gains a short section on masking as a SECOND way a survivor lies, with the two rules that fall out of it (grade the reason, and mutate suspected pairs together); and test_arbitrage.py's SAFETY-26 AC4 note is marked closed rather than left reading as an open finding. UNSURE ABOUT. The 5e-7 row asserts the shipped `round(spread, 6)` quantisation. That is a real property of the line and worth stating, but it does pin a rounding the ticket never named - if a reviewer would rather that stayed unpinned, it is one check to drop and nothing else depends on it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 07:37:19 +02:00
Claude	b68f288fef	TEST-11: pin the clamp guard to the write it reads ... check_output_clamp() sits one line below `await self.write_setpoint(self.target)` in cycle(), and moving it above the write left test_clamp.py, test_freeze.py and test_loop.py ALL GREEN. Measured on the move itself before this commit; measured again after, where test_clamp.py part 6 goes red and the other two are still green - the gap was real and it was only ever in this file. WHAT IS ACTUALLY LOST. The guard has two evidence sources. `self.loop_clamped` is set from the Decision well above the write and survives the move, and on the 10.3 runaway replay it is the source of every engagement the alarm reports (0 write-path engagements against 2 loop-side ones) - which is exactly what makes the move nearly invisible. `self.clamp_last` is assigned by write_setpoint() and by nothing else, is None until it has run, and is what `engaged_write` reads at main.py:856. Moved above the write, that consumer goes quietly false and a DEVICE-bound clamp - max_w above the inverter's own rating, SAFETY-20's install - is reported by nothing. A guard whose second evidence source can be silently disconnected is one refactor from being half a guard. WHAT THE CHECK PINS, AND WHAT IT DELIBERATELY DOES NOT. Not the position: the comment at that line warns against tidying SAFETY-03's ordering and SAFETY-18's into one rule, and a check a rename breaks is worse than none. It pins the CONSEQUENCE - what `self.clamp_last` held each time the guard consulted the watchdog - using a spy subclassed from the shipped ClampWatchdog over a slew-limited ramp where every cycle's command is a different number, so "this cycle's evidence" and "last cycle's" are distinguishable at all. The spy hooks `clamp_wd.note()`, the consumer, rather than the guard's name: that is what keeps a rename legitimate. The same assertions are re-run through a controller whose guard is renamed and whose write lives in a helper, and were verified against main.py itself - renaming the method throughout AND moving both calls into a new `_emit_and_guard()` helper keeps part 6 green; swapping the two calls turns it red on a line that names clamp_last. WHY AC 3 NEEDED A NEW STIMULUS, AND WHY IT IS NOT DRIVEN THROUGH cycle(). Through the real cycle() the write-path half cannot engage: the arbiter files the device range and max_w as P_SAFETY LIMIT claims, so resolution.target_w is already inside both bounds before write_setpoint() re-applies them. That duplication is deliberate defence in depth; part 6 now MEASURES the zero engagements rather than leaving it as a claim in a comment, and then drives the write path directly at max_w 5000 against a +-2500 W device - the wire carries 2500 W, every loop-side flag stays clean, and the alarm fires on clamp_last alone. With the two calls swapped the same stimulus clamps the same value and the alarm is silent, which is the ticket in one pair of runs. main.py gains one comment sentence naming the check, mirroring the one SAFETY-18's block already carries for test_freeze.py part 5. No behaviour changes. Full suite: 17/17 green in goodwe-addon-ci. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 07:31:26 +02:00
glenn schrooyenandClaude Opus 5	d0b053b150	TEST-10: pin max_w beside the meter_freeze_s key TEST-06 already pinned ... max_w and the LIVE_MAX_W literal beside it were the two survivors left after TEST-06 pinned meter_freeze_s: changing max_w 2000 -> 4500 in config.yaml passed every check in test_freeze.py and test_tariff.py GREEN, and LIVE_MAX_W = 5000.0 was a bare literal that silently disagreed with the shipped max_w (2000) with nothing in the file saying so. For contrast, deadband_w 15 -> 5 already went RED 2 + 1, so the pinning technique was known to work - it just was not applied to the key either side of it. Three changes, each measured: 1. test_freeze.py gains a check comparing Tuning()'s code default (control.py, 2000.0) against SHIPPED_MAX_W, read from config.yaml by extending the file's existing _cfg_default() regex reader rather than reimplementing test_arbitrage.py's _shipped. Broken and confirmed red: max_w: 2000 -> 4500 in config.yaml now fails exactly "the code default and the shipped default agree on max_w too" and nothing else in either file; reverting returns both files to all-green. (AC 1, AC 4) 2. LIVE_MAX_W is renamed LIVE_INSTALL_MAX_W in both test_freeze.py and test_tariff.py, each with a comment stating plainly that 5000 is the live install's own override, not config.yaml's shipped max_w (2000) - the defect was a literal that could be misread as the shipped default, not the number itself. (AC 2) 3. test_freeze.py states PINNED_KEYS = ("meter_freeze_s", "deadband_w", "max_w") in one place as the complete set of config keys this suite pins. Deliberately excludes maintenance_* - CFG-03 (merged into release/1.0 since this branch started, merged in here) gave those keys a separate single source of truth in app/maintenance.py and this ticket has no reason to duplicate that pin. Not every key in config.yaml is pinned here on purpose: meter_freeze_s, deadband_w and max_w are the three this file's mutual-exclusion arithmetic (section 2b) actually reasons about together. (AC 3) Full 17-file suite run green under goodwe-addon-ci after the merge with release/1.0 (f630ed9, CFG-03). CHANGELOG.md updated under Unreleased. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 06:48:05 +02:00
glenn schrooyenandClaude Opus 5	d5b1ef19b3	CFG-03: give maintenance option defaults one source of truth ... Option defaults for the maintenance cycle were declared in three places that could disagree, and MAINT-04 proved they already did. config.yaml shipped `maintenance_charge_w: 2000`; main.py carried TWO `opts.get(..., 2500)` fallbacks; MaintConfig's dataclass carried a third `2500.0`. So an options dict with the key ABSENT was ACCEPTED by validate.py's rule 6 - which read 2000 - and then built by main.py at 2500, against a 2000 W ceiling: options dict with maintenance_charge_w ABSENT, max_w=2000 validate_startup_config -> [] (accepted, no problems) MaintConfig().charge_w -> 2500.0 arbiter.resolve() -> 0.0 W, contradiction=True That is the bug rule 6 exists to refuse, passing rule 6. It is unreachable on a Supervisor install, which always supplies every key from config.yaml, and fully reachable from sim/inject.py and from the test suite - which is where anyone debugging maintenance actually works. MAINT-04 shipped a TRIPWIRE and said so: test_validate.py pinned all three literals and asserted the consequence through the real arbiter, so the divergence could not silently widen or be half-closed. Its PASSING CONDITION WAS THE BUG. Both it and validate.py's comment said to delete each other when the divergence was closed. It is closed, so both are deleted. THE DIVERGENCE WAS WIDER THAN ONE KEY. `maintenance_discharge_w` had the identical three-way split (config.yaml 2000, MaintConfig 2500) and the card named only the charge side. Closing one and leaving its twin would have satisfied the numbers and left three sources of truth one line down, which is the state that produced the bug. Both are closed, and so is the whole family: all eight `maintenance_*` keys go through the same mechanism. WHAT THE SINGLE SOURCE IS. config.yaml's `options:` block - it is what the Supervisor reads and what the operator edits, so it wins by definition. There is now exactly one in-code copy, `maintenance.MAINT_OPTION_DEFAULTS`, which is TARIFF-02's `PRICE_OPTION_DEFAULTS` and SAFETY-24's `PEAK_OPTION_DEFAULTS` pattern applied to the family that named the card - validate.py's rule 8 comment already called that "CFG-03 read as a rule rather than as a complaint", so this makes the rule hold where it was first broken rather than inventing a fourth mechanism for one option family. A MIRROR RATHER THAN A RUNTIME READ, and the reason is mechanical: the Dockerfile copies `app/` and `run.sh` into the image and NOT config.yaml. The running add-on cannot open the file it is configured by, so there is nothing to read at 03:00 on a client's Pi, and a YAML-subset parser that could fail at import is a new way for the add-on not to start. What makes the copy safe is that test_maintenance.py pins every entry by READING the shipped file - drift is a CI failure, not a comment. EVERY OTHER SITE NOW DERIVES FROM IT OR HAS CEASED TO EXIST: * MaintConfig's eight dataclass defaults are indexed out of the mirror. No numeric literal survives in the class that held the third opinion. * `MaintConfig.from_options()` is the ONLY place in the add-on that reads a `maintenance_*` option. main.py's eight inline `opts.get(key, <literal>)` calls are gone: moving the read next to the mirror means the fallback cannot be anything but the mirror, because there is no literal in sight of it to disagree with. It uses `key in opts` rather than truthiness, so a shipped `false` or `0` is honoured instead of being quietly replaced by the default - this card's own bug in a different costume. * main.py's SECOND fallback site - the cheap-window charge floor at the P_MAINT_SHAPE claim - reads `self.maint.cfg.charge_w` instead of re-opening the options dict with its own literal. The Controller had already parsed this once in __init__; asking the object that owns it cannot drift from it, and the rate the shaping asks for can no longer be a different number from the rate the state machine drains at on the same install. * validate.py's rule 6 and its `maintenance_discharge_w` warning take their fallbacks from the mirror. WHERE THE RANGE LIVES, STATED AND CHECKED. config.yaml's `schema:` block carries `maintenance_charge_w: int(500,5000)` - a fourth declaration site of a different kind. It is a BOUND, not a default, so it is not this bug; but leaving the question open is how a fifth site arrives. The decision recorded in config.yaml and in maintenance.py is: bounds live in the schema block ONLY, because the Supervisor is what enforces them and the Supervisor reads only that file, so a Python copy of `int(500,5000)` would be a place to disagree and nothing else. test_maintenance.py checks both halves of that: every mirrored key must have a schema entry - without one the Supervisor drops the option and the add-on silently runs on the mirror instead of the operator's value - and every shipped default must lie INSIDE its own range, since a default the schema rejects is a config that cannot be re-entered once it is edited. What the schema grammar cannot express is a relation BETWEEN keys (`maintenance_charge_w` against `max_w`), which is exactly why rule 6 is written in Python and why it does not belong in the mirror either. THE REPLACEMENT CHECKS, AND HOW THEY WERE VERIFIED. test_validate.py's new section exercises the same four consumers the defect ran through, the same way: the validator ACCEPTS a dict with every maintenance key missing; a REAL Controller built from that same dict holds 2000 W (through main.py, not through a regex over its source); `MaintConfig()` answers 2000 W with no dict at all; and the real arbiter emits `-2000 W, limited by supervised(max_w)` instead of `0 W, contradiction=True`. test_maintenance.py pins the mirror to config.yaml in both directions - equal values, and full coverage of every `maintenance_*` key the file ships, so a ninth key cannot arrive unmirrored - and asserts the consumers move as a RELATION rather than against numbers, reading MaintConfig's defaults back out of `dataclasses.fields()`. Each new check was verified by BREAKING the thing it watches and observing red, this project's rule: 1. config.yaml -> 1500, mirror left at 2000: test_maintenance 1 FAILED, test_validate 4 FAILED. 2. config.yaml AND the mirror -> 1500: green again, and every consumer moved together - MaintConfig() 1500 W, the Controller 1500 W, and the arbiter `-1500 W, limited by maintenance(cheap-window charge)` where it had said `-2000 W, limited by supervised(max_w)`. That is AC4: change the single source and watch the consumers follow. 3. `charge_w: float = 2500.0` retyped into the dataclass: 2 FAILED in each of the two files. 4. `opts.get("maintenance_charge_w", 2500)` restored in main.py: 1 FAILED, naming the file and the literal it found. 5. `maintenance_hold_min` deleted from config.yaml's options block: 3 FAILED. Full suite 17/17 in goodwe-addon-ci, twice, once under parallel load. Stale prose that asserted the now-closed divergence as current is corrected in app/watchdog.py, test_watchdog.py and test_peakguard.py - watchdog.py's example still uses 1500 W, but because the point of the example is a charge strictly inside the ceiling, not because 2500 is what ships. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 06:16:54 +02:00
glenn schrooyenandClaude Opus 5	e498dd4c1c	SAFETY-25: pin the claim-source set, so the tripwire is one ... The durability claim this PR shipped was FALSE, and the reviewer of #31 disproved it by building the fix. Part 10 said, in four committed places, that it "goes RED the day a loop-side floor is built, so the exposure cannot change size under a green suite". The reviewer implemented the memo's own recommended Option B in main.py - a `Claim.limit("reserve", P_LOOP, hi=0.0)` filed under a `loop_soc_floor` - and the ENTIRE SUITE STAYED GREEN. Part 10 green. Mutation 13 went on printing "NOTHING PREVENTS IT, ON PURPOSE" and the same 21 % -> 10.0 %, on a tree where something DID prevent it. Pushed to an absurd always-binding 95 % reserve it was caught only by SAFETY-24's pre-existing part 7 wiring checks; part 10 was still green. THE CAUSE IS STRUCTURAL, not a missing assertion. `replay_loop()` hand-builds main.py's claim list as a literal `[supervised, loop, peakguard.claim(...)]`, so it is blind to any claim main.py ADDS - which is exactly where AC 2 would be built. That is this repository's named failure mode: a check that observed something other than what it claimed to observe, shipped as a guarantee inside the document that recommends the change. THE FIX IS 10f: THE CLAIM-SOURCE SET, PINNED, two ways because the two fail differently. * STATICALLY, over `Controller.cycle()`'s own AST. Every `claims.append(...)` in it must be one the scan can read - an unreadable append FAILS rather than counting as nothing, which is how a scan like this goes quietly vacuous - and the sources it can file must be exactly {device, supervised, failsafe, safety, peak, arbitrage, maintenance, loop}. A ninth takes part 10 red on the line it is written, in every configuration, whether or not any fixture here reaches the state that files it. * DYNAMICALLY, through REAL `Controller.cycle()`s with main.py's OWN `resolve` spied - not a list this file built and hoped matched - swept over the WHOLE 0..100 % SoC range in the two states 10a-10c replay. Idle: exactly {device, supervised, loop}. Floor-limited: exactly {device, supervised, loop, peak}. A claim conditioned on a low pack, which is the shape a loop-side floor has, cannot hide from a sweep that visits 0 %. And the fold is checked rather than assumed: main.py's two P_SAFETY rating limits are both symmetric LIMITs, so replay_loop() modelling them as one `supervised` claim at the tighter bound is exact. MEASURED AGAINST THE COUNTEREXAMPLE. Reproduced first on the unfixed tree (green, as reported). On this tree the reviewer's Option B at its recommended default takes part 10 RED on 3 checks, and the 95 % variant on 6. Nine mutations were run in all, each against a freshly copied tree with no `__pycache__` present, mounted `:ro`; all nine red, no survivors, no `+0 B` delta. MUTATION.md records why a second round was needed: the first round's mutations were all aimed at DISARMING the guard, while the claim part 10 actually made was about the guard being FIXED. The four false sentences are replaced with what is now true, and each says WHICH half catches WHICH shape - 10f for an arbiter claim (Options B and C), 10a-10c for a clamp inside control.compute() or the guard (Option D), which the replay drives directly. AC 2 IS STILL OPEN AND NOTHING HERE BUILDS IT. The loop-side floor was a test mutant, reverted before commit. The memo still says "Status: OPEN. This is a memo, not a decision." Also, non-blocking, from the same review: the NOT READY banner had inherited the new scope sentence and become a ~550-character paragraph that the row three lines below repeated verbatim. A checks() row may now carry an optional short `banner` form; the floor-limited row does, and `status_payload()` prefers it. THE ROW IS UNCHANGED - shortening that would have been weakening AC 3 - and rows without the key are unaffected. Graded, and mutated: dropping the short form goes red. Merged origin/release/1.0 first (CI-02), keeping both tickets' CHANGELOG entries. Full suite green: 17/17 in goodwe-addon-ci (test_ci_gate.py needs `git`, which CI-02 added to .gitea/ci/Dockerfile but the local image lacks; run with it installed and it passes). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 05:04:22 +02:00
glenn schrooyen	3cb9d3b7d9	Merge origin/release/1.0 into SAFETY-25 ... CI-02 landed on release/1.0 after this branch was opened and both tickets add a block under `## Unreleased`, so CHANGELOG.md collided. Both entries are kept, newest-first: SAFETY-25's, then CI-02's, then SAFETY-20's. Nothing else conflicted.	2026-09-01 04:38:46 +02:00
adminandClaude Opus 5	182102eeaf	SAFETY-25: say what peak_soc_floor bounds, and measure what it does not ... peak_soc_floor reads like a pack-wide reserve and is not one. The grid-following loop has no SoC guard of any kind, so on a sustained-load evening it discharges straight past that number and keeps going until the pack's own BMS cut-out stops it. The gap has now been written down four times without being filed - SAFETY-18's finding (freeze.py:18), SAFETY-24's module note, its PR body, and its honestly-uncaught 13th mutation - and never once measured. It is measured here, on the committed 2026-08-20 capture, driving the SHIPPED control.compute(), peakguard.decide(), peakguard.claim() and the real arbiter.resolve() in main.py's order: 19:00-22:00 UTC, 830 W mean, minimum 701 W, zero export in the window reference pack (300 Ah x 51.2 V x DoD 90) started at 21 %, one point above peak_soc_floor ends at 10.0 % - the bms_soc_floor cut-out 1525 Wh delivered by the LOOP over 587 cycles 549 cycles below peak_soc_floor, 343 of them still discharging 0 cycles on which the peak guard filed any floor at all AND IT IS A BEHAVIOUR, NOT A CONFIG VALUE. The same evening ends at 9.9715 % at peak_soc_floor = 5, 11, 20 and 60 - the shipped value and both ends of the schema range - identical to four decimal places. The option an operator would reach for cannot move the number by any amount at all. On the same day's high-load block the two states coexist: 49 cycles reporting PEAK GUARD FLOOR-LIMITED and, on all 49 of them, the arbiter simultaneously granting the loop up to 2000 W of discharge. WHY SAFETY-24 COULD NOT CLOSE IT. The peak guard files a `lo` limit - a LOWER bound on the setpoint. That asymmetry is exactly what makes it trustworthy: a reviewer proved across 19,800 combinations that it can never lower a target, cap a discharge or contradict the arbiter. The same property makes it structurally incapable of stopping a discharge the loop itself wants. A floor on the guard cannot become a floor on the pack by being raised, and the sweep above is that sentence measured. WHAT THIS COMMIT CHANGES IS THE HONESTY, on the four surfaces an operator actually reads. That half is required whichever way the open question is answered, and it is the real misstatement on the live system today: * config.yaml, beside the option itself - it BOUNDS THE PEAK GUARD ONLY and is NOT A PACK-WIDE RESERVE, with the replayed evening and the sweep; * DOCS.md, in the options table and in a new section carrying the figures; * the STATUS-PAGE ROW for a floor-limited guard. This is the one line a human reads at the moment the guard stops discharging, and read alone it says "the battery is being held at peak_soc_floor" - which the replay shows is false in every cycle that row is rendered; * the PERSISTENT NOTIFICATION, which outlives the page. It now names what has stopped (the guard buying a lower bill) and what has not (the pack being spent). peakguard.py and freeze.py carry the measurement beside the findings they already recorded, so the next reader does not have to take the caveat on trust. THE PRODUCT DECISION IS NOT TAKEN HERE, and must not be. Whether the loop gets a reserve floor of its own decides whether this house's battery may discharge to the BMS floor on a heavy evening; that moves real energy and it is the owner's call. DECISIONS/SAFETY-25-loop-soc-floor.md is the memo AC 1 asks for: the options, what each costs, what each protects, weighed against MAINT-01 (a pack repeatedly at the BMS floor is the SoC-drift condition the maintenance cycle exists to correct, and an over-tight reserve fights it from the other side) and against the fact that this would be the FIFTH SoC key - OPT-04's arbitrage_soc_floor fired SAFETY-24's "revisit if a third floor appears" trigger unremarked, so SAFETY-27's naming decision should land first. It carries a recommendation and says plainly that it is not a decision. It also records a trap found while writing it, and now CHECKED through the real arbiter rather than described: the obvious shape of a loop-side floor is a `hi` limit at P_LOOP, and filed while the peak guard is asking for a positive floor that is `lo > hi` - which arbiter.py resolves to a CONTRADICTION at 0 W, the battery PARKED in the one quarter of the month that sets the bill. It is the same crossing-limits hazard shaping_suspended() already exists to avoid. The ordering `bms_soc_floor < loop_soc_floor <= peak_soc_floor` removes it provably, because wherever the reserve binds the guard is already floor-limited and files lo = 0; both halves are run in part 10d. test_peakguard.py part 10 is a TRIPWIRE, not a guarantee. It records a defect and goes RED the day somebody builds a loop-side floor, so the exposure cannot change size under a green suite and closing it has to be deliberate. Part 11's mutation 13 stays honestly NOT CAUGHT - nothing prevents the loop discharging past this floor - but it now reports a number instead of a sentence. Verified: 16/16 suites green in the CI image. Eight mutations, each against a tree copied fresh with __pycache__ excluded and mounted :ro, so no .pyc existed to go stale (MUTATION.md's structural immunity, the same one it records for CI); byte deltas +61, -8, -465, -430, -1088, -46, file deleted, and -95; none is +0 B. All eight go red on the named check: M1 peakguard.claim() also files hi=floor_w -> 7 red, incl. 10c M2 control.compute() gain forced to 0 -> 6 red, incl. 10a/10b M3 scope sentence removed from the status row -> 10e red M4 scope sentence removed from the notification -> 10e red M5 scope paragraph removed from config.yaml -> 10e red M6 scope bullet weakened in DOCS.md -> 10e red M7 the decision memo deleted -> 10e red M8 arbiter clamps crossing limits instead of reporting a contradiction -> 5 red, incl. 10d AC 2 is left explicitly OPEN, pending the owner's answer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 03:46:43 +02:00
adminandClaude Opus 5	1e4bad8aa7	CI-02: grade the merge, and stop a cancelled run reading as a test failure ... Two things a green from `checks / unit (pull_request)` was claiming without having observed. Both were measured on a deliberately conflicted throwaway pull request (#29, now closed and its branch deleted) rather than read off the workflow, because the Actions log endpoints 404 on this Gitea and a step's own conclusion is the only channel out of a job. CASE 1, AND THE TICKET'S MECHANISM IS WRONG IN A WAY THAT MAKES IT WORSE. The card says a conflicted pull request loses its merge ref, so that git fetch -q --depth 1 origin "$GITHUB_REF" \ || git fetch -q --depth 1 origin "$GITHUB_SHA" falls through to the second half and quietly grades the bare branch head. The symptom is real - PR #14 reported success while `mergeable: false` - but that is not how. Asking one question per step on the conflicted probe (runs 558, 559): GITHUB_REF == refs/pull/<n>/head P01 passed GITHUB_REF != refs/pull/<n>/merge P02 failed GITHUB_SHA == the pull request head sha P03 passed fetching GITHUB_REF succeeds P04 passed <- even conflicted ...and it lands on the bare head P05 passed refs/pull/<n>/merge does not exist P06 failed `git ls-remote origin 'refs/pull/*'` on this server advertises only `/head`, for open and closed pull requests alike. There are no merge refs here at all. The first fetch has therefore always succeeded and the fallback has never fired once; both halves name the same commit anyway. So the gate did not lose merged content on conflicted pull requests - it has never had merged content, on any pull request in this repository's history. Green has meant "this branch passed on its own", and with `block_on_outdated_branch` off on release/1.0 the base has usually moved underneath it. Reproduced end to end on one pull request, same conflict, gate swapped: run 567 the ORIGINAL gate -> success, "Successful in 3m38s" run 566 the gate below -> failure in 2s, merge step red, both test steps `skipped` The checkout now fetches the base tip and the pull request head, merges them, and refuses if the merge does not apply - as its own NAMED step, because /actions/runs/<id>/jobs carries a per-step conclusion and that is what lets a reader tell "nothing was tested" from "the tests spoke". `--depth 1` is gone: a merge needs a merge base, and a full fetch of this repository measured 6.8 MB and 1.1 s. The fallback survives only on the workflow_dispatch path, which has no pull request to merge and now announces which bare ref it took. CASE 2, AND `cancel-in-progress` IS NOT THE KNOB. Runs 531 and 533 on PR #14 were cancelled at 0s, each at the exact second the next run on that pull request was created: 531 created 17:08:19 `Waiting to run`, cancelled 17:10:44 = 532's creation 533 created 17:45:11 `Waiting to run`, cancelled 18:11:22 = 534's creation Both have `started_at` at the Unix epoch. A cancelled run posts `failure` on the required context, described `Canceled after 0s`; branch protection compares state, not description, so "nothing ran" and "your tests are broken" arrive as the same red wanting opposite responses. Three settings were measured, each with one run holding the single runner slot and two further pushes behind it: no concurrency block at all runs 561 and 562 both queued, both executed group, cancel-in-progress:false run 564 sat `Blocked by required conditions` and was cancelled at 0s the second 565 existed A shared group cancels a run that has not started regardless of that flag - GitHub documents it and Gitea 1.27 implements it. Having no group is the only configuration measured to leave a queued run alive, so the block is gone and the measurement is written above it. The cost is stated in the file: a developer who pushes four times occupies the shared runner four times. That is CI-01's own trade written the other way round - a delayed verdict, never a destroyed one - and a destroyed verdict is worse here because it is indistinguishable from a real failure. A sha-keyed group was considered and rejected: the only cancellations it still permits are same-sha ones, whose red lands on a commit that IS still the head. WHAT IS NOT ESTABLISHED, SAID PLAINLY. Nothing here makes a cancelled run distinguishable at the gate BY STATE; that is Gitea posting the status, not this workflow, and no edit to this file can change it. What ships removes the cause instead of relabelling the symptom. And a commit that never had a run carries an empty `/statuses/<sha>` list, while a queued one carries `pending / Waiting to run` within seconds and a concurrency-held one `pending / Blocked by required conditions` - those were already distinguishable at the API. `/actions/tasks`, which is what was polled when this was first reported, lists only tasks that started and cannot answer the question at all. test_ci_gate.py grades the gate by RUNNING it. It extracts the checkout and merge steps out of checks.yml and executes the shipped commands against two throwaway local repositories it builds - one whose pull request merges, one whose does not - and pins that the old one-liner exits 0 on the unmergeable one while the new steps refuse and say nothing was tested. Part 1 pins the two tokens that assemble `checks / unit (pull_request)`: renaming `name:` or the `unit:` job key would leave every open and future pull request waiting forever on a context that never arrives, with no error anywhere in that sequence, and admin override blocked. Seven mutations of checks.yml were each confirmed red, including both renames and a restored `--depth 1`. .gitea/ci/Dockerfile gains `git` for it; the fixtures are local paths and no network is touched. 17/17 green in the checks image. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 03:42:54 +02:00
glenn schrooyen	29fa39eda7	Merge origin/release/1.0 into SAFETY-20 ... # Conflicts: # goodwe_controller/CHANGELOG.md	2026-09-01 02:43:08 +02:00
adminandClaude Opus 5	83911ed637	SAFETY-20: measure the freeze rail against the reachable ceiling, not max_w ... SAFETY-18's conjunction needs `abs(commanded_w) >= 0.95 * max_w`, but the emitted command is clipped to the setpoint device's own [dev_min, dev_max] range as well as to max_w - in clamp_to_rating()'s second stage and again as the arbiter's `device` P_SAFETY limit claim. Measured on the shipped predicate at the ticket's numbers, max_w 5000 on a +-4700 W inverter: looks_frozen(unchanged_s=3600, commanded_w=4700, max_w=5000) -> False The command is pinned at the hardware's rail, the meter has been frozen for an hour, and term 2 is unsatisfiable by construction because 4700 < 4750. Any device rating at or below 0.95 * max_w disarms the conjunction outright, and the status page then printed `armed (... command is over 4750 W)` - a guard that cannot fire, advertising that it can, which is the failure SAFETY-15, SAFETY-19 and validate.py rule 5 all exist to prevent. The rail is now measured against min(max_w, |dev_min|, |dev_max|), through a new `rail_ceiling_w()` threaded into looks_frozen(), FreezeWatchdog.evaluate() and both call sites in main.py. An unread rating leaves the old behaviour exactly, and correctly: hass.limits() returns None whenever ESPHome is not up, and on that path no device clamp is applied either, so max_w really is the ceiling. A rating larger than max_w cannot raise the rail - this is a min(), not a swap. THE DELIBERATE CHOICE, since SAFETY-03 has landed. The arithmetic was kept rather than substituting Decision.i_clamped / Decision.clamped. i_clamped is the integrator bound (control.py:208, `bounded != i_w`), not "the command is at the device rating", and `clamped` is the max_w output bound, unreachable on a default install - neither is the device rail. More decisively, both answer "did the LOOP ask for more than a bound", while the rail term asks "is the command standing at the ceiling", and those coincide only when the loop is the claimer that won. A maintenance SET or a peak-guard floor reaches the ceiling through arbiter LIMIT claims with no clamp engaging at all, so a boolean rail would go False exactly during a maintenance phase running against a frozen meter - which freeze.py's own docstring names as the same fault with a worse actuator behind it. The predicate is also public with two call sites that pass DIFFERENT command values (self.target, and `standing` = last_write); a per-cycle boolean cannot be passed per call site, so substituting it would have silently decided the pre-clamp-versus-wire question that PM recorded as still open. AC 1 governs, and it is satisfied literally. The smaller of the two device bounds, not a per-sign pair. A per-sign rail is tighter and is not wrong, but it is two rails needing two coverage verdicts on a status row that carries one number, and the only configuration that distinguishes them is refused at startup anyway. The symmetric ceiling can only lower the rail, which widens term 2 rather than disarming it; term 1 carries the whole no-false-positive argument and is untouched. A ceiling of 0 W is NOT COVERED, not "armed at 0 W". A device that can command nothing in one direction would make `abs(command) >= 0` true of every command including a parked one - term 2 degenerately TRUE, collapsing the conjunction into the bare unchanged_s > N threshold TEL-05 refused for false-tripping at this controller's own operating point. rail_unreachable() returns the reason, looks_frozen() stays silent, and the page uses the NOT COVERED row the unsupported-transport case already has - a second reason to use that surface, not a new mechanism. AC 4, decided rather than assumed: NO NEW validate.py RULE. The configuration is max_w above the device rating, which rule 2 (CFG-01) already refuses on the identical predicate, re-run by run_control() once the real rating is known: validate_startup_config({... max_w: 5000}, -4700, 4700) -> ['max_w is 5000 W but number.sp accepts at most 4700 W - THE DEVICE WINS ...'] A rail-specific rule would fire on a strict subset of that (0.95 * max_w > dev_max implies max_w > dev_max) and could never be the rule that stopped a start. The residue is the state where hass.limits() answered (None, None) - ESPHome not up at boot, range checks skipped rather than guessed at, rating never re-read - and there is nothing to refuse there by construction, which is why the answer is a runtime row. Recorded in validate.py's "deliberately not refused" list and pinned by four checks in test_validate.py, so the decision's premise goes red if rule 2 is ever softened back to a warning. HOW REACHABLE THIS IS, stated rather than glossed. Because rule 2 refuses the configuration whenever the rating is known, min(max_w, dev_max) IS max_w on every install that reaches the control loop with a rating it could read, and this change is arithmetically dead there. That is clamp.py's argument for its own second stage word for word: the case where it bites is the case where the startup gate did not run or no longer holds, and a guard that quietly assumes the gate ran is a guard that reports armed in exactly the state it cannot fire in. Verified by breaking it, per this project's rule. Reverting rail_w() to bare max_w fails nine checks; deleting the NOT COVERED handling fails five. The one that mattered: shipping the corrected predicate while NOT passing the rating from check_meter_frozen() left the entire suite green, because nothing graded the caller - so test_freeze.py part 5b now drives the real cycle() on a +-4700 W device and asserts on the notification that leaves the process, and the unwiring mutation fails three checks there. The peak-guard call site's wiring is still ungraded (behind p1_enabled, needs a fed averager for `frozen` to have any observable consequence) and that gap is named in the file rather than implied. Full suite: 15/15 in goodwe-addon-ci. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 02:14:07 +02:00
glenn schrooyenandClaude Opus 5	7b4877d56d	TEST-15: purge the bytecode cache before a mutation run, not after ... FCST-03's developer reverted `self.provisional` to `here.provisional`, re-ran, and reported the mutation as a survivor. It was not one. CPython validates a cached `.pyc` on (source size, source mtime truncated to whole seconds), and that edit moved neither number - same length, same second - so the interpreter loaded the bytecode it already had. Disassembly settled it at the time: the source read `here`, the running code loaded `self`. A mutation run had graded code that was not there, with no error and exit status 0. This does not make the results already on the record wrong. It makes them UNVERIFIED, and that distinction is the whole card - so nothing here re-runs a campaign and nothing here quietly assumes the old numbers hold. REPRODUCED, THEN CLOSED. test_bytecode.py builds a real package whose two return values are the same length, imports it in a real subprocess, rewrites it inside the same second (retrying until both writes land in one whole second - milliseconds, no sleep) and reads back which value ran. Part 1 shows the interpreter running SELF off a file that says HERE. AND THE TWO OBVIOUS MITIGATIONS DO NOT WORK. Measured, not read off documentation: `python3 -B` and PYTHONDONTWRITEBYTECODE=1 are write-side only. Neither stops an EXISTING stale .pyc being read, and a mutation run always has one, because the previous run wrote it. Part 2 grades both still running the old code. The advice in test_control.py's coverage audit led with `-B`; it is corrected here - the purge is the half that works, and `-B` earns its place by keeping THIS run from leaving a cache for the NEXT edit to inherit. NO SLEEP ANYWHERE. One-second mtime resolution is the mechanism, not the enemy. Waiting it out would slow every run down and would still only cover the edit somebody remembered to slow down. THE HARNESS. tools/mutation_run.sh purges, prints a sha256/byte fingerprint of every app/*.py it is about to grade - so a mutation report can say WHICH source produced it, which is the reviewer's addition to this card - runs each suite under `python3 -B`, refuses a tree with no test_*.py (CI-01's rule, for CI-01's reason), and fails if a cache appears during the run. It takes the tree as an argument so the infra repo's replay harnesses can call it without being moved. WHERE IT IS SAID (AC 2). MUTATION.md carries the mechanism, the measurement, the reporting rules and the survey, and every one of the 16 suites now points at it from its docstring. That list is DERIVED FROM THE TREE by test_bytecode.py part 5, so a new suite that joins this directory without the pointer is red - the same failure shape CI-01's file glob exists to prevent. CI WAS ALREADY IMMUNE, AND IS DESCRIBED THAT WAY (AC 4). Verified rather than reasoned: with the checkout bind mounted `-v "$WS:/w:ro"` the interpreter writes no __pycache__ into the tree at all, and it fails SILENTLY - no error, exit status 0 - while the same probe on a writable mount produces one. Each job also rm -rf's its workspace and clones afresh, so nothing crosses between jobs on the shared runner. PYTHONDONTWRITEBYTECODE=1 is added as belt and braces only: the `:ro` is one character wide and the next person debugging a write will be tempted by it. Part 6 grades both ON THE DOCKER COMMAND LINE rather than on the file - the first draft searched the whole workflow and stayed green after the flag was deleted, because the comment explaining it still named it. THE SHIPPED ADD-ON IS NOT AFFECTED and the question is closed: goodwe_controller/Dockerfile has set PYTHONDONTWRITEBYTECODE=1 since it was written. There is no deploy-side finding. THE SURVEY (AC 3), in MUTATION.md, scoped BY THE PROPERTY. The defect is one-directional - a mutation that never took leaves the suite green, so stale bytecode manufactures SURVIVORS and cannot manufacture a red - which puts every "all red, no survivors" claim in the window out of scope, along with mutations executed in-process (SAFETY-07's B1/B2/B3, test_peakguard parts 7 and 10, where no source file is edited) and everything run after the purge discipline landed on 2026-08-31 (SAFETY-24, SAFETY-26, OPT-04, FCST-03's re-run). What is left is the recorded SURVIVORS from source-edit runs before that date. Two were re-run here under the harness and both still stand: TARIFF-01's record_block() ignoring its policy argument, and SAFETY-03's abs() on the clamp limit - 15 suites green each, on the tree as it stood. The rest are labelled still-unverified rather than assumed or re-run; each is one harness run to close, and the moment to spend it is when somebody next touches that module. OUT OF SCOPE AND RECORDED: the infra repo's sim/ replay harnesses import the add-on and write bytecode into both trees (goodwe/sim/__pycache__ exists today), so SAFETY-02's headline replay carries the same exposure. mutation_run.sh takes a tree argument for exactly that, but the change belongs in that repo and some of those harnesses want the rig. RED AND GREEN. Every new check was broken and watched fail: the purge commented out of the harness turns part 4 red (and its non-vacuity probe already proves the fixture would mis-grade without it); one docstring pointer removed turns part 5 red naming the file; `:ro` and the `-e` flag removed from the workflow turn part 6 red. Full suite green, 16 files, in the CI image on a read-only mount - the shape the runner uses. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 02:07:09 +02:00
glenn schrooyenandClaude Opus 5	504e8daac3	TEST-17: grade the status page's peak row at a stated month, not at today's ... release/1.0 went red at 00:00 on 2026-09-01 on a commit nobody had touched. `Controller.checks()` read the capacity-tariff peak with `self.peak.peak()` - no argument - so tariff.py resolved the month from `datetime.now()`, while test_tariff.py section 10 banks its quarter at the fixed fixture 2026-08-30. From 1 September the page was correctly asked for September, correctly answered NO_RECORD, and the row read "no completed quarter recorded yet" - a string containing no "peak", which the section's own filter required. Four checks failed. ISOLATED BY MOVING ONLY THE CLOCK. Same commit, same shipped-deps image, libfaketime: green at 2026-08-30, four failures at 2026-09-01. Identical at f4914a1, 04292c4~1 and 04292c4, so this is the calendar and not a regression. It has been latent since TARIFF-01 merged on 2026-08-30, and every PR that ever ran this suite ran it in August. THE PRODUCT IS RIGHT AND THE TEST WAS WRONG, so the live page is unchanged. Section 5 of this same file calls NO_RECORD "a normal state on the 1st of the month" and a capacity tariff is billed monthly, so a page showing the current month is correct. `checks()` now takes `when: datetime | None = None` and threads it into peak() and warning_frac() - the convention PeakStore.peak(), PeakTracker.peak(), headroom_w() and warning_frac() all already follow. The one production caller passes nothing and still means today. AND THE DEFECT IS NOW DETECTABLE RATHER THAN SEASONAL. Three checks: the same controller read at two different reference months must produce two different rows, which no clock can satisfy; the later month must read NO_RECORD and stay distinguishable from both an observed peak and an unreadable store; and checks() with no argument must still mean today. Verified by mutation - a checks() that drops `when` is red at every clock tried, where the old section went green in August. The first draft of these checks was itself wrong in the same way and reproduced the bug: it selected rows on "peak", which the NO_RECORD row does not contain, so it dropped the row and then graded its absence. They select on "quarter(s) banked" instead. Full suite green, 15 files, at the real clock and at faked clocks in 2026-08, 2026-12, 2027-02 and 2027-03. Left alone deliberately: only the UNREADABLE branch prefixes its row with "capacity-tariff peak:". The NO_RECORD row carries neither that phrase nor the word "peak". That asymmetry is what made the original filter brittle and what broke the first draft above; it is product text with other suites reading it, so it is reported rather than changed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-01 00:58:20 +02:00
glenn schrooyenandClaude Opus 5	04292c4a08	DATA-01: thirty days of the real meter, and what AC 3 actually measures ... TARIFF-01 and SAFETY-07 both merged with AC 3 - "monthly peak held under the soft limit in >= 95 % of intervals over a 30-day simulation replay" - honestly unmet, because two days of capture existed and it was believed nothing longer could be produced. That belief was a true statement about the past read as a claim about the future: HA's recorder still held the whole month, and the reason nobody found out is that the 2026-08-25 export was a one-off script that left no artefact. So the exporter is committed and runnable now. scenarios/p1-net-30d-2026-08/ is 2026-08-01 to 2026-08-30, 485,841 samples, 30/30 days read, 0 failed, 4.13 MB gzipped, in the schema the two committed days already fixed. VERIFIED AGAINST THE DAYS THAT EXIST. `--verify` re-fetches 2026-08-20 and 2026-08-23 by this exact route and reproduces both committed files BYTE FOR BYTE after decompression (865,024 B / 15,600 samples and 894,387 B / 16,351 samples). The gzip containers differ by design: this exporter writes mtime 0 so its output is reproducible, where the one-off wrote a wall clock. A FAILED READ IS NOT AN OBSERVATION. A day whose read fails writes no file, is recorded "read": "FAILED", and the run exits non-zero; the entity is proved to exist through /api/states before any empty day is believed, because a typo would otherwise answer 200 [] thirty times and produce a consistent dataset of nothing. Nothing is interpolated, so the month's 13 gaps (1291 s, 99.95 % covered) and its 3 `unavailable` samples stay visible as holes. SIZE: COMMITTED, DELIBERATELY, AND MEASURED. A git bundle of the whole history goes from 1.58 MB (release/1.0 @ 86c43eb) to 5.28 MB - +3.70 MB, x3.3 - and a Home Assistant supervisor clones that on every install. Downsampling was not on the table: meter_max_age_s is 30 s, so any coarser resample turns real coverage into modelled meter-gap and moves the number being measured. "Outside the repo with a pointer" is what already happened and is why this card exists. The files sit in a SUBDIRECTORY so the non-recursive globs in test_tariff.py part 9 and test_peakguard.py part 6 do not pick them up - CI keeps replaying the two small days instead of growing ~50 s per PR. AC 3, MEASURED OVER 30 DAYS (tools/replay_ac3.py, which must reproduce test_peakguard part 6's 189/190 to be believed): uncontrolled 2847/2879 = 98.89 % of quarters at or under 3500 W guarded 2850/2879 = 98.99 % month peak 5029.8 W -> 4107.3 W Met on the ">= 95 % of intervals" reading - and the uncontrolled figure is the finding, because a month with no controller at all passes it. Not met on the other reading of the same sentence: 4107.3 W is still over the soft limit. The guard pulls 31 of the 32 over-cap quarters down but lands only 3 under the cap, because CEILING_MONTH_PEAK defends the running month peak rather than the cap once one is set. Both suites' honesty notes are corrected to point at the month instead of at its absence. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-31 11:15:02 +02:00
glenn schrooyenandClaude Opus 5	d57122ec74	DATA-02: a real Belgian price year, so AC4 stops being unmeetable ... OPT-04 reported AC4 - "net-positive across 12 months of replayed prices" - as NOT MET and replayed a synthetic year, because scenarios/ held only P1 meter captures. Right call, wrong diagnosis: the criterion was being carried beside a 30-day METER criterion as though both needed waiting. EPEX BE day-ahead is public data, not a capture. It needed a fetch. 8760 hourly points, 2025-09-01 to 2026-09-01 Brussels-local, canonical three fields. Licence checked BEFORE committing: Energy-Charts publishes the BE zone under CC BY 4.0 from Bundesnetzagentur | SMARD.de and other zones under private-use-only terms, so this one is redistributable with attribution. The fetcher refuses to write a file whose per-response license_info stops saying so. Cross-checked against SMARD's own 4996/DE: 96 of 96 quarter-hours, max difference 0.00 EUR/MWh. Raw wholesale, and the file says so. all_in: false, with the markup/tax assumption carried as numbers to APPLY rather than numbers applied - TARIFF-02's trap in data form. Section 7B applies it in one visible place and asserts arithmetically that its additive terms cancel out of every daily spread, so the trade count turns on the VAT multiplier alone; the raw replay is run too, so how much rests on the guess is reported (110 vs 88). DST by construction: iterate in UTC, render through price.brussels(). 2025-10-26 is 25 points, 2026-03-29 is 23, verified by counting per Brussels day rather than asserting 24, and by checking October's 02:00 appears twice at two offsets with two prices while March's never appears. Both bugs the point-and-gap accounting caught were real: a UTC-bounded window made the first day 22 hours, and an inclusive-end off-by-one dropped the last day silently. A day nobody asked for is not a day with no prices. THE RESULT, AT THE SHIPPED DEFAULT, WHATEVER IT IS. At 0.10 widened 1.5x to 0.1500: 110 round trips, +24.88 EUR net of the cycle cost. Unwidened, 173. Nothing tuned - the threshold and the 2.5/1.5 factors are untouched. And what the owner's decision now has under it: the four reports that a static ~0.0840 spread does not clear 0.10 all STAND. What was missing is that a dynamic site clears the widened requirement on 121 of 365 days, median all-in spread 0.1130, so a median day would clear at 0.0754 - 156 trips, +35.42 EUR. Reported, not applied. The synthetic year stays, because the real one cannot grade section 17: not one of 365 days has a negative DEAREST hour, so a zero there counts something that could not happen. 7B asserts that degeneracy rather than reporting the zero. Size measured, not assumed: 893 KB plain but 74.6 KB as a git object against 56.5 KB gzipped. Git already compresses; 18 KB is not worth making the provenance block - the licence claim a reviewer must check - unreadable in a diff. Nothing wired into the add-on; generic_dayahead is still the live path. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-31 11:01:42 +02:00
glenn schrooyenandClaude Opus 5	9234016419	Merge release/1.0 (OPT-04) into SAFETY-24, and fix one grader the merge broke ... OPT-04 landed after the previous rebase. Conflicts were CHANGELOG.md and one IMPORT LINE in validate.py; both refusal blocks and both option sets survive untouched, and DOCS.md, main.py and config.yaml auto-merged. ⚠️ AND THE MERGE BROKE A CHECK THAT NEITHER CARD COULD HAVE SEEN ALONE. test_peakguard.py graded "the first `.decide(` call in main.py" and asserted there was exactly one. That was true when SAFETY-24 was written; OPT-04 added `arbitrage.decide(...)`, so the merged tree had two and the assertion failed. It failed loudly rather than grading the wrong call - the guard did its job - but it cannot ship red. Fixed by selecting the call by QUALIFIED NAME (`peakguard.decide`) instead of by position, and requiring exactly one of THAT. Other modules may now call their own decide(); this grader can no longer be moved by one of them. Verified still discriminating: a decoy `peakguard.decide` added to main.py turns it red on 7 assertions, and the `maintenance_soc_floor` swap still turns it red on 6. Also folded in the review's wording finding. An assertion read "a CONTROLLER whose SoC entity does not answer hands decide() None" while driving no Controller. The wiring property is stronger than the one claimed, and is now asserted on the SERVICE CALL: a Controller with no SoC never reaches the guard at all, because `inputs_ok` is False and cycle() stops at the safety claim first - so a `float(soc or 100)` defaulting line above the call site cannot disarm the floor. The original decide()-level check is kept, reworded to say what it actually grades. Full suite green on the merged tree: 15 files. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-31 07:39:40 +02:00
glenn schrooyenandClaude Opus 5	bdd7f18a54	OPT-04: charge cheap, discharge expensive - and only when it pays ... Four cards built the price stack and nothing traded on it. app/arbitrage.py is §10.1's priority 3, and it consumes all four rather than re-deciding anything: whether a trade is permitted at all, on which two hours, against which widened threshold is TariffPlan.arbitrage()'s answer, and that answer cannot be obtained without first saying whether the peak guard is holding. §9.1's "peak shaving outranks arbitrage" is therefore honoured structurally - there is no path to a spread that skips the question - and again in the arbiter, where P_PEAK (50) clamps a claim filed at P_ARBITRAGE (30). A guard that never ran is not a guard that is clear. On meter_source off the peak guard is never evaluated; that third state is carried as None and refuses, because charging at the rail creates the billed quantity while nothing measures the quarter. validate.py refuses that configuration too, along with arbitrage armed with no price source and a SoC floor at or above the ceiling. §17: never export into a negative price. The guard is on the hour being sold into, not on the spread - a day priced -0.30 .. -0.05 clears any threshold and its dearest hour is still negative. Buying in a negative hour stays allowed. resolve_tariff() may open an HTTPS connection and the tick feeds the ESP32 heartbeat, so the fetch runs in its own task at a 30 min cadence and the tick reads an attribute and an age bound. test_arbitrage.py section 8 asserts that structurally on the shipped AST: a fetch put back on cycle() is red. AC4 is NOT met and is not restated - this repository holds no price history. Section 7 replays a synthetic year and asserts the property that does not need real prices: every executed round trip cleared its own widened requirement, and zero discharges landed in the 522 negative-priced hours. At the shipped 0.10 EUR/kWh threshold a realistic Belgian day/night site does not trade at all. Reported, not tuned: that number and FCST-03's widening factors are one product decision and it is the owner's. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-31 01:36:09 +02:00
glenn schrooyenandClaude Opus 5	a1376e44e4	Merge release/1.0 (FCST-03) into SAFETY-24 - CHANGELOG only ... FCST-03 landed while this was in review, so both branches had prepended an Unreleased stanza. Only CHANGELOG.md conflicted, exactly as predicted; app/, config.yaml, validate.py and DOCS.md all auto-merged, and this card touches neither price_forecast.py nor static_tariff.py. Both stanzas kept verbatim, SAFETY-24's above FCST-03's - no text from either author edited. Full suite green on the merged tree: 14 files. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-31 00:43:58 +02:00
glenn schrooyenandClaude Opus 5	e709554857	SAFETY-24: an energy floor under the peak guard's forced discharge ... SAFETY-07 can command a discharge to hold a billed quarter down, and nothing below it consulted the state of charge. On the 2026-08-20 replay it asks for 878 Wh in a day. Relying on the BMS is not absurd - it is a real floor and it works - but it is the pack's protection rather than the operator's, and a month of aggressive quarters leaves the battery repeatedly at that cut-out with no EMS-side record of why. The first symptom is a pack never available when wanted, which is indistinguishable from the SoC drift MAINT-01 exists to correct. decide() now takes soc and soc_floor, both required and neither defaulted, and discharge_permitted() is the one place the question is answered. Above the floor nothing changes. At or below it the guard files a 0 W floor instead of a sized one - one-directional, so charging stays blocked and no discharge is capped - and reports floor_limited with the reason it bound. It is not a trip: every stop in 11.2's table still outranks the claim, and the floor is never negative, so 9.1's asymmetry survives as a property of the object (0 negative floors over 1296 swept combinations, SoC included). The SoC is graded only after `wanted > 0` is established, so it is never evaluated where it governs nothing. An unreadable SoC is floor-limited, not a full battery - a full battery is exactly the value that would disarm the floor, and this project shipped that defaulting once already. Failing to shave is not silent: one notification per episode (goodwe_peak_soc_floor), distinct from the saturation alarm because the two ask for opposite operator actions, plus its own status row and an action-log line. Verified by replay. The 2026-08-20 capture is driven against a modelled pack sized from the day's own measured appetite, so it genuinely exhausts: without the floor it reaches the BMS cut-out and holds there for 1227 guard cycles; with it the pack stops at 20.0 % and never touches the BMS. The energy withheld equals the energy between the two floors to within one cycle at the rail. The honest half is reported too - the worst quarter goes 4338 W -> 5030 W, because a floor-limited guard shaves less on purpose. Two new options, mirrored once in peakguard.PEAK_OPTION_DEFAULTS (TARIFF-02's pattern), imported by validate.py and main.py rather than typed as literals and pinned to config.yaml by a check that reads the file - so CFG-03 still tracks three places. validate.py rule 8 refuses peak_soc_floor <= bms_soc_floor at startup, in CFG-01/MAINT-04's manner. maintenance_soc_floor is deliberately not reused and not renamed: it is a drain target, not a spend limit, and the rename is recorded as a decision to revisit if a third floor appears. Eleven mutations of the shipped source were run against the checks; all eleven go red and there are no survivors. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-31 00:29:36 +02:00
glenn schrooyenandClaude Opus 5	71cd7849e4	Merge release/1.0 (SAFETY-07) into FCST-03, and close two degenerate stimuli ... CHANGELOG.md was the entire collision - SAFETY-07 lands in peakguard.py, main.py and the arbiter, none of which this branch touches. Both entries kept. X1. `_firm_or_die` guarding only `cheapest` survived, because the check passed the SAME provisional point as both cheapest and dearest: a guard on either role alone raises, so the stimulus could not tell "the buy hour is guarded" from "both are". Now one call per role with a firm point in the other seat, plus the positive arm so the two refusals are discriminating. X6. `firm_points()` returning the carried hours too survived, because its two consumers - the §11.4 refusal and cheap_now - guard provenance independently and both keep answering correctly. The accessor is now graded directly: exactly the published points, by identity and in order. Both are the degeneracy rule this file states at the top, in a new dress - a stimulus that cannot distinguish the two things it grades. ⚠️ AND THE REASON THE M9 MUTATION "SURVIVED" IN MY EARLIER REPORT: a stale __pycache__. Reverting `self.provisional` to `here.provisional` changes neither the file size nor, at one-second resolution, the mtime, so CPython kept the MUTATED bytecode and a green run afterwards proved nothing about that line. Every mutation here now clears __pycache__ first; re-run that way, M9 is caught. The committed source was always correct - the checks were not being run against it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-31 00:15:32 +02:00
glenn schrooyenandClaude Opus 5	dd40c56ab4	FCST-03: yesterday's prices, flagged as yesterday's, and unable to move anything ... §8.3 fills the hours a day-ahead feed has not published yet with yesterday's profile and flags them provisional, and forbids any irreversible action on such a price. The whole risk of this ticket is one line - a carried point and a published point are three fields and a bool, so `provisional=y.provisional` copies yesterday's False onto today's guess and produces stale data presented as current. That is SAFETY-18's frozen-but-fresh meter one layer up. So the flag is never passed through. Carried points come from a constructor with no provisional parameter; published points pass through BY IDENTITY, so no copy exists that could lose one; an audit re-derives the expected flag for every emitted point and raises rather than repairing; and the check walks the module's own AST so the pass-through idiom cannot come back looking ordinary. A published point may itself be provisional (eneco_eddy's imbalance print is), so the rule for a published hour is "whatever the feed said", never False. The fill keys on the Brussels wall clock rather than t-24h, so the 23- and 25-hour days are right; a late publication rebuilds the series, moving the number and the flag together. AC2 and AC3 landed on TARIFF-03's existing verdict surface rather than beside it. Refusal 3 became "fewer than two FIRM hours" - refusing on "any point is provisional" would have switched arbitrage off every morning on every dynamic site - and refusal 5 is new: the spread must clear a threshold widened by the widest active uncertainty source (max, never a product). The permitting variant now refuses to be constructed around a provisional point at all, and the cheap-window flag became per-hour for the same reason. The irreversible action is a value carrying the hours it commits, derived from maintenance.py's own DRAIN_TIMEOUT_MIN; the gate blocks a maintenance drain whose window reaches into a carried hour, and the phase machine stays idle. It is the price-justified entry point only - a gate that blocked on no_data would stop the monthly cycle on every default install. Zero new config options; TEST-14's signature scan ported to cover both Gate's and Arbitrage's constructors, closing _Refused.reason's open hole. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 23:54:07 +02:00
glenn schrooyenandClaude Opus 5	c2ed509565	Merge release/1.0 (TARIFF-03) into SAFETY-07 ... The anticipated conflict again, and only it: both cards prepend to CHANGELOG.md's Unreleased section. Both entries kept, SAFETY-07 first. app/main.py and DOCS.md auto-merged, so the overlap claim on #18 still holds - config.yaml and validate.py remain untouched by this card even after TARIFF-02 and TARIFF-03 widened both. Full suite green on the merge result, test_price.py and test_static_tariff.py included. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 23:43:35 +02:00
glenn schrooyenandClaude Opus 5	9f8b721a4d	Merge release/1.0 (TARIFF-02) into SAFETY-07 ... Conflict was the one anticipated: both cards prepend to CHANGELOG.md's Unreleased section. Both entries kept, SAFETY-07 first. Nothing else of TARIFF-02's surface (app/price.py, validate.py rule 7, config.yaml, DOCS.md) overlaps this card - config.yaml and validate.py are untouched here, so the CFG-03 check still reads a config.yaml that only TARIFF-02 has widened. Full suite green on the merge result, test_price.py included. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 23:13:29 +02:00
glenn schrooyenandClaude Opus 5	303525cfc5	TARIFF-03: static day/night and fully-fixed tariffs, first-class ... §9.2 puts a large share of the Belgian installed base on a static profile, and an EMS that only works under dynamic pricing is an EMS for a minority. A new `static_profile` option describes a two-period day/night tariff - or a single fixed price - and app/static_tariff.py turns it into the same canonical {start, eur_per_kwh, provisional} series the fetched providers emit. Not a sixth provider plugin, for two mechanical reasons. capabilities() is a classmethod, so a plugin's PriceProduct is fixed when the class is written - but §9.2 makes STATIC and FIXED two different products and which one a site is on is a property of the operator's data; StaticProfile.product derives it from the number of distinct prices. And the plugin framework exists to stop a FETCHED figure being marked up twice, which a number typed as all-in cannot be. So the profile sits where §11.4 already says it does - under the providers, as the fallback. Configured product and feed-is-down are one generator differing in one flag, so the degradation path cannot rot unused. "No arbitrage" is a type. TariffPlan.arbitrage() returns a variant whose ALLOWED arm carries the spread and the cheapest/dearest hours and whose REFUSED arm carries a reason and nothing else - .spread_eur_kwh on a refusal raises rather than answering 0.0, so an optimiser cannot compute a trade from one. Four refusals, all derived: peak guard holding, no price data, plan provisional, or the series is FLAT. The last is AC2: a fixed tariff disables arbitrage by arithmetic, not by matching on an enum. peak_guard_active is a required keyword argument, so §10.1's priority 2 over 3 cannot be skipped. Time-window shifting reaches the one shiftable load that exists: main.py's cheap-window flag falls back to the static profile, and the UI gained a Tariff row. Cheap is STRICTLY below the seven-day mean - `<=` would call every hour of a flat tariff cheap, and 48 h taken on a Friday is two-thirds weekend. A profile must tile every day type exactly once, checked at startup; a gap is refused with the range named rather than filled in. `22:00-07:00 mon-fri` does not cover Saturday morning, and that trap is what the check catches. validate.py rule 7's stated reason expired exactly as TARIFF-02 predicted: the test_price.py section 12 tripwire went red naming static_tariff.py. The message now says what is true instead, and the tripwire is re-aimed rather than removed - consumer set pinned, expired phrase asserted gone. Rule 7 also grew a second refusal for static_profile alongside the HA price pair, the same silent-loser conflict and a live one. CFG-03 is not widened: static_profile went into price.py's PRICE_OPTION_DEFAULTS - the one in-code mirror pinned to config.yaml by a check - and the new module carries no defaults dict of its own. Measured on the two committed days of this house's real P1 meter. 2026-08-20 (Thursday): 15.220 kWh imported, 9.606 day / 5.614 night, EUR 4.7185 under day/night vs EUR 4.6725 flat, shifting saves EUR 0.8069 = 9.606 kWh x the 0.0840 spread, derived twice. 2026-08-23 (Sunday): 0.728 kWh, all of it night-priced, which is the weekend row proving itself. §17 names six Belgian scenarios; this is the seventh, and it is two days rather than a season - the file says so rather than implying an annual figure. All 12 suites green. Eleven mutations of static_tariff.py were each caught by at least one check. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 23:07:53 +02:00
glenn schrooyenandClaude Opus 5	616b62d3e9	SAFETY-07: cap the loop before it sets the month's billed capacity peak ... TARIFF-01 measured the quarter and said the consumer would be this card. It is one new module, app/peakguard.py, and one new claim. THE MECHANISM. Every cycle the guard projects the open 900 s block to its end-of-interval average - from P1 telegrams only, never from the command - and compares it to a ceiling. Over the ceiling it files ONE arbiter claim: a lower bound on the setpoint at P_PEAK. That single shape is both behaviours 10.1 asks for, a hard clamp on charging and pre-emptive discharge, and it cannot cap discharge or export, because a floor cannot. 9.1's asymmetry becomes a property of the object instead of a rule to remember. excess = 900 x (projected - ceiling) / seconds remaining floor = MEASURED battery power + excess The 900/remaining gain is 1.0 at the top of the quarter and grows, so the guard is gentlest where its projection rests on the least evidence. The floor is sized from delivered battery power, not the standing command: a floor built on intent re-adds its own unmet ask every cycle and winds to the rail whenever the inverter fails to follow, and test_peakguard.py part 1 shows the two diverging. IT TRIPS, AND THE CAPTURES DECIDED THAT. On the healthy reference day it engages on zero of 95 quarters. The action is level-triggered, unlatched and re-derived every cycle, so a false engagement costs one cycle of discharge rather than a parked battery - the cost SAFETY-18 could not bound and this one can. Replayed on 2026-08-20 the billed quarter goes from 5029.8 W, above the inverter's own 5000 W rating, to 3485 W, under the soft limit and without saturating. Quarters under the limit across both committed days: 189/190 -> 190/190. Two days is not thirty and AC 3 remains TARIFF-01's open item. BLINDNESS IS CHECKED BEFORE THE PROJECTION IS GRADED, and it is a different action. A fresh averager projects a confident 0 W, which is under every ceiling there is; a meter gap longer than meter_max_age_s makes the projection read LOW; a frozen meter reading export projects 0 W at full coverage. All three become a floor of 0 W - no importing while the billed quantity is unobservable - which is one-directional and cannot cost pack energy. That is the backstop SAFETY-18 could not be: its alarm arrives at 300 s of a 900 s quarter and commands nothing. The frozen term is freeze.looks_frozen() itself, on this cycle's standing command. THE CEILING IS peak_cap_w, RAISED ONLY BY AN OBSERVED READING. NO_RECORD and NOT_OBSERVED both leave it at the cap, so an unreadable peak store makes the guard stricter and never looser. The gate is the reading's STATE, not whether a number happens to be attached: today a `peak_w is not None` test behaves identically, and depending on that coincidence is how a future last-known-peak field would raise the ceiling off a read that failed. headroom_w() is deliberately not consumed - cap minus peak turns a zero peak into FULL freedom. TWO DEFECTS FOUND BUILDING IT, both in the interaction rather than the arithmetic, and both caught by running the thing rather than by reading it: * A LIMIT does not out-vote another LIMIT. arbiter.resolve() applies every limit at or above the winner's priority and takes the most restrictive, so the peak floor (lo >= 0) and the maintenance charge-only shaping (hi <= 0) resolved to a CONTRADICTION and 0 W - the battery parked in the exact quarter it should shave. Fixed by suppression, not priority: main.py drops the maintenance shaping while the guard is engaged, which is what that branch already did for the optional peak_forecast_entity - a key empty on a default install, so until now the suspension could not fire on the site that needed it. * Thresholding `excess > 0` released the claim the instant it began working, producing seventeen engage/release cycles in one 900 s quarter and leaving that quarter 49 W over the limit it had spent fifteen minutes holding. That is 10.2's oscillation. The threshold is now the floor itself, which is the same arithmetic read as a level rather than as a switch. PeakTracker.project() no longer reads a private name with a default. getattr(averager, "_last_net", 0.0) failed quiet AND disarming - a rename credits 0 W held, the projection reads low, the money guard does not engage. QuarterAverager.held_net_w is a documented public property now, read without a default, and Projection carries it. TEST-13 item 4. NO NEW OPTION AND NO FOURTH DEFAULTS SITE. The ceiling is peak_cap_w, the coverage threshold is meter_max_age_s, the freeze predicate is meter_freeze_s, and the achievable discharge comes from max_w and the device rating. config.yaml and validate.py are untouched; 14's capacity_peak_limit_kw stays declined. On meter_source: off there are no telegrams, so the guard does not run at all and the status page says NOT COVERED - running it there blinded it permanently and stopped every legacy install from charging, which is what the first cut did until test_clamp.py's export case caught it. test_peakguard.py: eight parts, all figures derived from the shipped config.yaml and the committed captures. Part 8 runs seven one-line defeats of the guard and reports which check bites; six do, and the seventh is reported as NOT caught, because max(cap, peak) makes a zero peak the strictest ceiling there is and there is nothing left to catch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 23:05:05 +02:00
adminandClaude Opus 5	862f0fa574	Merge release/1.0 (TARIFF-01) into TARIFF-02 ... TARIFF-01 (#17) landed on release/1.0 first, so this branch was two commits behind and Gitea reported the PR unmergeable. Integrating rather than rebasing: the two reviewed commits stay addressable, and the branch is protected against force-push anyway. ONE CONFLICT, AND IT IS THE BORING HALF OF THE ONE REVIEW PREDICTED. Review of #16 expected collisions in four places - the tail of `options:`, the tail of `schema:`, the rule list inside validate_startup_config(), and the tail of validate.py. None of them happened: TARIFF-01 touched neither config.yaml nor validate.py. It added app/tariff.py, test_tariff.py, two P1 scenario captures, and edits to main.py and p1.py, none of which this branch goes near. The only conflict was CHANGELOG.md, where both branches prepended a block under the same `## Unreleased` heading. Both blocks kept, TARIFF-02 above TARIFF-01 since it lands second. Nothing was dropped or reworded on either side, and the resolution adds no line of its own beyond the blank one between them. Checked rather than assumed after the merge: - all ELEVEN test files pass, including TARIFF-01's own test_tariff.py (which this branch had never run) and the 93 s test_loop.py; - the 24-mutation battery still has 0 survivors; - no semantic overlap in config: TARIFF-01's peak tracker reads the peak_cap_w / peak_forecast_entity options that already existed, so the price options added here neither shadow nor duplicate anything. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 19:42:16 +02:00
adminandClaude Opus 5	e102cde841	TARIFF-02 review: close the three other doors to the markup, and stop overclaiming ... Review of PR #16 wrote a double-counting plugin four ways. PluginOptions blocked one. The one that decided it touched nothing but PRICE_OPTION_DEFAULTS - a public dict in the module every plugin must already import for register() - so "the number is not in scope" was simply false, and an absolute guarantee a reviewer trusts is worse than a stated limit, because they stop checking. register() now refuses, AT IMPORT, any plugin whose own code mentions a framework-owned name: FRAMEWORK_KEYS plus PRICE_OPTION_DEFAULTS, price_option and _o. code_leaks() parses the class and drops every docstring node before searching, because every plugin is REQUIRED to name its sourced components in prose - engie_dynamic says "markup" in its docstring and a raw text scan false-positives on the documentation the same file mandates. A check that fires on required documentation is a check somebody deletes. test_price.py asserts that a raw scan really would have false-positived, so the strip is proven load-bearing rather than asserted. It fails OPEN if inspect.getsource() cannot find the .py, which the add-on image always can. Refusing to start a battery controller because a static analysis could not run would trade a real outage for a hypothetical accounting error - so instead the checks assert source was found for all five shipped plugins, and a build that lost it is a red check rather than a quietly disarmed guard. All three reachable attacks are written out as plugins in the suite and each must be refused at registration. The cost is measured, not asserted: honest wholesale 0.188, every attack 0.219 - one markup high, every hour, invisible in every log this add-on writes. The guarantee is now stated at its true size everywhere it appears: the framework adds the complement exactly once, GIVEN A CORRECT sources DECLARATION. A plugin that declares {ENERGY} while its feed is all-in still doubles while touching no framework name, and no code can catch that - the declaration is an unverifiable claim about somebody else's tariff. Measured in the suite (0.276) so the limit is a number rather than a caveat. The docstring/declaration check verifies that a plugin's two claims AGREE, not that either is true; that now says so. The three surviving mutations: M3 - _NoData's reason taking a default. This is the identical survivor left open on RIG-01's _Unread.cause: the shape was borrowed from sim/riglock.py including its blind spot, which is what borrowing a shape does if nobody re-runs the mutations against the copy. Closed by SIGNATURE - no constructor or handler of an outcome type may carry a default - so the next one is red without anyone writing a new case. M5 - the ENERGY-required guard was untested. Its consequence is that adds becomes {ENERGY, TAXES} and the emitted price silently omits the energy it is pricing. M7 - deleting the TLS refusal went green AND the check named for it still passed, because the old parser stripped a fixed len("https://") and mangled http://api.energy-charts.info/p into the host pi.energy-charts.info, which then failed the ALLOW-LIST. An assertion that does not test what it names, inside a security check. Fixed on both sides: the scheme is parsed as a scheme, so an http URL now resolves to its real and declared host and only the TLS rule can refuse it; and the check asserts the REASON. Fixing it surfaced M7b - the no-scheme guard was survivable the same way - found by mutating my own fix, and closed the same way. Also carried forward: rule 7's refusal is correct forever but its stated reason ("the provider decides nothing") expires the moment TARIFF-03 or OPT-04 lands. test_price.py section 12 now greps app/ by AST for a load_prices consumer and goes red when one appears, telling whoever lands it to update the message in the same commit. The first draft of that tripwire used a substring and matched the comment in validate.py explaining the tripwire - the same false-positive class as the plugin docstrings, hit twice in one ticket, and fixed the same way. Documented rather than coded around: vars(read).get("points", []) and bool(read) both still get past the absence type, and neither is worth code - defining __bool__ would turn a line that reads like a guard into one that IS a guard by accident, which is how .get(k, default) got here in the first place. Stated plainly in DOCS/CHANGELOG/PR: every fixture is synthetic, so the five feed URLs and JSON shapes are verified against a belief about what those suppliers publish rather than against the feeds. A wrong shape degrades to no-price-data, not to a wrong price. Review's own DST verification recorded: 149,040 hourly instants, 2020-2036, zero mismatches against zoneinfo. The residual is political, not arithmetic, and the docstring now says so. 24 mutations driven through the suite, 0 survivors. Whole add-on suite green. No deleted lines outside this ticket's own files; main.py still untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 19:35:36 +02:00
glenn schrooyenandClaude Opus 5	f4914a174a	TARIFF-01: measure the month's billed peak, and make it survive a restart ... The 15-minute block average was already built and unwired. p1.QuarterAverager computes clock-aligned 900 s blocks, time-weighted over irregular telegram spacing, offtake-only and per-phase; P1Ingest.blocks was a 96-entry list in memory that a restart erased. So this is the persistence and the monthly reduction, not a second accumulator - a second one would be a second source of truth for the exact quantity the money depends on. BLOCKS, NOT A SLIDING WINDOW. The card says "rolling"; 9.1 bills "the highest 15-minute average offtake" and states its own worked case per QUARTER - one 4998 W quarter moving a monthly peak from 4832 to 5013 W. A trailing window reports a peak the meter never bills, and reports it HIGH: a burst straddling :15 fills the window completely while contributing to two block averages at partial weight. DELIVERED, NOT INTENDED. tariff.py only ever sees P1Sample - the meter's own reading - and never a setpoint. SAFETY-20's open question does not arise for a capacity tariff: the utility integrates the current that flowed. AN UNREADABLE STORE IS NOT A ZERO PEAK. peak() answers OBSERVED / NO_RECORD / NOT_OBSERVED with peak_w None unless observed, which is riglock.holder()'s fix applied to something that spends money. A peak read as 0 W hands SAFETY-07 maximum headroom and disarms the guard at the moment its own storage breaks. Restart mid-block resumes the accumulator through a new snapshot()/restore() pair, checkpointed every 15 s and cleared in the same breath as a block close. The held sample keeps its ORIGINAL timestamp, so an outage is integrated under the same max_hold_s rule a running process would apply. quarter_start is the primary key and a re-bank may only ever RAISE a figure. Calendar months are LOCAL: a quarter starting 22:15 UTC on 31 August bills in September. No new option (the limit is the existing peak_cap_w), so config.yaml and validate.py are untouched and CFG-03 is not widened. No second peak entity: peak_forecast_entity stays the input to maintenance_charge_floor(), because repointing that consumer changes what moves energy and belongs to SAFETY-07. AC 3 is NOT met. It asks for 30 days of replay; two days of this house's real meter exist and are committed here. test_tariff.py part 9 replays them, reports the percentage next to the sample size in days, and asserts nothing about 95 %. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 19:13:58 +02:00
adminandClaude Opus 5	852fc7ced6	TARIFF-02: one canonical price format, and a seam that keeps supplier names out of the optimiser ... Five provider plugins - generic_dayahead, engie_dynamic, totalenergies_dynamic, eneco_eddy, manual_csv - all emitting exactly {"prices": [{"start", "eur_per_kwh", "provisional"}]}, tz-aware at the Brussels offset, EUR/kWh, all-in. Nothing consumes it yet; the seam lands first, per the PM's ordering. It is built in goodwe_controller/app/ rather than at specs.md 2.2's ems/ingest/prices/, per the product owner's decision of 2026-08-30. The behaviour 9.3 / 8.3 / 11.4 specifies is unchanged. Three things shape the design, and each is the mechanism rather than a comment saying to be careful: Double-counting the markup is unreachable. A plugin does not return a price - it returns the figure its source published and declares which of {energy, markup, taxes} that figure already contains. assemble() adds the complement, once, in the framework. A plugin is never handed price_markup_eur_kwh: PluginOptions raises FrameworkOption on it, so the line that adds the margin a second time cannot be written. Engie and TotalEnergies publish a retail figure with their margin inside; adding the configured 3 c/kWh on top would have made every arbitrage decision wrong by that amount with nothing reporting it. The product type is declared, not inferred from the plugin's name. eneco_eddy is real-time/imbalance and gets 8.3's widened thresholds through capabilities().product and volatility_regime(), never through a name comparison - which is AC2. test_price.py asserts mechanically that no plugin id appears anywhere in the framework's code, and drives a sixth provider defined inside the test file to the right regime with price.py untouched. "No price data" is a type, not an empty list - the same rework sim/riglock.py took under TEST-04. A fetch returns PriceRead.series(...) or PriceRead.no_data(reason), and only the first carries fields. An empty series is not constructible; no_data has no .points, no .at(), and .get("points", []) raises rather than returning the default. A day of free electricity and a day with no prices are different instructions - arbitrage is pointless under one and forbidden under the other - and an implementation returning [] cannot tell them apart. Every site-level failure returns no_data; nothing raises into the control tick. Also: injection stays a separate scalar (export_price_eur_kwh, AC4), negative prices survive the boundary validator (17's regression case), egress is allow-listed against each plugin's own declaration (16), and no tzdata is used - the shipped Alpine image has none, so Brussels offsets come from the EU rule and instants are carried as UTC. validate.py grows rule 7: an unknown provider id, manual_csv with no path, and - the HA overlap the PM told us to decide about - price_provider set alongside price_now_entity/price_avg_entity, which is two price sources where the HA pair silently wins. The HA sensors are kept and still work alone; TARIFF-03 and OPT-04 are what replace them. CFG-03 is not widened: the price defaults have ONE in-code mirror, PRICE_OPTION_DEFAULTS, which validate.py imports rather than restating and which test_price.py pins to config.yaml by reading the file. test_price.py is runnable, assert-free in the house style, and every verdict it prints is derived. It grades the markup arithmetic with 0.031/0.057 rather than the shipped 0.03/0.06, because 0.06 is exactly twice 0.03 and a degenerate pair would make double-counting indistinguishable from correct addition - and it asserts that non-degeneracy as its first section. The DST checks run on the 23-hour and 25-hour days, not on a normal day where a fixed 24-slot implementation and a correct one agree. Thirteen mutations were driven through it; all thirteen go red. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 19:05:12 +02:00
glenn schrooyenandClaude Opus 5	4e66583a52	SAFETY-03 review fixes: both clamp stages always run, and two checks that could not fail ... 1. BEHAVIOURAL, and a regression this PR introduced. clamp_to_rating() returned early from the max_w stage, so the device bound was applied only when the rating bound had NOT fired - the bigger the overshoot, the less the guard did. At max_w 5000 against a +-4000 device, +9999 emitted +5000 W, outside the device range, while +4500 was correctly held to +4000. It undid the pre-PR guarantee "never send a value the device will reject outright" and undercut this module's own case for max_w-not-min(), which rests on that stage catching a validation that did not run. Both stages now always run; the result names both bounds when both bite (max_w+device). Asserted over a 492-point sweep, because the defect was invisible to any single-value check sitting inside one stage. 2. The hysteresis check issued range(CLEAR_CYCLES - 1) clean cycles, which at CLEAR_CYCLES = 1 issues zero, passes, and prints "0 clean cycles do NOT clear it" - green for the chatter setting the constant exists to prevent. Now: ONE clean cycle must not clear the alarm, a literal that does not move with the constant, and the de-assert count is measured by looping until it clears. 3. The re-assert check stimulated at REASSERT_S + 9, green for any value including 3600 - the hour of silence the module promises not to produce. Now stated in wall-clock terms: a loop pinned across the 900 s capacity-tariff quarter must speak at least 5 times and on no more than 20% of cycles. Pinned in both directions. Red confirmed for each: the restored early return (3 checks), CLEAR_CYCLES = 1 (1), REASSERT_S = 3600 (1) and REASSERT_S = 0 (3). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 15:52:09 +02:00
glenn schrooyenandClaude Opus 5	c040aac4b8	SAFETY-03: alarm when a computed setpoint exceeds the rating, do not just clip it ... The clamp was never the missing half. specs.md 10.3 records an unclamped integrator climbing ~130 W per 4 s past 10 kW and reporting 14 768 W pinned at the 5 kW rail; clipped silently that is a flat, legal-looking 5000 W hold and nothing says the loop asked for three times it. write_setpoint() - the one path every write takes - now clamps to the VALIDATED max_w and reports whether the raw value differed; check_output_clamp() raises OUTPUT_CLAMP as a notification, an ERROR, an event row and a red status banner. Not a trip: the clamped value is written and the loop keeps running. The rating is max_w and nothing is min()ed at runtime - CFG-01 already refuses a max_w outside the device range at startup. The device range is applied second as defence in depth; it cannot bite after a successful validation, so if it ever does it alarms too and names the bound. No new config key. Decision grew i_clamped / clamped booleans, and that is the load-bearing part: `reason` is one string that slew-limiting and the saturation freeze overwrite, so an alarm keyed on it is silent on exactly the cycles a winding loop produces. Mutating main.py back onto the string drops the 10.3 replay from 2 engagements to 0. Distinct from saturation by construction - no shared reason code, notification id, status row or counter - and checked in the negative, after first asserting the saturation freeze really did engage. Two things found by running it rather than by reading it: a row per engagement flushed the 40-row event log and evicted SAFETY-18's own METER FROZEN? row (now coalesced per episode with an exact count), and a naive clamp turns a nan into a command at the full rating because every comparison against nan is False. test_clamp.py is new: assert-based, no framework. Six author mutations reproduced red, including "clamp kept, alarm deleted". Two of the check's own hypotheses about the freeze/clamp interaction were refused by its sweep and rewritten to what it measured. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 15:22:22 +02:00
glenn schrooyenandClaude Opus 5	7cde5d862a	Merge release/1.0 into SAFETY-18 - CHANGELOG only ... MAINT-04 (#10) landed on release/1.0 mid-review, so both branches had prepended a stanza. config.yaml and DOCS.md auto-merged clean; only the CHANGELOG needed a hand. Both stanzas are kept verbatim, MAINT-04's Unreleased above the new 0.5.2 - no text from either author edited. MAINT-04 is unreleased and 0.5.2 is being cut here, so a release manager may want to fold the two; that is an editorial call, not a reviewer's. Full suite green on the merged tree: arbiter, control, loop, maintenance, p1, validate, watchdog, freeze. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 03:20:26 +02:00
glenn schrooyenandClaude Opus 5	ffb8ec6373	MAINT-04 review: pin the default divergence with a check, not a comment ... validate.py's comment said "if config.yaml's value moves, move this and main.py's together" and nothing enforced it - a comment where a check belonged, in a PR that elsewhere proves it knows the difference. test_validate.py now reads main.py and maintenance.py directly and asserts the divergence EXACTLY AS IT STANDS: config.yaml/validate.py at 2000, main.py's two fallbacks and MaintConfig's dataclass default at 2500. It records the mismatch rather than demanding it be closed, so it passes today and goes red if either side moves - including when somebody closes it in main.py, at which point the check and validate.py's block are deleted together. Nothing in a file another ticket owns is touched. The consequence is asserted through the real code as well as the literals: with the key absent the validator accepts, MaintConfig builds 2500 W against a 2000 W ceiling, and the arbiter resolves it to 0 W as a contradiction - the bug rule 6 exists to catch, passing rule 6. Production-unreachable (the Supervisor always supplies every key) but fully reachable from sim/inject.py and the tests, which is where anyone debugging maintenance works. Also: a CHANGELOG section for the upgrade path, covering both the case where the Supervisor re-derives the default and the case where it persisted the old one, since which applies was not verifiable without probing the live install. And maintenance.py's timeout comment said 13.5 kWh where everything else says 13.8 (300 Ah x 51.2 V, DoD 90); SAFETY-18 does not touch that file. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 02:51:40 +02:00
glenn schrooyenandClaude Opus 5	7aa1bd052e	SAFETY-18: a meter frozen at a wrong-but-fresh value now raises an alarm ... A meter that answers 200 OK with a stale document forever is ARRIVING on every poll, so every freshness mechanism in the stack reads it as healthy while the loop integrates a constant error and rails: 360/135/75 s at the live install's max_w: 5000 for a meter frozen at 350/1000/>=3000 W. Fifteen minutes of a 5 kW unattended import sets the month's billed capaciteitstarief peak. The detector is a conjunction, not the bare unchanged_s threshold TEL-05 measured and rejected: unchanged_s >= meter_freeze_s AND |command| within 5 % of max_w Both terms already existed and were already on the status page, and they fail for independent reasons: at the converged point the command is nowhere near the rail, and at the rail against a real load the kWh registers move in seconds. At the shipped 300 s the relation is structural rather than a margin - the slowest a healthy 1 Wh register can tick and still look unchanged is 12 W, which is inside the 15 W deadband, so the command there is parked at 0 W. Notification only, deliberately: an HA persistent notification with a fixed notification_id, an ERROR log line, a UI event and a red status row. No claim, no latch, no 0 W. A false trip parks the battery; a false notification costs an alert. Only meter_source: homewizard_local is covered - the status page says NOT COVERED elsewhere rather than pretending the guard is armed. DOCS.md states the capacity-tariff exposure this does NOT close: peak_cap_w caps maintenance charging and nothing caps the loop. That cap is SAFETY-07. test_freeze.py grades both directions and was verified by breaking what it watches (six mutations, all red): silent over the committed 40-minute converged capture, silent over an hour of TEL-05's low-power case where the rejected bare threshold is shown to fire, alarming on a genuinely frozen meter driven over real HTTP through the real HomeWizardLocalSource (the rig's own hwsim freeze fault when reachable), silent on the same railed command against a meter that is still moving, and asserting on the service call that leaves Controller.cycle() rather than on the watchdog's own flag. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 02:39:54 +02:00
glenn schrooyenandClaude Opus 5	878a6ce452	MAINT-04: refuse a maintenance charge the ceiling cannot deliver ... config.yaml shipped max_w 2000 against maintenance_charge_w 2500. The cheap-window shaping files Claim.limit(hi = -maintenance_charge_w) against the supervised SAFETY limit's lo = -max_w, so lo > hi - the arbiter's clause 3, correctly resolved to 0 W and logged as a CONTRADICTION. Maintenance silently never charged in a cheap window on a default install, and the only evidence read like a bug in the arbiter rather than like the two numbers the operator set. validate_startup_config() now refuses maintenance_charge_w > max_w, the same shape as CFG-01's sign_disagree_w >= max_w. Equality is reachable (-max_w is a single valid point) and is not refused. Demonstrated by starting the add-on on the pre-fix pair: exit 78 and the refusal banner. maintenance_discharge_w was checked rather than assumed and is NOT the same case: the drain phase OWNS the actuator (Claim.set at P_MAINTENANCE), so the ceiling clamps it to +2000 W and the arbiter's explain() names the clamp every cycle. Loud, and it still moves energy - warned, not refused. The shipped maintenance rates drop to 2000 so the defaults pass the rule; max_w was deliberately not raised, because it is the supervised safety ceiling. test_validate.py now reads config.yaml itself, so a default the validator refuses cannot ship again. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 02:28:09 +02:00
glenn schrooyenandClaude Opus 5	e40eb0768d	SAFETY-02: the P_PEAK assertion was pinning the test's copy of the gate ... Review finding 2, and it is the same duplication `disagrees()` just removed, so it gets the same fix rather than a follow-up card. `following_from()` in test_watchdog.py was a TRANSCRIPTION of the gate in main.py, carrying "keep the two in step" as an instruction - which is exactly the arrangement that does not keep two things in step. Measured: editing the shipped gate alone to `winner in ("loop", "peak")` left every suite green while the watchdog went blind for the duration of every peak event. The row whose whole job is to force whoever lands peak shaving to come and change an expectation did not do that. The expression is now `watchdog.loop_is_following()`, called by main.py and by the test. One definition, two callers, same reasoning as `disagrees()`: the copy that drifts is always the one in the harness doing the grading. ⚠️ AND EXTRACTING IT WAS NOT SUFFICIENT - the drift proof still came out green after the extraction, which is why it was worth running rather than assuming. The realistic P_PEAK row has peak shaving asking for MORE than the loop, so the magnitude term rejects it whatever `winner` says and masks the term under test. A second row with peak asking for LESS makes `winner` the only deciding term. With that row, widening the shipped gate fails two checks; without it, none. Also enforcing the write ordering that was documented and not asserted: swapping the two `store.set` calls passed everything. A store that fails the second write now proves the property the ordering exists for - a crash mid-trip leaves a reason with no latch, never a latch with no explanation. Swapping them now turns that check red. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Du77usMj8XNKNFZGmUiWDa	2026-08-28 22:59:46 +02:00
glenn schrooyenandClaude Opus 5	cc4e88490b	SAFETY-02 review: a latch that a restart clears is not a latch ... BLOCKER. `auto` was persisted and `sign_wd.tripped` was not, so reconstructing the Controller against the same store - which is what a container restart does - brought it back ARMED, into the same fault, unattended: tripped=False, banner back to NOT READY, and it resumed commanding -1000 then -2000 W before re-tripping 180 s later. "Restart the add-on" is the first thing an operator looking at a FAILSAFE banner and a 0 W inverter will try, and under a supervisor that restarts a crashed add-on it is a loop of three-minute wrong-direction bursts. DOCS.md's "it does not clear itself" was false across a restart. `sign_tripped` and `sign_reason` are Store keys now, beside the maintenance state and for the reason store.py's own docstring gives. Written the moment the trip happens - reason first, flag second, so a crash between the two can never persist a latch with no explanation - restored in Controller.__init__, cleared only by the operator's start. The regression is covered: reverting the restore fails seven checks in test_watchdog.py. Review follow-ups, no behaviour change: - The arming gate is tested against the REAL arbiter. It is the decision the ticket turns on and it was asserted in three comment blocks and verified by nothing - every case passed `following` in as a literal. Twelve claim configurations now derive it from resolve(), including the redirect case `winner == "loop"` alone would have got wrong and the `lo` limit that raises magnitude without flipping sign. - The MQTT `status: "failsafe"` value is tested. The check that claimed to cover it restated the line above it and never touched the payload. - The worked example described a config that does not ship: at the defaults maintenance_charge_w 2500 against max_w 2000 is an arbiter contradiction and 0 W, not a -2500 W charge. Rewritten at 1500 W. The contradiction is a real pre-existing bug - a default cheap-window maintenance charge silently never happens - filed separately and deliberately not fixed here. - Forward hazard recorded at the gate: `winner == "loop"` disarms the watchdog under any higher-priority SET, and a peak-shaving strategy at P_PEAK IS grid-following in sign, so it would blind this for every peak event. - disagrees() is public so the replay harness stops carrying its own copy of the predicate it grades. - held_s takes the clock instead of reading one. - The two limits are now each stated in both places rather than one each. - The no-false-positive argument is tied to control.py's freeze permitting the command to cross zero; under the shrink-only encoding control.py records as rejected, this would false-trip on a load step. - Measured figures corrected: 93.4 % / 4212 of 17280, per-cluster 0.3/0.9/10.5/0.0, and the near-circularity of those figures is now stated rather than leaned on. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Du77usMj8XNKNFZGmUiWDa	2026-08-28 22:33:15 +02:00
glenn schrooyenandClaude Opus 5	9aed43990b	SAFETY-02: a loop can be fresh, tracking and inside its rating and still push the wrong way ... The stale-input watchdog asks whether the meter is still talking. The saturation freeze asks whether the inverter can follow. The output clamp asks whether the number is too big. A loop can pass all three while charging the battery out of the grid, because the only thing wrong is the sign. On 2026-08-20 a commercial controller did exactly that four times in one day, for up to 77 minutes at a stretch, reaching a commanded -14 768 W against a ±5000 W inverter. app/watchdog.py compares the emitted setpoint against the authoritative P1 figure and, when they oppose each other with both over 300 W for 180 s continuously, files a failsafe SET claim at P_SAFETY, commands 0 W and latches there until an operator starts control again. Validated against that day rather than against an argument: sim/replay_sign.py in the infra repo drives this module over the committed captures of both 2026-08-20 and the healthy 2026-08-23 and reaches 18 trips on the fault day - every one inside a window NOTES.md §4.7 accounts for - and 0 on the healthy day. The four episodes do share one signature: 0.3 / 0.9 / 10.5 / 0.0 % sign agreement inside them against 92.9 % healthy. Three decisions the ticket could not make: - It is DISARMED whenever the grid-following loop is not what is driving. Sign agreement is a property of a loop that follows the meter, and a maintenance grid charge opposes the meter by design - 2500 W of charge into a house drawing 500 W is +3000 W on the meter against a -2500 W command, for hours. The gate tests the emitted number, not the winning claim's name, because a limit claim can let the loop "win" and still replace its value. - The trip LATCHES. Commanding 0 W removes the command side of the comparison, so the disagreement always clears the moment the trip works. - sign_disagree_w at or above max_w is refused at startup. The arbiter never lets a command exceed max_w, so such a threshold leaves the watchdog incapable of firing while the status page still reports it armed. What it does not catch, said out loud: an inverter that ACTS opposite to its command moves the meter further the same way, leaving command and meter in agreement. That is the saturation freeze's job. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Du77usMj8XNKNFZGmUiWDa	2026-08-28 21:51:35 +02:00
glenn schrooyenandClaude Opus 5	aae74d7571	SAFETY-12 review: name the safety claim that could not fire, and fix two figures ... Review fixes. A. test_loop.py takes 73 s, not the ~35 s claimed in three places. That number is the whole defence against a future developer deleting a slow test, so it was understated by 2x in exactly the place it matters. Corrected - and it is now ~95 s (measured 93 s), because this commit adds the scenario below rather than trimming windows to make an inconvenient number smaller. Both call sites carry an instruction to re-measure if the windows change. B. "242 checks" was test_p1's own count quoted as the total for all five suites. The real figure is 395 across the five, plus 14 here. And the finding this PR should have led with. stale_input_s and the `inputs missing -> 0 W` claim both live INSIDE cycle(), so pre-fix, on a meter whose value happened to repeat, that claim could not fire at all. Constant meter, SoC entity dying at t=4 s, one binary: pre-fix final target 220.0 W, reason 'loop -> 220 W' post-fix final target 0.0 W, reason 'safety -> 0 W' The old controller held 220 W through the whole input outage with its status line still reading loop -> 220 W, and layer 1 does not cover that on a `meter_source: off` install - no P1 age sensor is published, so the firmware has nothing to veto on, while the heartbeat keeps its watchdog fed. The pre-fix behaviour was not "holds a stale command safely"; it was a failsafe a repeating meter switched off. Asserted in test_loop.py, both halves. Three points of reasoning tightened, none of them wrong before: - the re-tune is unreachable by construction, not merely by the reset: the combined cycle rate is max(arrival rate, 1/floor), never the sum, and 1/15 s is strictly slower than the ~1/5 s arrival rate. That holds only while the floor exceeds the meter's update interval - and the schema minimum of 5 s is exactly the reference meter's interval. Flagged for validate.py, not fixed here. - the ~11 s lower bracket is not only a dropped poll: a 5.0 s poller against a 4.97 s meter beats, so about every 14 minutes the poller steps over an update entirely. Reaching 15 s takes a beat-skip AND a failed poll. - the "freshness is decided upstream" guarantee is transport-conditional. On `meter_source: off` the grid figure comes straight from hass.number() with no age gate. Running the full law is still right; the claim is narrower than it was stated. The 15 s default is not independently justified - it rests on the firmware's 30 s ingest veto and moves if that ever does. Said beside the constant. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Du77usMj8XNKNFZGmUiWDa	2026-08-28 21:14:58 +02:00
glenn schrooyenandClaude Opus 5	8cc9438aec	SAFETY-12: record the six-minute observation, not just the unit check ... test_loop.py proves the property in 35 s. This is the same three scenarios run for six and three real minutes each, on one binary, and it is what AC2 and AC3 were actually asked for: 1 cycle before vs 24 after on a constant meter with the command stuck at 220 W against a 350 W import, and byte-identical write sequences on both the converged and the normally-changing meter. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Du77usMj8XNKNFZGmUiWDa	2026-08-28 20:48:49 +02:00
glenn schrooyenandClaude Opus 5	88cd97cc7a	SAFETY-12: the loop thinks on a clock, not only when the number moves ... run_control() ran cycle() only when the meter value differed from the previous poll. A meter that repeats a value therefore ran no control cycles at all - while the heartbeat kept re-emitting the last command and the firmware kept putting it on the wire every 2 s. Layer 1 stayed fed and every indicator read healthy, so a command computed from an old reading went on being executed through whatever the load did next. TEL-05 measured it: 70 s at a literally constant 350.0 W, 14 arrivals, zero cycles. cycle_floor_s (default 15 s) is a deadline on the GAP between cycles, reset by every cycle whichever trigger fired - not a second scheduler. On a healthy meter it never elapses, so the cycle rate and the commanded sequence are unchanged; test_loop.py asserts that by driving the real loop twice on one binary (a huge cycle_floor_s reproduces the old behaviour) and diffing the writes. 15 s is bracketed: above the ~11 s worst gap on a merely-unlucky healthy meter (~5 s arrivals, 1 s detection, one dropped poll retried on the next tick), below meter_max_age_s and the firmware's 30 s ingest veto, and equal to stale_input_s. A floor cycle runs the full law. Freshness is already decided upstream - past meter_max_age_s the reading is None, which is a P_SAFETY 0 W claim - and the integrator advances per cycle, not per second, so bounding the gap bounds the accumulation. Not a freeze detector: nothing here decides whether a repeated reading is true. DOCS.md's "accepted deviation" passage is qualified rather than deleted - the window is now bounded at 3 x cycle_floor_s instead of open-ended, and its "nothing accumulates while it is stalled" argument is called out as having covered windup and not staleness. Same correction in control.py's comment. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Du77usMj8XNKNFZGmUiWDa	2026-08-28 20:29:16 +02:00
glenn schrooyenandClaude Opus 5	547d796c5d	CFG-01 review: widen the rule, refuse the firmware-veto case, fix the stop footgun ... Review findings, all confirmed in code before changing anything. THE RULE DID NOT AUTHORISE ITS OWN BEST REFUSAL. The stated test was "makes a safety mechanism inoperative, or makes a stated limit untrue", and a blank setpoint_entity does neither - layer 1 pinning the inverter at 0 W is the failsafe WORKING, as validate.py's own text admitted. The real justification is a second, separate category: the add-on is inert and indistinguishable from healthy. Stated as (a) and (b), with each refusal tagged, and with both halves explicitly bounded - (a) is not "any two numbers that could disagree", (b) is not "anything degraded". Left implicit, the gap is where trivia-creep comes back in. meter_max_age_s ABOVE THE FIRMWARE'S VETO IS NOW REFUSED. The schema allows int(5,300); the firmware's threshold is a compile-time `max_age_s: "30"` and it trips layer 1 at `p1_age_s >= 30`. At 120 the add-on believes a 119 s reading is fresh and keeps commanding while the board has already vetoed and is holding at 0 W - healthy meter, running controller, nothing moving. Structurally identical to the max_w case, and unlike max_w it is settable on this install, so the headline behaviour finally has a live demonstration. That firmware file's own comment says a lower bound on this "belongs in CFG-01, not here". Only ABOVE is refused: below the veto the add-on gives up first, which is fail-safe and visible on its own status page. Scoped to P1 being enabled, because meter_max_age_s governs nothing otherwise. FIRMWARE_INGEST_VETO_S cannot be imported from a compile-time YAML substitution, so it carries a note on the single direction in which it can go stale - and a warning that TEL-06 is editing `ingest_stale`, so a matching integer may stop meaning a matching rule. stop= WAS A LIVE FOOTGUN. It defaulted to None, which made a Controller that cannot stop itself the DEFAULT one. On the late-refusal path that meant: log the banner, return, and leave the process alive forever with no control loop and no exit - the exact "inert but looks healthy" failure this module exists to refuse. Now required and keyword-only, so the broken shape does not construct; test_p1.py's five call sites pass an Event. That whole path had no test and no live demo. It has one now: it drives run_control() against a device that only reports a narrower range once the loop starts, and asserts it refuses, signals, returns, and writes NOTHING - plus the converse, that an agreeing device leads to real writes. This also covers the max_w composition that cannot be reached through the Supervisor on the live install. max_w <= 0 is refused. Schema-blocked in production, but validate_startup_config() is the simulation suite's entry point too, and a non-positive max_w inverts the arbiter's supervised bounds into a contradiction that reads as a safety trip rather than a typo. Verified live 2026-08-28 (backup goodwe_controller-cfg01r2-1787940076): meter_max_age_s 120 refused with a message naming 120, 30, and THE FIRMWARE WINS; no traceback; add-on restored byte-exact and running. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Du77usMj8XNKNFZGmUiWDa	2026-08-28 20:05:10 +02:00
glenn schrooyenandClaude Opus 5	fc9bd89dca	CFG-01: refuse to start on a configuration that cannot be honoured ... main.py used to read the setpoint device's own +-5000 W rating, notice a configured max_w above it, log one WARNING, and run anyway with write_setpoint() quietly clamping. The operator's stated ceiling was never the real ceiling and the only evidence had scrolled off the log. specs §1.5 is explicit that such a config is refused at startup, not survived at runtime. validate_startup_config() runs in amain() before the broker, the web server or any task exists, so a refusal cannot leave half a controller running behind a UI. It refuses exactly three things, all sharing one property - continuing makes a safety mechanism inoperative or makes a stated limit untrue: 1. max_w outside the setpoint device's own rating. 2. No setpoint_entity: every write is a no-op, the device rating is never read, and the ESP32 heartbeat that holds off the layer-1 failsafe never happens. It ran, looked healthy, and moved nothing. 3. A meter_source that can never produce a reading. These were already caught, but they only DISABLED ingestion, which leaves grid None forever: permanent inputs-missing, 0 W, and a status page indistinguishable from a healthy meter nobody has fed yet. Those last predicates move into p1.validate_meter_options(), which build_source() also calls - one definition, two callers, not two competing validators. ha_dsmr with half its entities and mqtt_p1 with a blank topic gained the check the other two transports already had. Deliberately not refused, because untidy is not unsafe: integrator_max_w above max_w (the arbiter still bounds the wire to +-max_w, so the cost is unwind latency - warned), a missing soc/batt entity (fail-safe and already a red NOT READY banner), a setpoint entity that has not appeared on the Core API yet (ESPHome is routinely late; re-checked in run_control() once the real rating arrives), and a thin meter_poll_s margin. A refusal is legible as one: a banner saying in words that this is configuration and nothing is broken, numbered problems, no traceback, and exit 78 (EX_CONFIG). Verified on the live add-on 2026-08-28, not by reading the code: a blank setpoint_entity and a meter_poll_s equal to meter_max_age_s each stopped the add-on with the banner and no stack trace. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Du77usMj8XNKNFZGmUiWDa	2026-08-28 19:29:35 +02:00
glenn schrooyenandClaude Opus 5	c70239cac2	0.4.0: the meter transports that fit this house ... TEL-04 and TEL-05 merged without a version bump, so Home Assistant would not have offered the update - the same trap DEPLOY-01 caught at 0.2.1, recurring because merging a feature does not touch the version. ha_signed reads one signed entity. homewizard_local polls the meter's own API, where every HTTP response is a genuine arrival - the property the firmware watchdog needs, and the one HA cannot provide for a repeated reading. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 01:31:54 +02:00
glenn schrooyenandClaude Opus 5	4d41b0a79e	TEL-05 review follow-ups: show unchanged_s, name a timeout, keep the poll task alive ... Four follow-ups on the reviewed and approved TEL-05 work. Additive; no shipped behaviour changes except the two failure paths below. 1. unchanged_s had no operator surface. DOCS.md told a reader "the transport tracks it as unchanged_s" and there was nowhere to look: main.py built the transport, scheduled run(), and never read the object again. The status page now shows it on the healthy P1 line. Still NOT thresholded and NOT folded into the age - that refusal was reviewed and upheld, because at the converged -10 W this controller aims for a 1 Wh register needs ~6 minutes to move, so any limit false-trips at the target operating point. The whole argument for leaving it to a human requires the human being able to see it. 2. The "equivalent mutant" note on the content_type guard was wrong, and the comment is downgraded to say so. web.Response(text=...) defaults to text/plain, so the fake meter CAN serve valid JSON under the wrong mimetype. Test added; shipped behaviour was already correct. 3. A timed-out poll logged an empty reason: str(asyncio.TimeoutError()) is "", so the status page read "last error:" and then nothing, on a hung meter, at the moment the battery had just gone to 0 W. Falls back to the class name. Note str(err), not `err or ...` - an exception object is always truthy. 4. submit() sat outside the try in poll_once() and run() had no except, so a raise would kill the poll task permanently and SILENTLY - safe (the age climbs, the controller commands 0 W) but indistinguishable from a dead meter. Both wrapped; poll_s is already the retry cadence, so no backoff. Also a comment at the parse_homewizard range(phases) slice: a 3-phase meter configured as 1-phase understates the capacity-tariff figure. Filed separately, not fixed here. 242 checks in test_p1.py (236 before, 6 new). test_control 55, test_arbiter 18, test_maintenance 21, all untouched and green. Each new check proved non-vacuous: six mutations, six named reds, no suite aborts, sources restored byte-identical. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Du77usMj8XNKNFZGmUiWDa	2026-08-25 21:17:36 +02:00
glenn schrooyenandClaude Opus 5	98109a9b91	TEL-05: read the meter, not Home Assistant's opinion of the meter ... A fourth meter_source, `homewizard_local`, polling a HomeWizard P1's own local API (GET /api/v1/data) instead of watching an HA entity. The point is the age sensor. sensor.p1_sample_age_s is FW-01's watchdog input, and on every transport we had it measured "time since the value CHANGED", not "time since the meter REPORTED". Home Assistant offers nothing better: a repeated reading emits no state_changed, advances last_reported on neither serialiser, and state_reported cannot be subscribed to at all. Measured twice - 70 s of a frozen meter on the ENV-01 rig, and ten repeated readings against the live house. Our own capture of this house's meter goes 42.2 s and 97.0 s between changes, both past the default meter_max_age_s of 30, so the age sensor would have commanded 0 W on a perfectly healthy meter. Here every HTTP response is an arrival. The meter answered, now, with its current reading; whether the number moved is not consulted. Five identical readings are five arrivals. Reuses TEL-01's pipeline rather than restructuring it: same split_signed sign convention as ha_signed, same make_sample, same ingest stamping, meter_max_age_s, clock-recomputed age, plausibility bounds and the §20 unsigned-decode rejection. A failed or timed-out poll submits nothing, so it is a missing reading - never 0 W - and does not reset the age. meter_poll_s (default 5 s, the meter's own rate) is checked against meter_max_age_s once at startup, like the ha_signed entity ids. ⚠️ An arrival stamp cannot see a FROZEN meter, and no arrival detector can - one answering 200 OK with a stale number is arriving. The local API does expose what HA never had (the total_power_*_kwh registers stop advancing) and the transport tracks it as `unchanged_s`, but it is deliberately not folded into the age and not thresholded: this controller regulates grid toward ~0 W, and at a converged -10 W the export register needs six minutes to move by its 1 Wh resolution while the power figure legitimately repeats. Thresholding that would rebuild the false-trip limit cycle at the exact operating point we aim for. test_p1.py 179 -> 236 checks. Still defaults to off. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Du77usMj8XNKNFZGmUiWDa	2026-08-25 20:51:23 +02:00
glenn schrooyenandClaude Opus 5	e663e10245	TEL-04 review: unshadow the helper, validate config at startup, and record ... what the rig proved about the age sensor Review findings 1, 3, 5 and 6. Finding 2 is deliberately untouched - it is its own ticket. 3. `built` was rebound at test_p1.py:816 by `built = build_source(...)`, silently disarming the build() wrapper for anything appended below it. Renamed to `sel`. Reproduced the reviewer's failure before fixing: appending a check that calls built() after that line gives `TypeError: 'HaSignedSource' object is not callable` and aborts at 163 of 180; with the rename the same probe reaches 180 and passes. 5. DOCS.md now states the "length must equal meter_phases" constraint that config.yaml already carried, plus what leaving the list empty actually costs: on the surveyed reading the phases carry 2769 W of import while the connection nets 187 W, so the tariff quantity is understated ~15x. 6. build_source now checks the ha_signed wiring once at startup instead of once per telegram: a blank p1_net_entity, or a phase list whose length disagrees with meter_phases, logs an error and disables ingestion. Both otherwise fail in the single way indistinguishable from a healthy source nobody has fed yet - no samples, a climbing age, the watchdog holding the battery at 0 W, and nothing in the log. 1. THE AGE SENSOR. Measured on the ENV-01 rig against the real HomeWizard integration, meter frozen via hwsim's `?fault=freeze` seam (cleared in a finally:, rig verified restored): - websocket state_changed for the meter over 70 s : 0 - last_reported advanced (REST serialiser) : no - last_reported advanced (websocket serialiser) : no - subscribe_events(state_reported) : rejected, "Event filter is required for event state_reported" So Home Assistant exposes NO arrival signal for a repeated reading, and the proposed fix - stamp from last_reported via subscribe_entities - is not available. subscribe_entities listens only to EVENT_STATE_CHANGED, and as_compressed_state carries no last_reported at all. The age is therefore "time since the value changed", which on ha_dsmr is mostly harmless (a telegram moves several entities) and on ha_signed is not: one entity means a healthy meter under a flat load is indistinguishable from a dead one. Recorded loudly in DOCS.md, in the HaSignedSource docstring and in the CHANGELOG, with the measured 42.2 s and 97.0 s gaps from our own capture. meter_max_age_s is deliberately NOT widened. The two conditions produce an identical signal, so a larger number does not separate them - it only chooses which of the two errors you get, and it would disarm the watchdog for a genuinely dead meter as well. The honest fix is an arrival stamp the meter itself provides. test_p1.py: 174 -> 179 checks, all green. Other three suites unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Du77usMj8XNKNFZGmUiWDa	2026-08-25 17:34:37 +02:00
glenn schrooyenandClaude Opus 5	8b51a51e20	TEL-04: a third meter_source for a single signed entity ... TEL-01 shipped ha_dsmr and mqtt_p1, and neither can read the meter that is actually fitted here. The house has a HomeWizard P1 exposing ONE signed entity, sensor.p1_meter_active_power (+ import, - export); ha_dsmr wants two unsigned registers and refuses a negative one outright, which is every exporting telegram. So sensor.p1_sample_age_s could not be produced at this site, and FW-01's watchdog needs it - measured, not theoretical: the house P1 went 51.1 s and 36.2 s without a state change overnight, both past meter_max_age_s 30, so without the age sensor the watchdog would false-trip the battery to 0 W. Adds meter_source: ha_signed, reading p1_net_entity (and optionally p1_phase_net_entities in L1..L3 order for the capacity-tariff peak). The derivation is split_signed(), sitting next to make_sample's subtraction for the same reason it does - the moment a user is asked to write two template sensors that split a signed value, the sign convention is back in unreviewed YAML underneath a safety input, which is exactly what TEL-01 removed. The transport is a subclass of HaDsmrSource overriding only _wanted() and build(), so every rule TEL-01 established is inherited rather than re-implemented: ingest timestamping, meter_max_age_s, the clock-recomputed sensor.p1_sample_age_s republished ~1 Hz, the plausibility ceiling, the "prime the cache from get_states but never build a sample out of it" rule, "a reconnect emits nothing", and unavailable/unknown treated as a MISSING reading and never as 0 W. Defaults to off. An existing install is unaffected until it opts in. test_p1.py: 122 -> 174 checks. Includes an end-to-end run of the new transport against a fake Home Assistant websocket, and the sign convention asserted against real captured readings from sim/scenarios/ha-p1_meter_active_power-2026-08-{20,23}.json (-5710 W at 13:46 local under full sun is export; +775 W at midnight is import). Non-vacuity: ten mutations of the new rules, each applied alone and reverted byte-identical. Nine turn the suite red. The tenth - splitting the per-phase signed values rather than passing them through - is an equivalent mutant, because make_sample subtracts the two lists again and does not sign-check per-phase figures. That is recorded in a ponytail: comment at the site rather than left for the next reviewer to rediscover. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Du77usMj8XNKNFZGmUiWDa	2026-08-25 16:44:22 +02:00