Octopus integration v17.0.0 now using device id to identify intelligent dispatches

[browellm]

A breaking change in v17.0.0 means that calling the Octopus Account Number via the apps.yaml code to interrogate dispatches information no longer works.

Intelligent device related entity ids have been changed from including the account id to including the device id. This is to support multiple EVs as well as other future intelligent devices OE might want to add in the future (e.g. Snug)

[gcoan]

can you advise what the new intelligent dispatching sensor name now is so we can change the pattern matching in apps.yaml

[browellm]

Hi Geoffrey this is an example one of the new entities binary_sensor.octopus_energy_00000000_0002_4000_8020_0000000bd147_intelligent_dispatching

[gcoan]

thanks @browellm

can you try this as the replacement regular expression in apps.yaml:

  octopus_intelligent_slot: 're:(binary_sensor.octopus_intelligent_slot|re:binary_sensor.octopus_energy_intelligent_dispatching|binary_sensor.octopus_energy([0-9a-z_]+|)_intelligent_dispatching)'

the first two regular expression options should match the previous Octopus integration entity id, the third should match what it is providing in v17.

[mpartington]

I restarted Predbat and the existing expression still matches for me

2025-10-12 19:23:52.082659: Regular expression argument octopus_intelligent_slot matched ^(binary_sensor.octopus_energy([0-9a-z_]+|)_intelligent_dispatching)$ with binary_sensor.octopus_energy_00000000_0002_4000_8020_00000008c379_intelligent_dispatching

[gcoan]

thanks @mpartington I think there are different versions of the apps.yaml config out there. certainly some people have

octopus_intelligent_slot: 're:(binary_sensor.octopus_intelligent_slot|re:binary_sensor.octopus_energy_intelligent_dispatching)'

which doesn't have the a-z 0-9 pattern matching in it

yours has which means it matches the new entity id correctly

[browellm]

thanks @browellm

can you try this as the replacement regular expression in apps.yaml:

  octopus_intelligent_slot: 're:(binary_sensor.octopus_intelligent_slot|re:binary_sensor.octopus_energy_intelligent_dispatching|binary_sensor.octopus_energy([0-9a-z_]+|)_intelligent_dispatching)'

the first two regular expression options should match the previous Octopus integration entity id, the third should match what it is providing in v17.

Applied and appears to be working. I've applied the same syntax to the new ready_time and charge_limit sensors

[gcoan]

Great

have the ready_time and charge_limit similarly changed name to include the device id?

[browellm]

Yes
select.octopus_energy_00000000_0002_4000_8020_0000000bd147_intelligent_target_time
number.octopus_energy_00000000_0002_4000_8020_0000000bd147_intelligent_charge_target

[SwiftRR]

Hi
I am lost with this!
I have not yet updated to v1.17.
The expressions that I have in my apps.yaml are as below. So each expression is linked to my Octopus Account Number.

  octopus_intelligent_slot: 're:(binary_sensor.octopus_energy([0-9a-z_]+|)_intelligent_dispatching)'
  octopus_ready_time: 're:(time.octopus_energy([0-9a-z_]+|)_intelligent_target_time)'
  octopus_charge_limit: 're:(number.octopus_energy([0-9a-z_]+|)_intelligent_charge_target)'

So my account number is being matched each time.
These expressions have always worked for me for Predbat to pick up the IOG slots and to show them in Predbat plan.

Until recent discussions, I hadn't see the first expression (which is in templates apps.yaml:

octopus_intelligent_slot: 're:(binary_sensor.octopus_intelligent_slot|re:binary_sensor.octopus_energy_intelligent_dispatching)'

I have just tried my 3 expressions in predbat log and they are all picked up showing my account number.
The version above for octopus_intelligent_slot is not picked up and does not work.

I can try updating to v1.17 but I will need to the change the expressions for apps.yaml.
And then what to??

This is a critical issue to resolve or there will be users who find that predbat is unable to recognise the new expression introduced in v17.0.0

For v17.0 the Intelligent help gives:

binary_sensor.octopus_energy_{{DEVICE_ID}}_intelligent_dispatching

What is the 'DEVICE_ID'?
I have looked for v16.0 help but this has been replaced by v17.0 help:
A guess that it was (???)

binary_sensor.octopus_energy_{{ACCOUNT_ID}}_intelligent_dispatching

As it is late, I won't risk updating to v17.0 now.
I will try tomorrow.

PS Someone who has updated was presented with this message:

So what do the repairs do? Or is this an Octopus_Energy issue?

Rob

[gcoan]

you're getting confused unnecessarily Rob, read the Octopus integration release notes.

The release notes describe what has changed, the intelligent despatching entity names have changed so they now include the device id, i.e. the id of the car, NOT the account number. This is to enable extension to multiple devices intelligently controlled in future.

Different people seem to have different versions of the apps.yaml string depending on when they installed predbat and the octopus integration.

