PredBat 9.3.3 with Octopus car_charging_planned set - not charging battery

Describe the bug
Since setting the car_charging_planned variable in apps.yaml - I notice that the battery does not charge as planned when the slot is at the off-peak rate.

Expected behaviour
I have set the car_charging_planned variable to my Zappi Plug Status - so that it can monitor for charging - the plus is currently charging, but the battery is discharging.

This does not happen in versions 9.3.1 and below.

I love the idea that PredBat is now checking for valid charge slots - but I am now not able to fill my battery during the off-peak rate.

switch.predbat_octopus_intelligent_dynamic is on
switch.predbat_octopus_intelligent_charging is on

car_charging_now : 're:(sensor.wallbox_portal_status_description|sensor.myenergi_zappi_[0-9a-z]+_plug_status)' - I have also tried this with the CT clamp value for the Zappi, but the same behaviour.

Predbat version

9.3.3

Screenshots

Automated first-pass triage — a maintainer will review this before any action is taken.

This is classified as a bug. Detailed triage is on hold until the files below are attached: the report needs Predbat's actual configuration, rates and plan data to investigate, and screenshots alone aren't enough for that — so no theory or cause is being offered yet, to avoid guessing.

Please attach:

A predbat_debug.yaml and predbat.log captured while the problem is happening — the problem reports as repeating, so please capture them during a slot where the battery should be charging but isn't. Both come from the Debug panel on Predbat's web interface. The debug file downloads as predbat_debug.yaml.txt and can be attached as-is.
If the incident is over instead: the debug snapshot for that time, from the Debug column on the plan's History view (Predbat web interface → Plan → History), next to the time slot where it happened. With default settings only around the last 48 hours are kept, so grab that soon if it applies — and a predbat.log covering that period if you still have one.
When it happened (date, time, timezone) is also useful, along with the Octopus-integration/myenergi side if you have it (e.g. the Zappi sensor states and the dispatch schedule at that time) and screenshots of the plan or HA history graphs for the battery entities — the screenshots posted already cover some of this, so keep them handy in the ticket.

Details: debug history docs

Behaviour on 9.3.1 - which is what I would expect.

@leacho73

please provide the requsted files @leacho73

predbat.log

I think that the 're:(sensor.wallbox_portal_status_description|sensor.myenergi_zappi_[0-9a-z]+_plug_status)' mighe be part of the problem....

The debug shows sensor.myenergi_zappi_17281751_plug_status which isn't my sensor

#5317 might be related

Automated first-pass triage — a maintainer will review this before any action is taken.

Following up on the earlier comment now the attachments are in, with three things found — one of them means we still need a file from you.

