2 Commits

Include renames

Author	SHA1	Message	Date
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
adminandClaude Opus 5	017b798fe6	Precedence arbiter: one rule instead of an if/else ladder ... Two controllers writing one actuator is the failure this system exists to avoid. "Exactly one writer" was true, but only as a convention held up by careful reading - which does not survive an EV charger and a heat pump wanting the same battery. Strategies now return claims and arbiter.py resolves them: highest-priority `set` wins (none at all means 0 W), then every `limit` whose priority is >= that set's applies, most restrictive first; contradictory limits command 0 W and are flagged as the bug they are. The second clause is the whole point. "Money outranks maintenance" used to be a hand-written exception inside a Jinja template; it is now a consequence of the priorities - the charge-only limit binds the loop but cannot bind a higher-priority peak claim. Also: maintenance shaping moved out of control.py, which is a controller again and not a policy engine; the loop now tracks the arbiter's actual output rather than its own last wish, so it does not jump when it regains control; and every decision explains itself ("loop -> 0 W, limited by maintenance(charge-only)") in the UI and the log. 19 new assertions in test_arbiter.py, each one a precedence question someone will eventually ask in the field. Deployed to the reference site as 0.2.0 and holding grid within a few watts of zero. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016NckgXecasQb2eSsPYNSW6	2026-08-23 02:45:32 +02:00