Repository navigation
PB Plan shows hold for charge charge during cheap rate window #5344
Description
Activity
PB did replan and actually charge the battery over night. I've attached the log from this morning for comparison.
Automated first-pass triage (a maintainer will review before any action is taken).
Classification: duplicate of #5330 — Plan house battery charge earlier in long IOG dispatch period, which is open and covers this same planner behaviour. Please subscribe/comment there; any future change for it will be tracked on that ticket.
What I checked, from your attached files (the plan HTML plus both logs and the debug history — note
.1and.2logs are different download-time archives whose periods overlap, so I merged them by timestamp). No test run was needed; the question is settled by your own data. This worked against a local main clone at57ec7bf1— the session's permission mode blockedgit fetch, so if main has moved on past that, re-check before acting on the pointer below.- Your attached plan (18:30 Oct 1) shows precisely what you describe: within the 23:30–05:30 off-peak band the house battery charges only 22:00–22:30 and 23:30–00:00, then sits flat at ~50% from 00:00–04:30 with the Hold-for-car marker while the car takes the IOG dispatch (2.47 kWh per half hour), tops up 04:30–05:30 and ends the band at ~66%. That is the partially full battery in the morning.
- Nothing blocks charging the battery during the dispatch — this is cost-tie placement, not a hold command. The plan's own rate array prices every minute of that band the same (~6.6p), and your log shows the mid-band charge limit flapping between equally-scored shapes across the evening: ~0% at 18:30, 69% at 19:00, 84% at 21:10, 91% by 23:30. With all minutes price-equal nothing in the cost model prefers filling earlier or fuller; the shape comes from search convergence and plan retention. That is the same root cause recorded in Plan house battery charge earlier in long IOG dispatch period #5330's triage (replayed on main at
v9.3.2-46-g57ec7bf1, essentially your v9.3.3). - Your 17:00 Oct 1 history snapshot predates the Octopus car plan arriving at ~18:00 (it has no dispatch slots), and at that point the plan was exactly what you expect — charging the whole band 00:00–05:30 to 100%. The shape changes when the dispatch arrives.
- Your second log confirms the night resolved itself as you hoped: car and battery charged concurrently (battery 42%→50% between 01:00 and 01:30 with ~11.4 kW grid import, car flagged "charging now" throughout), inverter charge limit written as 100% → 91% from 00:05 → 96% by 03:50 → 100% from 04:50, and the battery reached 100% at 05:15 before the window closed. So inverter execution is fine; this is purely the planner's choice of how much and when to charge inside a price-flat band.
No additional files needed — version, environment, logs and debug data are all attached, thank you.
Duplicate of #5330 — closing this one in its favour.
Posted by Claude on behalf of @chalfontchubby.
Reopening this: it was closed as a duplicate of #5330, but a look at the logs from last night suggests it is a related symptom rather than the same one, and it shares a trigger with #5343.
Summary
The battery was not held back because Predbat decided a full battery wasn't worth it. Every charge window in the plan carries a 100% target, and the battery did reach 100% before the cheap rate ended. What changed the plan was the car plugging in: at about 17:21 the Intelligent dispatch plan arrived, and from then on the planner treats the whole overnight band as one flat 6.57p price. With nothing to prefer filling earlier or later, it picks a lazy shape (charge 22:00-22:30 and 23:30-00:00, hold through the middle of the night, top up 04:30-05:30). That is the part #5330 covers.
Detail
- Before 17:21 the plan was one block, 00:00-05:30 at 100%. After the car plan appeared, modelled load over the 48 hour horizon jumped from about 53 kWh to about 83 kWh, the battery's stored value fell from about 34.7 kWh to about 5.9 kWh, and the cheap band split around the car's dispatch slots.
- Charging in the middle of the night would have been fine, since nothing blocks it. The plan simply had no cost reason to put it there.
- The same 17:21 change is also when the planned 18:00-19:00 export in PB is no longer planning an export during Octopus Power Down Sessions. #5343 disappeared, so both reports look like two faces of one regime change when the car plan arrives. That is likely, not yet confirmed.
So I'd keep this open as related to #5330 and #5343 rather than a pure duplicate. It would help to know whether the hold happens on nights when the car is not plugged in before the cheap band.
Hi - thanks for the detailed explanation, I think I follow it enough to add a bit more info.
I mentioned that this had happened 2 nights in a row this week, both nights will have been very similar, i.e. I will have plugged the car back in before the export for the power down started.
ATM - I'd like to say the hold doesn't happen on a night when the car isn't plugged in. I won't be able to give you a log confirming that until Saturday (I'll have to plug in tonight Friday) - will it be of use to get the log around the same time on Saturday e.g. 18:00 hrs or will Sunday morning give you better data?
Logs look backwards in time - so log from sunday morning is good.
Debug.yamls loog forward - they save the state of things so we can see (and change) what pb is thinking now - so having one of those from saturday night (which you can download sunday morning from the plan->history tab rather than the full tgz which is a bit much) would be helpfulReacted by Sycamore967Some of this is perhaps down to the fact we never used to mark hold for car - the plan just did it but it wasn't represented in the history or plan. Now you see where it is choosing to hold and it perhaps looks unintuitive.
Posted by Claude on behalf of @chalfontchubby.
Thanks for the extra logs - between those and #5330 we've found three separate things contributing to this, plus a connection to an existing open PR. Summary first, detail below.
Summary: your 23:30 slot, the flat middle of the night, and the 04:30 top-up are being decided by three different, independent quirks rather than one bug - none of them are "avoiding the car." One is in #5163, an already-open PR fixing a saving-session side effect that we can now confirm you hit directly. We're working on fixes for the other two.
Detail
-
A real saving session skewed your export threshold that evening. Your debug data shows an Octopus saving session 18:00-19:00 on 1 Oct (8.5p/kWh reward, so your export rate read 20.5p for that hour against a flat 12.0p background). Your logs show the computed export threshold sitting at 12.18p while that session was still ahead in the forecast - just above your real 12.0p rate - which made exporting at the ordinary rate look not worth it, so there was less reason to build up battery stock for it. The moment the session rolled past (19:00:06 in your log), the threshold dropped to exactly 12.0p and that reason returned. This is the exact bug fix(fetch): exclude saving-session/Axle boosted minutes from automatic rate thresholds (#5050) #5163 is already fixing (capping a session's reward back to the tariff's real price before it feeds the threshold calculation) - you're a good real-world confirmation of it, thank you.
-
Windows on either side of midnight aren't considered together. Part of Predbat's optimiser explicitly refuses to move charge between a window that starts before midnight and one that starts after, even when they're priced identically and are really the same overnight cheap period. That's likely why your 23:30 slot got treated separately from the rest of 00:00-05:30.
-
A tie-break in the search slightly favours later windows when prices are exactly equal, which is part of why the plan tends to leave gaps mid-band and fill in near the end rather than spreading evenly or filling from the start.
None of these are about holding back while the car charges specifically - nothing in the code stops the house battery charging at the same time as the car. The shapes you're seeing come from the points above, which we're addressing: #5163 for point 1 (already open), and new work for points 2 and 3.
-
Note this does explain why your system replanned after 7pm to charge fully. Once octopus was in the past, it made sense to charge more because it realised it was profitable to sell at 12p.
Posted by Claude on behalf of @chalfontchubby.
A correction to my previous comment. One part of it was wrong.
Summary: I said this wasn't about holding back while the car charges. It is. Your reading of the plan was right: the car's dispatch is why the house battery's charging was pushed to the end of the night. The other two points still stand: how much it chose to charge (the saving session and #5163), and the split around midnight. What I got wrong was when it charged.
What actually happens
With car charging from the battery turned off, Predbat stops the house battery discharging while the car charges ("Hold for car"). During that hold, two plans cost exactly the same: charge the battery at 00:00 and hold it full, or hold it and charge at 04:30. Nothing flows out of the battery either way, and the overnight rate is flat.
When two options cost exactly the same, Predbat's tie-break prefers not to charge. So it drops the early slots during the hold one by one and keeps only the late ones still needed to fill the battery before the cheap rate ends. That's the flat 00:00-04:30 stretch followed by the 04:30 top-up.
Without a car there's no tie: an uncharged battery would discharge into the house and have to be recharged later, which costs a little in losses, so the plan charges early.
We reproduced this in a test using the same equal-priced overnight slots with realistic battery losses. Without a car the plan charges from the start of the band; with a car holding the battery it charges at the end.
So point 3 in my earlier comment was close but incomplete: the tie-break only bites because the car hold creates the tie.
Nothing actually stops the battery and the car charging together, and on the night they did once Predbat replanned. The planner just sees no benefit in charging early while the hold is on.
Overnight this is benign: the 23:30-05:30 rate is fixed, so charging at 04:30 fills the battery at the same price as charging at midnight, and it was full before the cheap rate ended. Where it does matter is a daytime Intelligent dispatch, whose later slots can vanish. That case is tracked in #5330.
Morning, this has been really interested reading and I appreciate the time you've taken to explain what's happening. I'm also pleased my logs were able to help confirm some earlier noted behaviour. I'll post again on Sunday morning, so hopefully you'll be able to see what I'm seeing in the round encompassing when there is a car charge and not, but the above seems to suggest you've already got the cause.
I've added last night's log, where the only real difference is the lack of a power down session and to confirm that I still had to manually add export slots around the planned car charge. Everything else played out the same as the last two nights. It might also be worth pointing out that although IOG planned a car charge session at 20:30-21:00 the car didn't actually get triggered to start the charge. PB didn't charge the battery (which I believe it would have done in earlier versions as it would have seen the IOG dispatch).
I won't upgrade to v9.3.4 until I've got the logs etc for you on Sunday morning to complete everything on a consistent platform.
- Yes, previously we didn’t charge the house battery if the car didn’t pick up an IOG slot, since interpreting the octopus website literally it says that would be charged full price.
- Could I request in these cases a debug.yaml from the plan history around the start of the period of interest. Thanks. Sent from Yahoo Mail for iPhone On Saturday, October 3, 2026, 11:04 am, Rik Allen ***@***.***> wrote: Yes, previously we didn’t charge the house battery if the car didn’t pick up an IOG slot, since interpreting the octopus website literally it says that would be charged full price.
Debug yaml from the plan->history taken around the start of this log please. We can't do much without it.
Posted by Claude on behalf of @chalfontchubby.
Summary: #5392 reports the same thing you saw, the house battery sitting idle while the car charges overnight. Investigating it led us back to your 1 Oct debug file, and it changes what we told you on 2 Oct. The main cause isn't the scoring tie we described then. Predbat wrongly treats the car's slots inside the guaranteed 23:30-05:30 off-peak window as slots Octopus might cancel. When it plans for that worst case, charging the battery alongside the car looks expensive, so it waits.
On #5392 the false "might be cancelled" marking comes from a rounding bug, fixed in #5396. On your version (v9.3.2) it comes from a different source, the Octopus Energy integration's own dispatch flags, so #5396 won't fix your case. That needs a further change, which we'll track here.
Detail
- Predbat's PV10 (worst-case) scenario re-prices any minute marked
io_adjustedas if the dispatch had gone away, atrate_max(37.36p in your file, versus a normal peak of 28.86p). - In your 1 Oct 18:25
predbat_debug.yaml, 810 of the 960io_adjustedminutes are already at the 6.57p off-peak rate, including the whole 23:30-05:30 window. On v9.3.2, Predbat's own dispatch overlay never setsio_adjusted, so these come from the integration'sis_intelligent_adjustedattribute on the rate feed. - Replay of that file against current main (
--redo):
Car slots 00:00-04:30 Battery at 05:30 Plan total As in your file battery idle 64% £6.58 io_adjustedremoved for 23:30-05:30 onlycharges from 00:00 99% £6.38 - Car charging from the battery is still off (Hold for car) in the second run, and the plan charges early anyway. So the tie we described on 2 Oct isn't what drove this plan. Without the worst-case penalty, charging early is simply cheaper.
- The likely fix is to treat a minute inside the tariff's fixed off-peak window as certain, whoever flagged it, instead of trusting the flag.
- Predbat's PV10 (worst-case) scenario re-prices any minute marked
Describe the bug
The plan shows hold for car, when it should be planning a charge during the cheap rate.
Expected behaviour
Again from tonight the plan shows that during the off peak rate window, where IOG has planned to charge the car anyway, PB will hold for car, instead of charging, leaving me with a partially full battery in the morning. I'm expecting PB to sort itself out and actually charge the battery to 100% by morning, but there is clearly something wrong with the plan as I write this.
Predbat version
9.3.3
Environment details
Inverter and battery setup - GE Hybrid 3.6 Qty 2x 9.5 batteries
Standard HAOS
Screenshots
Log file
The logs and screenshots from tonight's session,
predbat.1.log
predbat_debug_history.tgz.dmp
predbat_plan.html
apps_live.yaml (1).txt
predbat_debug.yaml.txt