A kept tomorrow reading (same day, at most 12 h old) now stands in at any hour, not only from 20:00 (Hold.stand_in()). Today members and the OPT-34 morning rules are unchanged; no partial sums.
Tests: new test_opt38.py (red on b291262, green here). Two existing checks changed because they asserted the old daytime behaviour: test_opt27.py (14:00, tomorrow stale 5 h) and test_opt34.py (08:00, tomorrow sensor down 4 h).
Mutant restoring the evening gate: 4 checks red in test_opt38.py.
A kept tomorrow reading (same day, at most 12 h old) now stands in at any hour, not only from 20:00 (`Hold.stand_in()`). Today members and the OPT-34 morning rules are unchanged; no partial sums.
Tests: new `test_opt38.py` (red on b291262, green here). Two existing checks changed because they asserted the old daytime behaviour: `test_opt27.py` (14:00, tomorrow stale 5 h) and `test_opt34.py` (08:00, tomorrow sensor down 4 h).
Mutant restoring the evening gate: 4 checks red in test_opt38.py.
Co-Authored-By: Claude <noreply@anthropic.com>
One stale Forecast.Solar tomorrow sensor dropped the whole OPT-17 sum from
17:54 to 20:00. Today readings and the OPT-34 morning rules are unchanged.
Co-Authored-By: Claude <noreply@anthropic.com>
The forecast rule is right. A stale tomorrow reading stands in only for its own day0 and when it is at most 12 h old. Today readings, the OPT-34 morning rules and OPT-17 are unchanged. I found no case where a figure is used for the wrong day (midnight, DST, a sensor down for more than 12 h). The new test is red on b291262 and green on the head. The mutant that puts back the BELL_TO_H gate is red (4 checks). CI runs 1550 and 1551 are green, and the full local suite is green (98 files, 0 failed).
Blocking: the daytime "kept" line.read_sum() sets Forecast.kept when only the tomorrow side is kept (kept = kept or (tday is not None and tkept)). Before this PR, that could only happen from 20:00. Now it also happens in the day. The Home, Batteries and Simple solar line, and the Forecast tab's today line, then show "Solar forecast read {at}, kept for tonight." instead of "Solar still to come today: X, we count on Y". The {at} time is the fresh today reading's time. Probe at 14:00: today read 13:55 and fresh, tomorrow kept from 09:05.
base: Solar still to come today: 2.5 kWh, we count on 1.8 kWh. Updated 13:55.
head: Solar forecast read 13:55, kept for tonight.
The event log says "read, kept from 13:55" in the same way.
Requested changes:
Before BELL_TO_H, a kept tomorrow reading must not set the flag that drives the today line. Either keep a separate tomorrow-kept flag, or count tkept towards kept only in the evening.
Add a test: at 14:00, with today fresh and tomorrow kept, the Home line is the normal "Solar still to come today" line.
In the edited test_opt27.py 14:00 check, change fd.kept to match. In test_opt34.py 08:00, change fy2.kept to match.
About the two old checks I was asked to look at: their tomorrow figures follow from the decided rule. At 14:00 the 09:05 reading is used. At 08:00 the 03:50 reading for the 5th is used, never the 3rd's. Only their kept assertions lock in the problem above.
Review of c43873b: **not merged, one change needed.**
The forecast rule is right. A stale tomorrow reading stands in only for its own `day0` and when it is at most 12 h old. Today readings, the OPT-34 morning rules and OPT-17 are unchanged. I found no case where a figure is used for the wrong day (midnight, DST, a sensor down for more than 12 h). The new test is red on b291262 and green on the head. The mutant that puts back the `BELL_TO_H` gate is red (4 checks). CI runs 1550 and 1551 are green, and the full local suite is green (98 files, 0 failed).
**Blocking: the daytime "kept" line.** `read_sum()` sets `Forecast.kept` when only the tomorrow side is kept (`kept = kept or (tday is not None and tkept)`). Before this PR, that could only happen from 20:00. Now it also happens in the day. The Home, Batteries and Simple solar line, and the Forecast tab's today line, then show "Solar forecast read {at}, kept for tonight." instead of "Solar still to come today: X, we count on Y". The `{at}` time is the fresh today reading's time. Probe at 14:00: today read 13:55 and fresh, tomorrow kept from 09:05.
- base: `Solar still to come today: 2.5 kWh, we count on 1.8 kWh. Updated 13:55.`
- head: `Solar forecast read 13:55, kept for tonight.`
The event log says "read, kept from 13:55" in the same way.
Requested changes:
1. Before `BELL_TO_H`, a kept tomorrow reading must not set the flag that drives the today line. Either keep a separate tomorrow-kept flag, or count `tkept` towards `kept` only in the evening.
2. Add a test: at 14:00, with today fresh and tomorrow kept, the Home line is the normal "Solar still to come today" line.
3. In the edited `test_opt27.py` 14:00 check, change `fd.kept` to match. In `test_opt34.py` 08:00, change `fy2.kept` to match.
About the two old checks I was asked to look at: their tomorrow figures follow from the decided rule. At 14:00 the 09:05 reading is used. At 08:00 the 03:50 reading for the 5th is used, never the 3rd's. Only their `kept` assertions lock in the problem above.
Before the bell ends it replaced today's Home line and the event log with
the kept-for-tonight wording. stand_in() docstring covers the tomorrow case.
Co-Authored-By: Claude <noreply@anthropic.com>
All 4 requested changes are done. The kept flag for a kept tomorrow reading now starts only at 20:00, and there is a 14:00 Home-line test for EN and NL. That test fails on c43873b (9 checks) and passes on the head. The two old checks now assert not kept, and the stand_in() docstring has its clause. My probe at 14:00 and 18:00 now gives the release/1.0 line ("Solar still to come today: 2.5 kWh, we count on 1.8 kWh. Updated 13:55."), and tomorrow is still there.
From 20:00 to 07:00 next day, the head behaves exactly like b291262. I compared the kept flag, the tomorrow figure, the Home line and the event-log word every 10 min. There were 132 samples over 2 cases and no difference.
Local runs: test_opt17, test_opt27, test_opt34 and test_opt38 all pass. CI runs 1552 and 1553 are green on 0bacafa.
The midnight edge does not block this merge. It is a separate card: a tomorrow reading that comes after midnight with yesterday's value.
Nit, not blocking: the stand_in() docstring line at solarfc.py:337 is 113 characters long.
Re-review, round 2 (0bacafa): **right, merging.**
- All 4 requested changes are done. The kept flag for a kept tomorrow reading now starts only at 20:00, and there is a 14:00 Home-line test for EN and NL. That test fails on c43873b (9 checks) and passes on the head. The two old checks now assert not kept, and the `stand_in()` docstring has its clause. My probe at 14:00 and 18:00 now gives the release/1.0 line ("Solar still to come today: 2.5 kWh, we count on 1.8 kWh. Updated 13:55."), and tomorrow is still there.
- From 20:00 to 07:00 next day, the head behaves exactly like b291262. I compared the kept flag, the tomorrow figure, the Home line and the event-log word every 10 min. There were 132 samples over 2 cases and no difference.
- Local runs: test_opt17, test_opt27, test_opt34 and test_opt38 all pass. CI runs 1552 and 1553 are green on 0bacafa.
- The midnight edge does not block this merge. It is a separate card: a tomorrow reading that comes after midnight with yesterday's value.
- Nit, not blocking: the `stand_in()` docstring line at solarfc.py:337 is 113 characters long.
admin
merged commit 23ff9d0920 into release/1.02026-11-07 06:56:10 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
A kept tomorrow reading (same day, at most 12 h old) now stands in at any hour, not only from 20:00 (
Hold.stand_in()). Today members and the OPT-34 morning rules are unchanged; no partial sums.Tests: new
test_opt38.py(red onb291262, green here). Two existing checks changed because they asserted the old daytime behaviour:test_opt27.py(14:00, tomorrow stale 5 h) andtest_opt34.py(08:00, tomorrow sensor down 4 h).Mutant restoring the evening gate: 4 checks red in test_opt38.py.
Co-Authored-By: Claude noreply@anthropic.com
Review of
c43873b: not merged, one change needed.The forecast rule is right. A stale tomorrow reading stands in only for its own
day0and when it is at most 12 h old. Today readings, the OPT-34 morning rules and OPT-17 are unchanged. I found no case where a figure is used for the wrong day (midnight, DST, a sensor down for more than 12 h). The new test is red onb291262and green on the head. The mutant that puts back theBELL_TO_Hgate is red (4 checks). CI runs 1550 and 1551 are green, and the full local suite is green (98 files, 0 failed).Blocking: the daytime "kept" line.
read_sum()setsForecast.keptwhen only the tomorrow side is kept (kept = kept or (tday is not None and tkept)). Before this PR, that could only happen from 20:00. Now it also happens in the day. The Home, Batteries and Simple solar line, and the Forecast tab's today line, then show "Solar forecast read {at}, kept for tonight." instead of "Solar still to come today: X, we count on Y". The{at}time is the fresh today reading's time. Probe at 14:00: today read 13:55 and fresh, tomorrow kept from 09:05.Solar still to come today: 2.5 kWh, we count on 1.8 kWh. Updated 13:55.Solar forecast read 13:55, kept for tonight.The event log says "read, kept from 13:55" in the same way.
Requested changes:
BELL_TO_H, a kept tomorrow reading must not set the flag that drives the today line. Either keep a separate tomorrow-kept flag, or counttkepttowardskeptonly in the evening.test_opt27.py14:00 check, changefd.keptto match. Intest_opt34.py08:00, changefy2.keptto match.About the two old checks I was asked to look at: their tomorrow figures follow from the decided rule. At 14:00 the 09:05 reading is used. At 08:00 the 03:50 reading for the 5th is used, never the 3rd's. Only their
keptassertions lock in the problem above.Re-review, round 2 (
0bacafa): right, merging.c43873b(9 checks) and passes on the head. The two old checks now assert not kept, and thestand_in()docstring has its clause. My probe at 14:00 and 18:00 now gives the release/1.0 line ("Solar still to come today: 2.5 kWh, we count on 1.8 kWh. Updated 13:55."), and tomorrow is still there.b291262. I compared the kept flag, the tomorrow figure, the Home line and the event-log word every 10 min. There were 132 samples over 2 cases and no difference.0bacafa.stand_in()docstring line at solarfc.py:337 is 113 characters long.