3 Commits

Include renames

Author	SHA1	Message	Date
Claude (SAFETY-90 review)	24dbbd18ad	SAFETY-90 review: test that a second gap does not price the first one down ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 12:39:28 +02:00
Claude (SAFETY-90 review)	8dfe91e1d2	SAFETY-90 review: count the start-up seconds like a gap ... While the add-on is down the batteries are at 0 W (it sets 0 W when it stops; the ESP32 watchdog after 30 s), so the import before its first reading was the house, not the aim. Those seconds now count at gap_w(limit, the import seen first), and after a restart the restored reading's held 30 s is topped up the same way. Status row: "counted as high use". Tests take the pre-start import as the house (batteries at 0 W) and add restarts of 10/60/150 s with a restored averager. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 12:24:33 +02:00
Claude (SAFETY-90 dev)	9d3fbe1be9	SAFETY-90: the peak guard goes on after a P1 meter gap ... A meter gap past meter_max_age_s left seconds the quarter average never counted, so the guard was blind for the rest of the quarter (rig case 7b: 3964.8 W against a 3450 W aim). Once readings are back, the missed seconds now count at the higher of the limit and the import seen just before and just after the gap with the batteries at 0 W (peakguard.gap_w/fill_gaps); the gap's first meter_max_age_s is topped up to that too. Seconds before the add-on's first reading count at the aim, and the page says part of the period was not measured (EN/NL). The bill record is unchanged; no option. DECISIONS/SAFETY-90-peak-guard-after-a-gap.md, test_safety90.py. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 11:46:58 +02:00