Intelligent dispatching not matching schedule in Octopus App

[chrislewishome]

Describe the bug

Hi,

Want to know if this is expected or not, the smart dispatching seems to be coming on an hour before when the schedule actually is.

Reproduction steps

Plug car in and the intelligent dispatch comes on an hour before the expected start time.

Expected behaviour

The times match.

Tariff Code

20L3053095

Integration Version

16.3.1

Home Assistant Version

2025.9.3

Fresh Install?

Not specified

Home Assistant Logs

N/a

Confirmation

• I confirm that I cannot find my solution within the documentation
• I confirm that I cannot find my solution within the FAQ

[stevedundee2]

I'm seeing discrepancies too. This afternoon the IOG charging slots on their app seemed to keep changing last minute, but over on home assistant these slots stayed as "intelligent on" for the duration ie not just a few minutes delay before everything caught up.

[stevedundee2]

I don't know how to find out whether:

• HA is successfully getting bad information from the Octopus API (i.e. an Octopus bug)
• or the information is good and Octopus are giving the slot as cheap energy even though it no longer appears in their charging plan (e.g. because they changed their minds so last minute that the the half hour slot had already started)
• or HA is failing to get the updates from Octopus (I think not because associated details like when the car is currently planned to charge are updating fine)
• or this is a bug in this integration

[mrdavewiltshire]

I'm having a similar issue.

My Ohme Charger is recieving am IOG schedule, and the car is charging, but my intelling dispatching toggle never switches (except for the standard overnight off peak times)

[BottlecapDave]

Hello and sorry that you're having issues. Theres a few reasons why this might have occurred.

1. The integration has to poll to get data. This is limited to every 3 minutes to keep in OEs good books. When the integration was first created, OE didn't use to change the schedule with such little notice, which is why this polling is starting to fail when OE changes it at the last minute. This means the integration thinks there's a valid schedule up until it next polls and then realises the schedule is no longer valid, which can result in the dispatch turning on incorrectly for the period
2. The integration moves a planned dispatch into a started dispatch (integration concept) once a planned dispatch has started. Once a started dispatch has been created, it's "locked in" and is used for correcting prices to the off peak rate. This means that a planned dispatch can be incorrectly locked if the planned dispatch changes but starts before the next polling. This was done like this because if I waited for the next polling it meant the dispatch sensor could be turned on up to 3 minutes after the start. Completed dispatches can't be used because they don't state the reason of the dispatch which means boost charges were incorrectly being calculated at off peak rate.
3. Dispatch sensor is linked to off peak rates and basically turns on when off peak (either standard or due to dispatch time). This was done to keep logic central and try and reduce inconsistent bugs. In your scenario, a planned dispatch might have originally been due at 19:30 and then changed at the last minute but the polling occurred after it originally started. The only true way of knowing this would be investigating the attributes via the underlying SQL at the time when it came on.

These reasons are why the docs recommend you to not rely solely on the dispatch sensor if possible and also take into account if your vehicle is charging via other integrations.

As part of supporting multiple intelligent devices, some of this logic will be changing.

1. The dispatch sensor will not look at rates but the dispatches themselves. Theres already a config option that determines if dispatches should look at planned and started dispatches (optimistic that all planned dispatches will turn into active dispatches) or just started dispatches (pesimistic which might cause delays in the dispatch sensor turning on). If the former then when any planned or started dispatch is active, it will turn the sensor on. If pesimistic, only when a started dispatch is active will it turn on. This config will continue to have a baring on if the rate sensors are also optimistic or pesimistic.
2. Planned dispatches will only turn into started dispatches if the planned dispatch is active and it's just polled the data. This means hopefully the started dispatches should be more accurate. Of course, there's a small chance that a dispatch doesn't turn into a started dispatch if for whatever reason the data cant be polled or if it starts and ends at the end within the polling interval. This will mean that depending on your config option, you might have the dispatch sensor turn on when a planned dispatch becomes active, but then turns off when it's removed and not turned into a started dispatch.

The limitations of the API and what OE provide is unfortunately the result of this sensor being a "best guess". Theres an ongoing discussion in the forums around the effectiveness of these short notice changes. It might be OEs way of trying to stop people gaining the system and using the off peak rates to do other things.

@mrdavewiltshire This is unfortunately by design, Ohme doesn't provide the dispatch information in a way that is usable. OE sends a load of planned dispatches to Ohme and ohme then choose which ones it wants to pick. There have been discussions in the forums on whether this has changed, but I've yet to get more feedback.

[chrislewishome]

@BottlecapDave does that apply to my problem? The app and HA are exactly 1 hour out every time. Also the unit rate shows the slot is £0.07 an hour out as well.

[BottlecapDave]

I just use the data retrieved from the API and the time on your HA instance to work out if it's active. What does the attributes of the sensor state are your planned/started/completed dispatches. Is your HA instance set to the correct timezone?