Your entity id's have your account number in them, when you upgrade the entity id's will change to include the car device id.

This MIGHT need you to change the apps.yaml string to match the new sensor id format.

I have been trying to ascertain what has changed so I can advise people on what changes are required.

HOWEVER it looks like if you had the account id in your entity id's previously then you won't be affected as the account id and device id are the same regular expression format of a string of numbers and letters and underscores. If your entity id didn't have the account id before (and it looks like @browellm didn't) then a minor change will be needed to fix this.

And the repairs the integration reports are a different issue that will require probably require code changes to predbat as well as an apps.yaml change. But we have 6 months to do this in.

[SwiftRR]

I have updated to v17.0 and am trying to make sense of the repair 'read more' statements.
For me, The device id seems to refer to my zappi ev charger.

This is what I see in predbat.log (only after restarting predbat as @mpartington has stated):

2025-10-13 09:24:07.225183: Regular expression argument octopus_intelligent_slot matched ^(binary_sensor.octopus_energy([0-9a-z_]+|)_intelligent_dispatching)$ with binary_sensor.octopus_energy_00000000_0009_4000_8020_000000036b60_intelligent_dispatching

2025-10-13 09:24:07.226944: Regular expression argument octopus_charge_limit matched ^(number.octopus_energy([0-9a-z_]+|)_intelligent_charge_target)$ with number.octopus_energy_00000000_0009_4000_8020_000000036b60_intelligent_charge_target

However, octopus_ready_time still links to my account number as before.

Hope this helps.

PS. Do I just leave the repair 'read more' statements as they are or 'ignore' when they will go away?
Or is this where code changes to predbat and apps.yaml will be required?
I will need to read through the 'read more' sections again.

Rob

[gcoan]

So for you Rob as your regular expressions have the a-z and 0-9 bit in them, they used to match your account id, they now match the Zappi device id, so predbat has found the Octopus integration entities with the new names and everything will work OK.

The two repairs are different, they are saying that two binary sensors (for saving sessions and free electricity) are deprecated and should not be used.
The replacement solution in the octopus integration is calendar entities.
This will require a predbat code change to enact, I have already raised a predbat issue on this but there is 6 months to make the change.

You can ignore the repairs for now

[SwiftRR]

I have just looked over at bottlcapdave's Github pages and v17.0 issues are starting to appear as users are investigating the consequences go the changes. Some user automations broke and are having to be reworked.

e.g. (as of 11:48 13-10-2025)
BottlecapDave/HomeAssistant-OctopusEnergy#1514
BottlecapDave/HomeAssistant-OctopusEnergy#1515

Rob

[SwiftRR]

I am getting my head around the 'intelligent' changes in v17.0

Earlier, I found that the intelligent_slot and charge_limit expressions had picked up the device id of my zappi ev charger.
However, the target_time expression was still linked to my OE account number.

The OE integration has two alternative for referring to target_time using select and time
I noticed that @browellm earlier had referred to the select option.
My apps.yaml expression used the time alternative.
time is also recommended in the current documentation which states that select does not work.

So I have tried changing time to select in my apps.yaml and the changed expression now also links to my zappi ev charger:

2025-10-13 12:06:06.626394: Regular expression argument octopus_ready_time matched ^(select.octopus_energy([0-9a-z_]+|)_intelligent_target_time)$ with select.octopus_energy_00000000_0009_4000_8020_000000036b60_intelligent_target_time

In apps.yaml, there are also lines for the Ohme ev charger which will need to be checked by someone using this charger. (There will be many users as the Ohme ev charger appears to now be OE's default).

This does need further trialling but it looks as if the target_time expression will need to be changed in templates apps.yaml and to documentation.
This applies to users upgrading to v17.0.

I hope I have made sense and that my logic is correct.

Rob

[gcoan]

I'm updating the documentation and templates to what I believe is the correct regular expressions (based on looking at the v16 and v17) Octopus integration documentation:

  octopus_intelligent_slot: 're:(binary_sensor.octopus_energy([0-9a-z_]+|)_intelligent_dispatching)'
  octopus_ready_time: 're:((select|time).octopus_energy_([0-9a-z_]+|)_intelligent_target_time)'
  octopus_charge_limit: 're:(number.octopus_energy([0-9a-z_]+|)_intelligent_charge_target)'

These will work regardless of whether you are using v16 (which has account id) or v17 (device id).

The OE integration has two alternative for referring to target_time using select and time
I noticed that @browellm earlier had referred to the select option.
My apps.yaml expression used the time alternative.
time is also recommended in the current documentation which states that select does not work.

The regular expression above will work with either select.octopus_energy_XXX_intelligent_target_time or time.octopus.....

The select is to 30 minute granularity, the time is to minute granularity and it looks like you can use either, but are recommended to disable the other one you are not using as they can get out of step. Also time.xxxx is disabled by default (and appears as if it doesn't render properly in the Octopus app), so I think we need to be able to support both