14 Commits

Include renames

Author	SHA1	Message	Date
Claude	591c35ed01	SAFETY-28: gate the write path on the allocation record, not on key count ... specs §1.5 makes "any configuration in which two writers can reach one actuator" a non-goal. That non-goal was enforced by counting config keys: validate.py's ACTUATOR_WRITE_KEYS = ("setpoint_entity",), consumed at rule 1, with a comment stating the guarantee outright - "there is exactly one such key, so a second writer is not expressible in the options schema at all". That was true and it graded THE SHAPE OF THE OPTIONS SCHEMA, not the writes. Add CFG-04's per-inverter config - a roster of inverters each with its own setpoint_entity - and there are two real writers with len() of that tuple still equal to 1. The check stays green while the property it protects is gone. sim/inject.py's two_writers scenario asserted on the same tuple, so it went green too. That is this repository's named failure mode: a check that observes something other than what it claims to observe. Demonstrated rather than argued. test_validate.py part 2 now constructs the hazardous per-inverter config, asserts that the OLD proxy is still green on it, and then asserts the new check refuses it. Against release/1.0's validator the updated sim scenario reports: "validate_startup_config() ACCEPTED a configuration in which 3 declarations reach the ONE actuator number.goodwe_setpoint ... the old proxy reports 1 write key(s) on this same config and is therefore GREEN on it". THE WRITE PATH IS NOW GATED ON THE RECORD ========================================= Controller.write_refusal() asks Allocation.authorises() whether the single allocator placed exactly this number, for this unit, on this tick. write_setpoint() refuses anything else. A second writer with arithmetic of its own cannot satisfy that - its number appears in no record - so it has to file a Claim and go through resolve(), which is the one allocator. "Exactly one allocator per shared resource" stops being a convention somebody can forget and becomes something the write path checks. The refusal is a SUBSTITUTION, not a return: 0 W goes on the wire in place of the number nothing stands behind. Returning would leave the inverter latched on its last command with the ESP32 heartbeat still being fed - holding an unauthorised setpoint quietly, which is the outcome the gate exists to stop. AC 1 is "refused at the write path, not merely logged", and test_clamp.py part 7a grades the device's writes, not the log. The gate sits BELOW the non-finite coercion and ABOVE the clamp. Below, because a nan is loss of input and rule 1 has already turned it into 0 W. Above, because the question is who chose this number, and the answer is only meaningful about the number that was asked for - gating the CLAMPED value would refuse exactly the cycles SAFETY-03 exists for, since a clamped write differs from the allocator's share by construction. Mutation M7 moves the gate below the clamp and turns nine checks red, part 6c among them. A STALE RECORD CANNOT BE REPLAYED ================================= Every Allocation now carries the `tick` it was made for. It is handed IN by the caller - plan(..., tick=) - rather than counted inside the allocator, because test_alloc.py part 10 grades that the module holds no state at all, and a serial number incremented in there would be the cached-across-ticks thing the envelope rule forbids wearing a different hat. Controller.alloc_tick advances ONCE PER RESOLUTION, not once per loop iteration, and both halves are load-bearing: * a new allocation makes the previous record stale immediately, so a record whose envelopes have moved cannot authorise a write. That is the replay half (AC 2), graded by capturing a real record, running another real cycle, putting the old one back and observing refusal. * the "inputs missing, not yet stale" hold returns BEFORE the allocator runs, exactly so one dropped meter reading does not zero the inverter, and the heartbeat re-affirms self.target through this same gate while it does. A tick incremented per loop iteration would refuse that heartbeat and turn the hold into the outage it exists to prevent. Graded. An UNSTAMPED record (tick None) authorises nothing: "I cannot say when I was made" fails closed rather than reading as tick zero. THE FAILSAFE CANNOT DEADLOCK BEHIND THE GATE, AND HERE IS WHY ============================================================= write_setpoint() is also how layer 2 commands 0 W. cycle()'s two refusal branches substitute a 0 W failsafe and write it like any other cycle; shutdown() and the operator's stop button do the same. EVERY ONE OF THOSE RUNS WHILE THE ALLOCATOR HAS REFUSED - ok is False and there are no shares - so a gate that asked the allocator's permission to command zero would block the safety write behind the very component whose failure the safety write answers. A gate that can do that is worse than the hole it closes. Resolved by authorising 0 W unconditionally, and on the VALUE rather than on a failsafe=True flag: a flag is an assertion by the caller, which is exactly what a second writer would pass; the value is a fact about what will be written. The argument that this is safe and not merely convenient is that the hazard §1.5 names is N-times loop gain from BROADCAST - handing every inverter the same target so each supplies it in full (allocator.py's opening argument; TEST-19 measured a permanent 4000 W p2p limit cycle at gain 1.0 with no guard firing). At S = 0 the broadcast and the correct allocation COINCIDE: a_i = 1 for every unit gives every unit 0 W, which is exactly its share. There is no over-command to make at zero. Said at the line, in write_refusal(). test_clamp.py part 7c drives it end to end through the real cycle() and the real REFUSE_EMPTY branch: the allocator refuses every tick, the device still sees 0 W, and the action log says ARBITER: REFUSED rather than WRITE REFUSED so the two failures stay distinguishable to whoever has to debug them. unmet_w IS STILL NOT ok ======================= The gate reads ok and the unit's share and never unmet_w. allocator.py:179 says why: an allocation that could not place every watt is still safe to write, and fusing them would let one saturated inverter park the whole site. Graded on a record with 3800 W unmet and every share legal - mutation M5 adds `or self.unmet_w` to the gate and that check goes red. THE CONFIG CHECK, REPLACED RATHER THAN DELETED ============================================== actuator_writers() counts WRITERS PER ACTUATOR instead of option keys. It walks the options TREE rather than looking for a container called `inverters`, because CFG-04 has not chosen that name yet and a census that guessed wrong would go green while two writers existed - the same defect one step along. Entity ids are folded to lower case so a second writer cannot be smuggled in as Number.X versus number.x. Two inverters with two entities are ACCEPTED - that is what the per-inverter roster is for, and a validator that refuses the feature it guards is one somebody switches off. Two declarations aimed at ONE entity are refused, naming the actuator and every writer pointed at it. That includes the case an author will meet first - keeping setpoint_entity as A's and listing A again - because "they happen to be the same entity, so it is fine" is precisely the reasoning that makes two writers invisible. ACTUATOR_WRITE_KEYS survives ONLY as the enumeration a census needs, with its guarantee comment deleted; nothing asserts on its length any more. Keeping the name is also what stops admin/goodwe's current two_writers scenario failing on an AttributeError between the two merges. WHAT NEITHER CHECK OBSERVES, SAID OUT LOUD ========================================== The census sees CONFIGURED writers. A second write path added in CODE - a hass.set_number() call next to some new strategy - declares nothing and is invisible to it, exactly as it was invisible to the tuple. That half is not closed at startup and cannot be; it is closed at runtime by the record gate, which does not care what the options look like or who called the method. The two checks are deliberately different kinds, and only the runtime one survives a schema this file has not seen yet. EVIDENCE ======== * Full 18-file suite green on a purged tree (tools/mutation_run.sh). * Verified by breaking it - seven mutations, each on a purged tree, each reverted and re-verified: M1 remove the gate -> test_clamp red (4 checks) M2 make the zero exit an amnesty -> test_clamp red (12 checks) M3 drop the tick comparison -> test_clamp red (5 checks) M4 delete the census refusal -> test_validate red (3 checks) M5 fuse unmet_w into ok -> test_clamp red (1 check) M6 freeze the tick on the live path -> test_clamp red (2 checks) M7 move the gate below the clamp -> test_clamp red (9 checks) * AC 5: no existing check was weakened. The two edits to test_clamp.py are fixtures, not assertions - parts 5 and 6c call write_setpoint() directly with a number nothing allocated, which is now refused, so they say where their number came from. Every assertion in both parts is unchanged, and part 7f asserts that across part 3's sixty real cycles the gate refused zero writes. * admin/goodwe's TEST-19 norig scenarios (planner_binding, two_master_plant, two_master_broadcast) still pass against this tree - they import the add-on's control law across the repo boundary. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-02 13:56:48 +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
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	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	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	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
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
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	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	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	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	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