Skip to content

IOG - Octoplus plan is still taken into account in Predbat plan after Smart Control is switched off #5339

Open
#5341
Open
IOG - Octoplus plan is still taken into account in Predbat plan after Smart Control is switched off#5339
#5341
Assignees
springfall2008
Labels
BOT_TRIAGEDHas been through the triage botOctopusRoot CausedbugSomething isn't workingfixed

Description

@PianSom
PianSom
opened on Oct 1, 2026

Describe the bug
I am an IOG user. I switch between Octopus-led EV charging (where octopus controls the EV charger and I have the possibility of bonus slots) and Predbat-led (where Smart Control is switched off, so there are no bonus slots, and Predbat determines EV charging). This has worked well until recently.

Now if I plug m EV in and the system is in Octopus-led mode then Octopus will generate a charging plan and publish it to the intelligent_dispatching binary_sensor. Predbat will then generate a plan assuming that plan (including any bonus slots) will take effect.

If I subsequently move to Predbat-led then - although the binary_sensor does not change - there are no longer bonus slots available to use in the future. However Predbat seems to think these cheap slots will appear and plans accordingly.

Expected behaviour
Predbat should ignore future Octopus charging slots if Smart Control is turned off. (I recognise that this may be a bottlecapdave issue; if so, let me know.)

Predbat version
Currently v9.3.3

Environment details
AIO1x2+GW
Docker Predbat

Screenshots
n/a

Log file
Let me know if required

Predbat debug yaml file
As above

Activity

  1. PianSom
    assigned
    springfall2008
    on Oct 1, 2026
  2. PianSom
    changed the title [-]IOG - Ocoplus plan is still taken into account in Predbat plan after Smart Control is switched off[/-] [+]IOG - Octoplus plan is still taken into account in Predbat plan after Smart Control is switched off[/+] on Oct 1, 2026
  3. springfall2008
    added
    bugSomething isn't working
    waiting_for_user
    Octopus
    on Oct 1, 2026

  4. springfall2008 commented on Oct 1, 2026

    @springfall2008
    springfall2008
    on Oct 1, 2026
    Owner

    This is an automated first-pass triage — a maintainer will review before any action is taken.

    This is being handled as a bug report on first pass, but detailed triage is on hold until the evidence files below are attached. From the description I can't tell what Predbat was reading when the plan was made (its Octopus Intelligent config, which dispatch/planned-slot entities were set to what, and what the resulting plan looked like), so analysing the code without it would just produce a guess.

    Please attach:

    • A predbat_debug.yaml and a predbat.log, both captured while the problem is present — i.e. after switching over to Predbat-led, at a point where Predbat's plan still shows those cheap charging windows that will no longer happen. 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 handy, the state/attributes of the relevant Octopus integration entities around the same time (e.g. the intelligent_dispatching binary_sensor and any planned-dispatch/plan attributes), since the report is specifically about those. A screenshot or a text export is fine.

    Since I see you can switch modes freely, reproducing the state as described above and grabbing both files then is the most useful thing.

    Background on the debug snapshot: debug history docs.

    Once the files are here the ticket gets a full re-review automatically.

  5. springfall2008
    added
    BOT_TRIAGEDHas been through the triage bot
    on Oct 1, 2026
  6. chalfontchubby
    removed
    waiting_for_user
    on Oct 1, 2026

  7. chalfontchubby commented on Oct 1, 2026

    @chalfontchubby
    chalfontchubby
    on Oct 1, 2026
    Collaborator

    Posted by Claude on behalf of @chalfontchubby.

    No logs needed after all - we've reproduced this and found the cause.

    In plain terms: when you switch Smart Control off, Octopus keeps handing back the charging plan it had already made (including any bonus slots), and the Octopus Energy integration passes that straight on to Predbat. Predbat doesn't currently look at whether Smart Control is on, so it carries on treating those slots as real and cheap. This is a Predbat gap rather than a bug in the integration - it is faithfully relaying what Octopus returns. We are working on a fix: when Smart Control is off, Predbat will ignore the planned slots (slots that have already been delivered will still count).

    Detail

    Reproduced against the Octopus GraphQL API on a live Intelligent account with an EV:

    State isSuspended currentState flexPlannedDispatches
    Smart Control on, plan made false SMART_CONTROL_IN_PROGRESS 2 SMART dispatches
    Smart Control switched off true SMART_CONTROL_OFF same 2 dispatches, unchanged

    So Octopus does not withdraw the plan on suspend.

    • HA integration path (octopus_intelligent_slot pointing at binary_sensor.octopus_energy_<device_id>_intelligent_dispatching): the integration publishes planned_dispatches without looking at suspended state. Smart Control is exposed separately as switch.octopus_energy_<device_id>_intelligent_smart_charge (on = not suspended). Predbat merges the planned_dispatches attribute into its slots in fetch.py and never reads that switch.
    • Built-in Octopus API component: it polls isSuspended, but only uses it to drop the device from the active car list; the suspended device's planned dispatches are still published on its intelligent_dispatch sensor.

    Planned fix: an optional octopus_intelligent_smart_control apps.yaml entry (the Smart Control switch, one per car), filled in automatically by the built-in component. While it reads off, planned dispatches are skipped and completed ones are kept. The built-in component's own sensor will likewise stop publishing planned dispatches for a suspended device.

  8. chalfontchubby
    added
    Root Caused
    on Oct 1, 2026

  9. chalfontchubby commented on Oct 1, 2026

    @chalfontchubby
    chalfontchubby
    on Oct 1, 2026
    Collaborator

    Posted by Claude on behalf of @chalfontchubby.

    A fix is up as a draft PR: #5341. While Smart Control is off, Predbat now ignores the car's planned Octopus slots (including bonus slots), and keeps slots already delivered. If you use the Octopus Energy integration there is nothing to configure: Predbat finds the integration's Smart Control switch from the intelligent_dispatching sensor name.

    Correction to my comment above: I said the built-in Octopus API component would also be changed. Having read its automatic_config(), it already stops wiring a suspended device's slots into Predbat, so the PR only changes the integration path, and the fix applies to anyone using the Octopus Energy integration.

  10. chalfontchubby
    added
    fixed
    on Oct 1, 2026

  11. PianSom commented on Oct 2, 2026

    @PianSom
    PianSom
    on Oct 2, 2026
    Author

    Planned fix: an optional octopus_intelligent_smart_control apps.yaml entry (the Smart Control switch, one per car), filled in automatically by the built-in component. While it reads off, planned dispatches are skipped and completed ones are kept. The built-in component's own sensor will likewise stop publishing planned dispatches for a suspended device.

    Can I just check - if the new switch is put in apps.yaml and is set to eg on, but I then (programatically through an automation call to the Octopus api) turn off Smart Control then will Predbat pick up this change and ignore the apps.yaml setting?

    I had (naively?) thought a Config switch may be better than an apps.yaml switch.

  12. gcoan commented on Oct 2, 2026

    @gcoan
    gcoan
    on Oct 2, 2026
    Collaborator

    I had (naively?) thought a Config switch may be better than an apps.yaml switch.

    Apps.yaml is cleaner because HA controls would have to be one per car which bloats HA.

    Question whether this needs to be configurable though ? If smart charging off in HA then shouldn't predbat ignore the slots as the octopus component does ?

  13. chalfontchubby
    added a commit that references this issue on Oct 2, 2026

    fix(octopus): take the Smart Control switch from apps.yaml, not a har…

    5edfa25

  14. 5 remaining items

  15. chalfontchubby
    added 15 commits that reference this issue on Oct 6, 2026

    fix(octopus): ignore planned Intelligent dispatches while Smart Contr…

    fc9720b

    fix(octopus): address review of the Smart Control change (#5339)

    7555d0d

    fix(octopus): keep manual bump/boost dispatches while Smart Control i…

    0e31b83

    refactor(octopus): share the manual dispatch sources, keep the raw pl…

    0d5fb90

    fix(octopus): take the Smart Control switch from apps.yaml, not a har…

    6a45aca

    chore(coverage): list octopus_intelligent_smart_control in the test a…

    cbc0cd1

    feat(octopus): publish a writable Smart Control switch from the built…

    90477aa

    fix(octopus): harden the Smart Control switch after review (#5339)

    e8bd2f9

    fix(octopus): keep a charger's planned slots from octopus_intelligent…

    f55c289

    fix(octopus): cost a charger's planned slots at the normal rate while…

    33fe309

    fix(octopus): cost a charger's finished slots like its planned ones w…

    6aa6764

    fix(octopus): keep a held half hour while Smart Control is off and a …

    1d916cc

    fix(charger): don't follow planned Octopus dispatches while Smart Con…

    0ba4b93

    fix(octopus): a held half hour no longer trims a charger's running sl…

    1154ee8

    docs(charger): say a driven charger follows the dispatch sensor only …

    6134103
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

BOT_TRIAGEDHas been through the triage botOctopusRoot CausedbugSomething isn't workingfixed

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions