goodwe-addon

664 Commits 209 Branches 19 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
glenn schrooyenandClaude	cdcbe7dbb6	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-29 21:06:09 +01:00
glenn schrooyenandClaude	97686319f3	TARIFF-24 round 3: a run planned with a forecast keeps its gap to its end checks / unit (pull_request) Successful in 51m57s Details infra-pin / fresh (pull_request) Successful in 1s Details 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

Author

SHA1

Message

Date

glenn schrooyenandClaude

cdcbe7dbb6

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-29 21:06:09 +01:00

glenn schrooyenandClaude

97686319f3

TARIFF-24 round 3: a run planned with a forecast keeps its gap to its end

checks / unit (pull_request) Successful in 51m57s

Details

infra-pin / fresh (pull_request) Successful in 1s

Details

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