1. The attached predbat_debug.yaml is not from your system. Your own predbat.log at the same minute (01 Oct 15:00) shows Inverter 0 SoC 1.63kWh of 9.7kWh (17%), while the debug yaml's state dump says 9.809kWh of 12.58kWh (78%), and it lists entities you don't have (sensor.myenergi_zappi_17281751_plug_status, a GivEnergy ch2344g125 inverter, different Octopus account ids) — which is why that serial looked wrong to you. Your regex actually resolved to sensor.myenergi_zappi_16165997_plug_status in your own log (01 Oct 08:40 and 15:38), so entity selection is working. Please attach your own debug yaml from the Debug panel (the one you posted is another user's, so no config conclusions should be drawn from it).

2. Your log contains a clean before/after comparison, and it confirms the change you described. The log shows you running v9.3.1 through 01 Oct until you updated to v9.3.3 at 08:41, then back to v9.3.1 at 15:35 — so the two versions are compared ~10 minutes apart on the same afternoon, both with the car plugged into a started dispatch that Predbat's verification had cancelled (Octopus Intelligent: car 0 is in a dispatch but not charging, cancelling its slots at 15:07 and again 15:43):

9.3.3 (15:31): the house's rate for those dispatch minutes had been re-priced back to the normal 27.49p, the plan left the battery discharging (SoC 8% → 6% → 2%), and the log records removed the dispatch rate from 355 minutes of cars [0] which are not charging (repeated 15:07–15:29).
9.3.1 (15:42–15:55): the same cancellation had happened at 15:43, but the cheap 6.57p dispatch rate was left in place and the battery was charging (Charging target 2%-100%).

Best-supported mechanism, needing your own debug yaml to confirm: on 9.3.2/9.3.3 dispatch slots are only kept as cheap for the house when the car is confirmed charging in them (plan.py slot confirmation, gated on your octopus_intelligent_dynamic switch which is on), and a cancelled dispatch's discount is then stripped for the house too, outside the fixed 23:30–05:30 band (octopus.py dynamic_load_car_strip_feed_rates). On 9.3.1 a not-charging car released only the car's own kWh but left the house rate cheap, so the battery charged. PV10 planning also re-prices intelligent-adjusted minutes more than 30 minutes ahead at the max rate (prediction.py ~739), which started reaching integration-fed rates once the marker wipe was fixed in v9.3.2 (#5290/#5286), alongside the car-side change in #5304. Since most of your cheap minutes are dispatch-shaped rather than the fixed band (your own log's charge windows show the band as dispatch-sized pieces with holes), the effect on your plan is large. This is consistent with the maintainer's pointer to #5317, and separate from #5316.

3. One behaviour worth checking on your side: Predbat never saw your car as charging on 01 Oct (charging_now [False] all morning) while you report the Zappi was charging. If the Zappi was charging in an eco/boost mode, its plug status string may not match your car_charging_now_response: 'charging' — if it never reads "charging" at those times, the car never confirms its slot and the cancellation above is triggered. Please check the sensor.myenergi_zappi_16165997_plug_status history at the times in your screenshots.

Still needed:

Your own predbat_debug.yaml (Debug panel), captured while the battery is not charging in a cheap slot.
Your apps.yaml as .txt, especially car_charging_now_response and the octopus_intelligent_trust_slots setting.
If you re-enable 9.3.2/9.3.3 and it happens again, the debug snapshot for that slot (Plan → History → Debug column).

Interim option to test: turning switch.predbat_octopus_intelligent_dynamic off stops the cancellation and the strip, returning closer to 9.3.1's behaviour — at the cost of re-introducing the low-load protection #5229 added, so a maintainer judgement call on where that balance should sit.

Classification: bug · Priority: medium (IOG users generally; the workaround above is coarse).

Same problem. Car has been charging for 16 mins - but no battery charging - the 2330-0530 also looks affected

Logs please, for predbat and the state of the zappi sensor

And debug.yaml

Can you see car_charging_now going true in the logs

sorry was on my phone - logs attached

predbat.log
predbat_debug.yaml.txt

Battery keeps bouncing between charging and not charging

Your log shows the charging change is working: Predbat saw the car charging at 19:41:24, two seconds after your Zappi switched to Charging, and put the dispatch back (car 0 slots resumed).

Before that, from 17:01 until 19:41, your Zappi reported EV Connected and the car took no energy (0.0 kWh in every hourly log line), even though Octopus had dispatches open from 18:30. Predbat cancels a dispatch the car isn't using, as Octopus may not bill it at the cheap rate. That's the on/off you saw. It's worth checking why the car didn't start until 19:41: Zappi mode, or the car's own charge schedule.

Since 19:41 the plan charges the battery from 21:00 to 22:30, still inside the 6.57p dispatch, so it costs the same as charging now.

@chalfontchubby

Posted by Claude on behalf of @chalfontchubby.

To wrap up: this was a configuration mismatch, not a fault in the plan.

Cause: car_charging_now pointed at your Zappi's plug_status, which reads Charging, but car_charging_now_response didn't include charging. So Predbat never saw the car charging and cancelled the dispatch for the house battery.
Fix on your side: adding car_charging_now_response: ['charging'] resolves it. Your 19:41 log shows the dispatch resuming as soon as the Zappi switched to Charging.
Tonight's plan is fine. Your dispatch plus the off-peak band gives 10 hours at 6.57p (19:30-05:30). With your flat 12p export, the plan charges from 21:00, exports some of it back at 12p, and recharges overnight. That's why the battery isn't charging continuously.
Fix on Predbat's side: fix(fetch): accept a charger's "Charging" status in car_charging_now_response by default; document matching #5338 adds charging to the default list and the templates, and documents how the matching works, so the next Zappi user doesn't hit this.

If you have a list of your own in apps.yaml, keep charging in it after upgrading. The new default only applies when the setting is left out.

Battery is still at 0% and the car has been charging since 19:41 - it's still flicking between charging and discharging - my config is as above.

Any charge slots planned get removed

@leacho73

Battery is still at 0% and the car has been charging since 19:41 - it's still flicking between charging and discharging - my config is as above.

Any charge slots planned get removed

@leacho73

please provide log and debug after you made the above change cant debug from just a description

Appears to be working now with:

car_charging_now_response: ['charging']

Rather than:

car_charging_now_response:

'charging'

Navigation Menu

Repository navigation

PredBat 9.3.3 with Octopus car_charging_planned set - not charging battery #5335

8 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

PredBat 9.3.3 with Octopus car_charging_planned set - not charging battery #5335

Description

Activity

springfall2008 commented on Oct 1, 2026

leacho73 commented on Oct 1, 2026

gcoan commented on Oct 1, 2026

leacho73 commented on Oct 1, 2026

chalfontchubby commented on Oct 1, 2026

springfall2008 commented on Oct 1, 2026

8 remaining items

leacho73 commented on Oct 1, 2026

chalfontchubby commented on Oct 1, 2026

chalfontchubby commented on Oct 1, 2026

chalfontchubby commented on Oct 1, 2026

leacho73 commented on Oct 1, 2026

chalfontchubby commented on Oct 1, 2026

chalfontchubby commented on Oct 1, 2026

leacho73 commented on Oct 1, 2026

gcoan commented on Oct 1, 2026

leacho73 commented on Oct 2, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions