5 Commits

Include renames

Author	SHA1	Message	Date
glenn schrooyenandClaude	50b567d6d1	OPT-27: the night plan keeps the last fresh solar forecast ... Forecast.Solar's sensors stop updating in the evening, so at night every such site had no forecast: the night cheap run needed 1.5x the cycle cost and Leftover solar planned nothing. One missed poll also dropped it at once. solarfc.Hold keeps the last fresh reading of each sensor, for the day it is for. A missing or stale sensor is covered by it for up to FRESH_S (a short outage), and from the end of the bell (20:00) until local midnight + 3 h however old. A tomorrow figure is tomorrow's until midnight and then today's; a today figure is only today's. Stored in the controller's store (solar_fc_hold), so an evening restart keeps it. The forecast line says 'Solar forecast read 17:05, used for tonight's plan.' (EN, NL). test_tariff24_weather.py runs with a hold that never covers: it tests what the plan does when the forecast IS lost. Co-Authored-By: Claude <noreply@anthropic.com>	2026-10-30 18:54:41 +01:00
glenn schrooyenandClaude	60a3fa615e	TARIFF-24 forward-port: part 6 reads its last row through nth() (test_named_absence) ... Co-Authored-By: Claude <noreply@anthropic.com>	2026-10-30 08:30:25 +01:00
glenn schrooyenandClaude	9dc22fb987	TARIFF-24 forward-port: pin the hold's edges (review F1, F2) ... Part 6 of test_tariff24_weather.py, the review's probes R4 and R5: - R4: a forecast lost while only the day's give run is under way holds to that run's end (22:00) and no further; the night's cheap run then needs the wider gap. Pins the `solar_fc is None` return in `_wx_track()`: without it the hold chains into the cheap run and B charges (mutant M2, now red). - R5: a give run that starts during a hold runs to its end (`keep_started()`), with no grid charge after the hold. Behaviour unchanged; a give run not kept goes red. Co-Authored-By: Claude <noreply@anthropic.com>	2026-10-30 08:09:44 +01:00
glenn schrooyenandClaude	97686319f3	TARIFF-24 round 3: a run planned with a forecast keeps its gap to its end ... Losing the solar forecast mid-run used to widen the gap at once and stop a grid charge (and a sensor that went unavailable for a minute stopped and restarted it). A run under way when the forecast is lost now keeps the gap it was planned with until it ends (Controller.weather_held(), recorded by _wx_track() each cycle a forecast is read); the wider gap applies from the next run. The plan key holds the hold state so the plan rebuilds when it ends. Home's mirror (homeview.trade_verdict) asks the same weather_held(now). Tests: test_tariff24_weather.py part 4 (going: the charge continues to the run's end, the next run is not_worth; flap of one and two reads: no stop, no restart; Home agrees) and a test_modes_p4.py scenario that runs a forecast day at a gap between 1x and 1.5x the cycle cost. DECISIONS wording follows. Co-Authored-By: Claude <noreply@anthropic.com>	2026-10-28 17:17:56 +01:00
glenn schrooyenandClaude	382b0ea411	TARIFF-24 round 2: a usable solar forecast replaces the "no weather" x1.5 (AUDIT-02 F1) ... With battery modes on, the price gap a mode needs was always widened x1.5 by Uncertainty.NO_WEATHER, even with a solar forecast read, so a 0.08 day/night gap never traded at the shipped cycle cost. The doubt is now added only when no usable forecast is read (solar_fc is None, the day plan's own test), in the run plan (_price_runs), the charge gate (_mode_roles) and Home's mirror (homeview.trade_verdict). The rule is one helper, arbitrage.weather_uncertainty(); the modes-off trade path (main.py cycle) keeps its literal NO_WEATHER. DOCS "Battery modes" sentence, CHANGELOG 0.19.1 line and the DECISIONS note follow. Tests: test_tariff24_weather.py. Co-Authored-By: Claude <noreply@anthropic.com>	2026-10-28 15:08:21 +01:00