Repository navigation
Best way to limit Octopus IOG? #5065
Description
I've read through #4885 but my testing shows that even when car is plugged in, if no charge and the rate for that 30 minutes is off peak, home usage is charged at peak and Octopus then show the 30 mins as peak due to no EV charging.
I see a few other issues but no real solution currently.
Is there an easy way, right now, just to limit home charging to where the car is actually charging in a low rate slot. Currently seeing lots of home charging and being stung by peak, so having to turn charge/discharge off entirely.
Activity
springfall2008 commentedon Sep 12, 2026
🤖 Automated first-pass triage (a maintainer will review before any action is taken).
Classification: question — there is currently no setting that does what you're asking for; the capability you're describing is a known open gap rather than something you're misconfiguring.
What I verified against current main (v9.0.2-2-g885c637d):
rate_add_io_slots()(apps/predbat/octopus.py:3281) stamps every future AT_HOME planned dispatch as the cheap import rate for the house battery. It is gated only by the daily slot cap and a drop of already-past zero-kWh dispatches — nothing checks whether the car actually charges in that slot, which is exactly the billing trap you're describing (house import in a half-hour Octopus bills at peak because no EV charging happened).octopus_intelligent_ignore_unpluggedswitch only drops slots when the car is unplugged. A plugged-in-but-deferred car keeps its slots, so it does not cover your case.octopus_intelligent_chargingswitch is not a workaround: it only stops Predbat planning the car's own charging from IOG slots (apps/predbat/fetch.py:1500). Planned slots are still collected (fetch.py:1449) and stamped into the house import rate (fetch.py:1190) either way.octopus_slot_max: 0doesn't help selectively either — the cap is applied to the car-planning path too (apps/predbat/octopus.py:3133/3207 as well as 3359), so it removes the car's charging slots as well.So the only complete way today to stop the house battery leaning on provisional IOG slots is to remove
octopus_intelligent_slotfrom apps.yaml — which also throws away completed-slot tracking and Octopus car planning, so it's usually not acceptable (and is a bigger hammer than your current workaround).This is exactly the gap tracked in #4516 (open) and the load-confirmed dispatch-trust proposal in #4917; #4482 (limit provisional slots using the EV's actual SoC) is closely related. The trust gate from PR #4885 was closed without merging, so nothing from it is in any release — which matches what you found reading it.
If you can add your billing evidence (peak-priced half-hours where the car never charged) to #4516 or #4917, it would help confirm the design of a load-confirmed gate there. Meanwhile, there is no supported configuration that limits house charging to slots the car is actually charging in.
chalfontchubby commentedon Sep 12, 2026
Hi. I share your concern - but to date every time we have checked the sessions that appear to be high rate like this do get charged at the lower rate by the time they turn up in the bill.
If you are able to confirm your final bill shows a high rate, then it will help during discussions as we try and work out the right support to add. I've written a few patches in this area but so far none have been merged. There are quite a few existing tickets.
I'm keen to add the option to ignore cheap slots for planning and only use them opportunistically for charging the battery once we have seen the car charge that slot.
chalfontchubby commentedon Sep 12, 2026
Out of interest, if you filter the log based on "timeline" that shows a slightly confusing view of how future slots are handled through planning, charging etc
iammattmartin commentedon Sep 12, 2026
They don't give the graphs on the bill any more, at least for me.
This was my first bill after the change and loads of peak usage where the car was plugged in but did not charge, predbat saw the lower rate slot and started doing battery charging etc.
The graphs on the Octopus site show the data as peak, predbat off peak and the charges certainly align with peak charging.
iammattmartin commentedon Sep 12, 2026
Just to give an idea, before the IoG changes, my electric use has not changed and my average peak rate bill was around £3-5 a month.
chalfontchubby commentedon Sep 12, 2026
Thanks - I did get graphs on the bill I looked through a couple of days ago - pages and pages of them.
@springfall2008 - thoughts? - could we resurrect one of the patches? What is the best plan?
iammattmartin commentedon Sep 12, 2026
I got my bill up to 26th August with all the graphs. Up to this date, my Octopus app said the charge cap was coming.
After that date, the charge cap was live and then I got a shorter bill from then up to my normal bill date (shown above) for the new 4 rates with no graphs.
springfall2008 commentedon Sep 12, 2026
The bill can be read live via the API, I was wondering about adding it to predbat.
chalfontchubby commentedon Sep 12, 2026
Would be great to be able to reconcile the bill against slots we decide to charge in - quite a lag of course but it would allow us to track when Octopus decide to enforce what they say they are doing.
iammattmartin commentedon Sep 12, 2026
and something else I have seen happen, although this is very much and Octopus issue.
They schedule the slot but never tell the charger to actually charge. Although I suspect the way to detect is the same as the outcome of home usage in what turns out to be peak remains.
chalfontchubby commentedon Sep 12, 2026
Do you control the car or the charger? So far I've not had that too much but I do need to make sure car, octopus, charger are all thinking the same. Hypervolt with vw controlled by IOG.
iammattmartin commentedon Sep 12, 2026
Nope. Andersen charger linked to IoG. They control.
I'd go as far as my setup has not changed pre/post the Octopus changes.
8 remaining items
chalfontchubby commentedon Sep 15, 2026
Yes, I've seen the house charge with octopus showing dispatching with zero drain from the car. (Plugged in - didn't work out why that failed)
Don't know yet what I was charged for those.
leacho73 commentedon Sep 15, 2026
Random snapshot from the 13th September - Not the end of the world, but you can see the consumption after the car had finished charging, about 4kw of use at peak rate from 20:30 - 21:00 - ignore the usage in the middle of the day, this was the 2 hours of free electricity.
PredBat didn't issue the demand command until 21:00 which is when the 30 minute slot assigned by Octopus finished - but the car finished at 20:21, so before the last 30 min slot - not helped by the car bouncing modes as it does - but it had completed. So Octopus classed the 20:30-21:00 slot as peak as no charging happened.
chalfontchubby commentedon Sep 15, 2026
Taking small steps - excluding slots outside the overnight cheap period for planning would be low hanging fruit, so house never cares about dynamic slots - it just holds if the car does start charging.
Next level is opportunistically import if we have evidence there is a dispatched slot and the car has started charging.
Future options once that settles might be to leave a buffer in case there was a dynamic slot we can take advantage of.
I would tend to avoid guessing which future slots will exist based on car Soc because they seem to move around a lot. Just rely on overnight cheap.
I propose agile development of small features in an attempt to to get something merged.
chrisgla commentedon Sep 17, 2026
Following up on #2853 from a while back — same underlying problem, revisited after actually building out what was suggested there.
Been fighting this exact issue for a long time — I moved off Predbat a year ago onto plain HA automations as it was costing too much which is a shame because Predbat/Predheat together would genuinely add value once heat pump consumption is in the mix too.
Setup: FoxESS hybrid inverter, Tesla on Octopus Intelligent Go but charge control is via Wallbox by Octopus (OCPP). The core problem is
rate_add_io_slots()infetch.pywrites a confirmed/planned Octopus dispatch slot straight into the house-widerate_importarray, with no check for whether the car is actually drawing power during that slot, or whether SoC < (ev_charge_limit - 3%). Predbat can see SoC fine — it's Octopus that has issues surfacing reliable state from the Tesla API. Confirmed slots aren't a "maybe" — they get treated as genuinely cheap for the whole house, so Predbat happily Force Charges the home battery from the grid at the same time the car sits idle (already at target SoC, or just not drawing for whatever reason). That's a real peak-rate charge on a slot that was only ever meant to subsidise EV charging.What I've tried, and why none of it is a real fix:
octopus_intelligent_consider_full— helps with "ghost" provisional slots that never confirm, but does nothing for a genuinely confirmed dispatch where the car just isn't drawing.select.predbat_mode = Monitor— doesn't work as a "plan but don't execute" mode; per the docs it stops planning entirely, so you lose the optimisation, not just the control.switch.predbat_set_read_onlyOn (Predbat keeps computing its full Best plan every cycle but never writes to the inverter) plus our own external automation that mirrors Predbat's proposed action from the per-invertercharge_limit/scheduled_charge_enable/scheduled_discharge_enablesensors onto the real inverter — but only when gated by two independent real-world corroboration signals: the EV charger's live power draw, and EV SoC vs. target (with a small hysteresis for tail-off). We apply that gate on both directions — charge and discharge — since the same defective-dispatch problem can just as easily misfire an export decision, which is really four gate checks in total (charge×power, charge×SoC, discharge×power, discharge×SoC).That last approach is basically reimplementing what #4885/#5110's trust-gate design was going for, just anchored on actual measured EV telemetry rather than dispatch-timing heuristics (planned/started/none). Wondering if there's appetite to add real power/SoC corroboration as an optional trust signal alongside the timing-based gates in #5110. Happy to share our HA logic if it's useful as a reference implementation — but it's only a workaround, since it can't actually gate the incoming dispatches themselves as "needed" vs. "accepted" at source.
chalfontchubby commentedon Sep 17, 2026
Having Soc based gating is absolutely viable. I'm hoping for an agile approach of getting something landed then improve it rather than trying to get everything in and never getting anything merged.
I would say the majority of users seem to have the majority of slots confirmed - there isn't a lot of evidence on these tickets of full price charging in dynamic slots, but there is certainly some.
I don't mean in that you are not seeing it - I suspect some combinations of usage patterns and setups are more prone to this - whether it is the pattern of how the car is used, which of car/charger is controlled, what models of each (and hence which 3rd party cloud is in the mix). And perhaps Octopus behaviour also evolves over time.
I believe the impact is real, but perhaps it affects different people to different extents, so a decision taken on the basis of the whole population of users isn't ideal for some outliers.
Hopefully landing 5110 at least can prevent/mitigate expensive charges, even if it reduces the upside of the extra cheap charging slots for the house.
chrisgla commentedon Sep 17, 2026
Even before recent changes Octopus have always been clear that if the EV is not drawing then it's not a slot that their accounting system will validate as off-peak- so it is a full price slot. This is regardless whether it's dispatched by Kraken. In my case where I've got an older Tesla Octopus never do that as they can't see SoC, only Wallbox control. Octopus could actually check current draw/ charge state via OCPP, but they don't and in fairness maybe all chargers don't offer this. So I usually get full price charging in dynamic slots as the car isn't charging much. I'm really hopeful it can be landed, static automations for IOG aren't too difficult- but I could really do with the load and particularly heat pump management. It's really sad to see Predbat doing the right calculations then an invalid dispatches flag wrecking the entire plan. This afternoon I was meant to be discharging, instead I've had to do the auto inhibit until I can go in and manually re-plan
iammattmartin commentedon Sep 17, 2026
I know that is what they said but that was not what I saw.
My car always used to be plugged in, often no charge required (after all, they encourage leaving it always connected).
I always got low slots with no car charge and this was always at off-peak rate for all usage including house. This was consistent since October when my solar/battery/ev was installed - until now.
chrisgla commentedon Sep 18, 2026
I'm pretty sure I have been charged. I've got a large enough ESS battery that I only use peak in Dec/ Jan, but on bills there's been bits of peak rate use. Not the easiest to correlate and in reality I'd rather fix than bodge something then won't work when they implement contracted policy across the board at some point. Octopus clearly still struggle a bit- I get charge slot assigned notifications when the cars not even plugged in or at home at times, but they have direct OCPP to charge so I can't really see what's going on.
chalfontchubby commentedon Sep 18, 2026
Trying to get something merged - but I don't have rights to do that myself.
iammattmartin commentedon Sep 29, 2026
I do wonder if there is a way to stop the car hold? As in, if the car is charging and the battery needs to charge, to allow it. I see more and more in a low cost slot when the car is charging, the battery is held for that to stop it depleting in to the car but what if you want to ensure the battery fills up in the cheap (given the limited slots now)
chalfontchubby commentedon Sep 29, 2026
You can set manual charge I believe if you want to override PB's normal planning. If there is a need for charging we should be calculating that and doing the right thing anyway. If you find examples of it not doing the right thing, then that a new issue please.
Or if manual forced export doesn't work - then please raise that issue.
I think this issue has been answered not - with 5229 completed. I'd like to close it and have new issues for anything else - otherwise things get missed.
iammattmartin commentedon Sep 30, 2026
I guess my reasoning here is that I want predbat to take advantage of any low slot it can to fill the battery because the slots are now much shorter, often 30 mins here and there. I'll keep an eye but having an abiity to not hold any charge during cheap times because car is charging would be ideal.
chalfontchubby commentedon Sep 30, 2026
That would change the basic algorithm of predbat, assuming what it's already doing is not efficient.
If you see it doing it wrong, that's another issue. Thanks.