car_charging_plan_smart produces two opposite failure modes depending on max_price — blocks all planning at 0p, wildly over-plans (including peak-rate slots) at 30p

[jHamshaw]

Title: Created with the assitance of Claude....

Summary

With switch.predbat_car_charging_plan_smart On for both cars, input_number.predbat_car_charging_plan_max_price produced two distinct, reproducible bugs depending on its value:

• At 0p: zero car charging ever planned, regardless of a genuine, large SoC-to-target gap and a confirmed real Octopus IOG dispatch slot.
• At 30p: car charging planned wildly in excess of what's physically possible, including repeatedly at 30.27p peak rate — the opposite of what "smart" price-aware planning should do.

It should be noted that this is IoG with the charge cap switched on.... Octopus move the slots around a lot more now, particularly during house peak day rate times....

Evidence — max_price = 0p (blocks everything)

Debug log/ History Plan - consistent across every plan cycle:

Cars 2 charging from battery False planned [False, False], charging_now [False, False]
smart [True, True], max_price [0.0, 0.0]p, plan_time ['06:30:00', '06:30:00'],
battery size [77.0, 84.0]kWh, limit [61.6, 67.2]%, rate [7.4, 7.4]kW, exclusive [True, True]

At the time, Car 1 (EV6) had a genuine SoC of 34.5% against a real configured target of 80% (number.ev6_ac_charging_limit = 80) — a ~45.5% gap (~35kWh on an 84kWh battery) — with a confirmed live Octopus dispatch slot (03:00–07:30, 07:30–08:00, matching the Octopus app). Despite this, planned [False, False] and zero Car kWh appeared anywhere in the 48-hour plan.

Secondary bug spotted in the same log line: limit [61.6, 67.2]% does not match either car's real configured target (80% for both). Working backwards: 80 × 0.77 = 61.6 and 80 × 0.84 = 67.2 — i.e. each car's real 80% target appears to be getting multiplied by its own car_charging_battery_size (in kWh) ÷ 100, which looks like an internal scaling bug (percentage being treated as if it needed dividing by a kWh-based factor). This didn't block planning on its own (both scaled-down limits were still above current SoC), but could plausibly cause a car to stop charging early in other circumstances where the true target and the miscalculated one straddle the real SoC.

Evidence — max_price = 30p (wildly over-plans)

After raising car_charging_plan_max_price to 30 (comfortably above the 6.9p cheap rate, below the 30.27p standard rate), the very next plan showed:

• Total car energy planned: 74.66kWh across 48 hours — exceeding the combined capacity of both cars' batteries (77kWh + 84kWh) from completely flat, despite the real remaining need being ~13kWh (EV6 at 64.5%→80% on an 84kWh battery) and the VW showing as full.
• Car energy planned repeatedly during 30.27p peak-rate slots, e.g.:

Sat 15:00  30.27p  ...  Car kWh 5.22
Sat 15:30  30.27p  ...  Car kWh 7.12
Sat 16:00  30.27p  ...  Car kWh 6.70
Sat 16:30  30.27p  ...  Car kWh 5.16
Sat 17:00  30.27p  ...  Car kWh 6.78
Sat 17:30  30.27p  ...  Car kWh 6.72
Sat 18:30  30.27p  ...  Car kWh 4.94
Sat 19:00  30.27p  ...  Car kWh 7.14

This is the opposite of what a price-capped ("max price to pay") smart planner should do — a 30p cap should exclude 30.27p slots entirely (they're above the cap), yet they're where most of the phantom energy is concentrated.

System context

• 2-car setup, single shared Zappi charger, car_charging_exclusive: [true, true]
• octopus_intelligent_charging: true, car_charging_slots correctly pointing at the live IOG dispatch sensor (confirmed matching the real Octopus app slots)
• car_charging_only_charge_plugged_in: true, car_charging_assume_needs_full_charge: false
• Both car_charging_plugged_in sensors confirmed correctly reflecting real-world plug state at time of testing
• Predbat version: v8.46.4–v8.47.x (across the testing window)

Question for maintainers

Given both failure modes trace to the same smart/max_price mechanism, and the 0p case's debug log also shows a plausible unrelated scaling bug on limit, it may be worth checking whether car_charging_plan_max_price is being compared against the correct per-slot rate at all (e.g. compared in the wrong units, or against a stale/default rate rather than each slot's actual price) — that would explain both a 0p cap blocking real cheap slots and a 30p cap somehow not excluding 30.27p slots. Turning car_charging_plan_smart off entirely (relying on car_charging_slots + basic SoC-to-target logic) appears to avoid both failure modes in initial testing.

History Plan :

History Plan.pdf

[chalfontchubby]

Thanks for the very thorough write-up - a couple of things worth sharing before we go further.

The "limit shows as %" thing isn't a scaling bug. car_charging_limit is deliberately converted from your configured percent target into kWh internally (fetch.py:1978: target_percent × battery_size_kwh / 100) - that's exactly your 80 × 0.77 = 61.6 and 80 × 0.84 = 67.2. It's genuinely in kWh by the time it's used for the SoC-gap arithmetic; the debug log at fetch.py:1983 just mislabels it with a % suffix when it should say kWh. Cosmetic log bug, not a functional one - worth fixing on its own, but it's not causing the planning problems.

car_charging_plan_smart/car_charging_plan_max_price shouldn't be able to cause either failure mode you're seeing, given both your cars are on octopus_intelligent_charging: true. Traced it through: those two settings are only ever read inside plan_car_charging() (plan.py:4711), and fetch_sensor_data_car_planning() (fetch.py:1107-1151) explicitly skips calling that function for any car on Octopus Intelligent - it just logs and moves on. For an IOG car, car_charging_slots is instead built entirely by load_octopus_slots() (fetch.py:1263), which has no reference to max_price or smart anywhere in it. So toggling max_price between 0p and 30p shouldn't be touching this code path for either car at all.

Given that, and given your own note that "Octopus move the slots around a lot more now, particularly during house peak day rate times" - my best guess right now is that what changed between your two test runs was the actual Octopus dispatch slots themselves (genuinely different car_charging_slots data from the IOG API), not the max_price/smart settings - coincidence of timing rather than causation. That doesn't mean nothing's wrong; slots landing in a 30.27p peak window, or zero slots despite a real SoC gap, would still be a real bug if that's genuinely what Octopus/load_octopus_slots() produced - just a different one than you're currently pointing at.

To actually pin this down I'd need a same-moment predbat_debug.yaml + screenshot pair from one of your two test windows (the 0p case or the 30p case, whichever you can reproduce more easily) - that'll show us the real car_charging_slots Predbat had for each car at that exact moment, which is the piece I can't reconstruct from the log excerpt and PDF alone.

[chalfontchubby]

One more thing worth flagging here: your point about Octopus reshuffling dispatch slots a lot more now than it used to is independent corroboration for something #4270 has been sitting on for a while - it adds a confirm/provisional check so the house battery doesn't commit to a big import on the assumption a dispatched slot will be used, only actually relying on it once car_charging_now confirms the car is genuinely drawing current.

If Octopus is now routinely moving slots around after Predbat has already planned against them, that's exactly the failure mode #4270 is trying to close off - a slot Predbat planned the house around can disappear or shift, and without a confirm step the house still commits to the import regardless. Given you're independently hitting more dynamic Octopus behaviour in this issue too, flagging it here in case it helps the case for picking that PR back up: #4270