Saving session / Axle VPP rate boost breaks automatic low-rate threshold - binary_sensor.predbat_low_rate_slot stuck ON, day rate reported as "low rate"

[kamenmackay]

When a saving session / Axle VPP event is in the forecast, Predbat boosts both the import and export rates for that slot by the reward (load_saving_slot / load_axle_slot, tagged rate_replicate = "saving"). In automatic threshold mode (rate_low_threshold = 0), set_rate_thresholds() sets rate_import_cost_threshold = rate_max - 0.5, where rate_max now includes the synthetic boosted slot. On a two-rate tariff (25.95p day / 3.49p night) with a 100p/kWh event, the threshold becomes 125.45p and rate_scan_window classifies the entire ordinary day rate as "low rate windows".

Result: binary_sensor.predbat_low_rate_slot turned ON (on a 25.95p slot) and stayed ON continuously for ~24h - through the genuine 3.49p night window and the whole expensive day rate - and predbat.low_rate_start/end/cost reported the 25.95p day blocks as low rate.

Expected behaviour: the automatic threshold should be computed on the underlying tariff rates, excluding slots boosted by saving sessions / VPP events (the saving tag in rate_replicate is already there to key off), so only genuinely cheap tariff slots qualify.

Impact: automation-facing low-rate sensors misfire (an automation of ours fired on a non-cheap slot), and for users planning car charging on rates this would widen the car-charge scan to the whole day rate. The optimizer itself is unaffected (it uses the best-price thresholds).

Version: v9.0.2, HAOS add-on, GE inverter via GivTCP, Octopus Intelligent, 1 car.
Workaround: set rate_low_threshold to ~0.9 (threshold = 0.9 × average; our 25.95p day rate then correctly drops out).
Suggested fix: in set_rate_thresholds() (fetch.py), compute rate_min/rate_max/rate_average for the threshold over import rates excluding saving-tagged minutes.

I will add that this issue was mostly generated by the AI feature in Predbat and the only thing that I will add that it missed is that I had plan prediction set out to 36 hours rather than 24 (I've since switched it to 24) which I think might be important.

[springfall2008]

Automated first-pass triage (a maintainer will review before any action is taken).

Classification: bug — priority_medium (automation-facing sensors misfire while an event is in the forecast; workaround exists: set rate_low_threshold to ~0.9, as the reporter found).

Confirmed against current main (v9.0.2-1-g7f0d73d6) with a reproduction test — the reported mechanism is exactly what the code does:

• load_saving_slot() (octopus.py:2909) and load_axle_slot() (axle.py:674/682) add the event reward to the import rate table as well as export, tagging those minutes "saving" in rate_replicate.
• rate_scan() runs after those boosts (fetch.py:1191-1197), so rate_max/rate_average include the synthetic boosted slots.
• In automatic mode set_rate_thresholds() (fetch.py:2367) then sets rate_import_cost_threshold = rate_max - 0.5. With a 25.95p day rate and a +100p event that is 125.45p, and rate_scan_window() classifies every minute below that as "low".

Reproduction (48h two-rate table 25.95p day / 3.49p night, +100p saving slot 17:00-19:00 tagged "saving", rate_low_threshold=0):

rate_max=125.95 rate_min=3.49 rate_average=30.54 threshold=125.45
44 low-rate windows, 1320 low minutes, window averages: [25.95, 25.95, ...]

i.e. the 25.95p day blocks come back as low-rate windows — matching the stuck-ON binary_sensor.predbat_low_rate_slot and 25.95p "low rate" entries the reporter saw.

Three things a fix should account for:

1. rate_average is distorted too. In the repro the true tariff average is ~17.7p but rate_average comes out 30.54p, so the manual-multiplier path (rate_import_cost_threshold = rate_average × rate_low_threshold, fetch.py:2361) is inflated as well. The reporter's 0.9 workaround landing at 27.5p (just above the day rate) is a lucky fit of their tariff numbers, not a principled threshold — so the fix belongs on the stats, not just the automatic branch.
2. The in-cycle auto-correction doesn't help. fetch.py:1244-1245 re-sets the threshold to highest (the priciest found window's average, ~25.95p here) after the scan, but low_rates was already computed with the wrong threshold and everything downstream in the cycle (low-rate sensors at output.py:411, car-charging slots at fetch.py:1356, and charge_window_best = clone_windows(self.low_rates) at plan.py:1382) consumes that pre-correction list; the wrong threshold is recomputed fresh every cycle.
3. "Optimizer unaffected" is only approximately true. The planner's price-level search re-prices from actual per-minute rates, so its final choice is usually still near-correct, but its candidate set is the widened day-spanning low_rates (plan.py:1382, active when set_charge_window is on), so candidate granularity is degraded — worth including in any fix's blast-radius review.

Root-cause pointer: set_rate_thresholds() (fetch.py:2348-2371) computes the automatic threshold from rate_max/rate_average that include event-boosted minutes. The suggested fix is sound: derive the threshold stats from minutes not tagged "saving" in rate_import_replicated (the tag is already written by both the Octopus and Axle loaders) — and likewise consider the mirrored export side, whose auto threshold cross-compares rate_export_min against import rate_min (fetch.py:2380), both of which are boost-contaminated.

No additional information needed — the report is precise and reproduced without a log/debug dump. Possibly related to #2090 (a different saving-session reporting baseline gap, same function family).