Intelligent Dispatching does not turn on if planned dispatches span 11am

[andynash]

Describe the bug

I've realised that if planned dispatches span 11am, the Intelligent Dispatching binary sensor does not turn on, even though planned dispatches correctly records the updated dispatches from Octopus.

For example, let's say it's 8.15am (in case it is relevant, we use the car integration, not charger).

Let's also assume the current SOC is very low, that we have just been informed (not unusual in our case) we need to make a long journey at 7pm, and note that we use a 2.3kW 3-pin charger (this issue may not have been noticed by others, as I imagine most use 7.2kW chargers and/or start their journeys in the morning before 11am, and predictably).

If we request a charge to complete by 11am, we might be given some slots from (say) 8.15am to 11am, the Intelligent Dispatching sensor turns on, and all is fine.

However we are leaving at 7pm and require more charging than that.

We cannot request a time earlier than 4am, so that is what we select. Octopus then often provide planned dispatch slots between (say) 8.15am and 4am and these are correctly received by the integration. These often start before 11am and end after 11am.

In this case, the binary sensor does not turn on, even though we are currently within a planned dspatch.

I've not been able to work out whether it matters if for example there's a dispatch which completes before 11am and another that starts after 11am, or whether an individual dispatch starts before 11am and ends after 11am, as the dispatches we've received and I've observed have always included an individual dispatch that starts before 11am and finished after 11am.

If we wait until after 11am to select 4am amd receive planned dispatches (that therefore do not span 11am), the sensor then correctly turns on during the planned dispatches.

Reproduction steps

Request (and receive) planned dispatches that span 11am.

Expected behaviour

Intelligent Dispatching turns on as usual during the received planned dispatches.

Tariff Code

E-1R-INTELLI-VAR-22-10-14-M

Integration Version

10.3.1

Home Assistant Version

2024.4.4

Fresh Install?

Not specified

Home Assistant Logs

Will try and obtain logs during the period the planned dispatches are received from Octopus

Confirmation

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

[andynash]

I've captured logs using the enable debug logging in the integration settings while new dispatches spanning 11am were received, but the resultant file is a .bin so I can't view the file or paste the contents here (as binary not sure they'd not be useful anyway?).

I can send if required though?

Incidentally, prior to changing the time to 4am, it had been 11am and a dispatch was in progress, therefore dispatching was turned on. As expected, when the new dispatches were received, including a dispatch from the current time (c. 9.30am) to beyond 11am, dispatching turned off even though it should have remained on.

[BottlecapDave]

Hello sorry you're having issues with the sensor.

The dispatching sensor turns on whenever you're within a rate that is either off peak or has is_intelligent_adjusted set to true. The latter should occur when you're with a supported provider (e.g. not ohme) and you have pending or completed dispatch that starts/ends or covers a rate outside of an off peak rate. For example

• 08:00 - 08:30
• 08:30 - 09:00
• 09:00 - 09:30
• 09:30 - 10:00

these will all have is_intelligent_adjusted set to true and adjusted to an off peak rate if for example a pending or completed dispatch is say from 08:01 to 09:59.

There have been sporadic reports where a pending dispatch is removed before it's finished but not turned into a completed dispatch which would cause the sensor to turn off early.

It would be interesting to know what the rates state in the event entity during the problematic period both before, during and after the dispatch event as well as the pending and completed dispatches in the sensor.

[andynash]

Thanks Dave!

I don't think we are looking at the scenario where pending dispatches are removed as they are definitely present as expected.

I'll have to wait until a morning when I can observe is_intelligent_adjusted and let you know 👍

[andynash]

I didn't quite make it in time to check this properly today, though I can confirm that is_intelligent_adjusted is set appropriately when planned dispatches either finish before 11am and begin after 11am.

I've realised I have a sensor tracking is_intelligent_adjusted, and this was off yesterday during a period covered I believe by planned dispatches that did span 11am, however I'd like to be able to see all these sensors live during such a period to be 100% sure.

It may take a few days to have an opportunity to check this properly as the car is going away tonight for a night, maybe longer.

Out of curiosity, I'm not sure whether is_intelligent_adjusted comes directly from the Octopus API (even if renamed) or if it is derived by the integration from other data?

[BottlecapDave]

Out of curiosity, I'm not sure whether is_intelligent_adjusted comes directly from the Octopus API (even if renamed) or if it is derived by the integration from other data?

The is_intelligent_adjusted field is calculated by the integration. This is true if an available planned or completed dispatch spans (completely or partially) a given 30 minute rate period. This is because OE API only provides the core rates, not accounting for planned or completed dispatches.

No rush on the findings as I probably won't have much time to look at it within the next week.

[andynash]

I can confirm that when this is happening, is_intelligent_adjusted is true, while intelligent_dispatching is false.

It is now just after 6am, with the Intelligent ready time set to 4am. Planned dispatches have been provided by Octopus and are recorded in the dispatching sensor so dispatching should be turned on. The current planned dispatch has started and ends at 4am tomorrow morning (I wonder if the tomorrow part might be where the bug lies? But of course I can't test that as the ready time cannot be set after 11am and earlier than 4am).

When I change the ready time to 11am or earlier, dispatching turns on correctly (and of course ends at 11am).

[BottlecapDave]

The current planned dispatch has started and ends at 4am tomorrow morning (I wonder if the tomorrow part might be where the bug lies? But of course I can't test that as the ready time cannot be set after 11am and earlier than 4am).

This might be where it lies. Sorry to be a pain, but any chance you could post the full list of rates (today and tomorrow) if possible. It can be from the energy card if you use that if it indicates which rates are marked as intelligent dispatch.

[andynash]

No problem at all, I'll try and grab those tomorrow morning 👍

Sorry I've realised I was focused on the adjusted variable, but you did ask for the rates before 🤦

[andynash]

Hi Dave, I've attached screenshots of the data you asked for below - as far as I can see everything looks as it should except the Intelligent Dispatching binary sensor, but you may spot something I've missed!

As a reminder, it works fine if the planned dispatches end before or at 11am, and if they start after 11am, but if they start before 11am and end after 11am, that's where the problem occurs.

Thanks for your help with this 👍

Planned Dispatches

Current Rate Attributes

Current Rates

[andynash]

Ps. Nothing to do with this bug (at least I don't I think so), but I can't for the life of me work out why the rate changed to 7.5 between 8am and 9am. Overnight and beyond this time, the time was set to 4am and the charge to 100% (as that is what it had been set to the previous day), so the previous adjusted rate will have run up to 11.30pm yesterday, the standard Intelligent slot will then have run to 5.30am, and this seems to have happened as expected.

Normally in this scenario, I would expect the standard rate to take over from 5.30am, and continue at least until the next time the car is plugged in (or we update the 4am/100%). so 8am to 9am is not as expected - perhaps Octopus felt that the car had disconnected then reconnected, but if so, that doesn't explain why it would then stop at 9am.

Then at 10.13am I adjusted the 100% to 10% and back to 100% to trigger Octopus to send planned dispatches that would span 11am, so that I could create these screenshots, so from 10am onwards the rate is as expected (given the planned dispatch they provided).

[BottlecapDave]

I think I found an issue which might be causing this, but I'm having trouble replicated what you're seeing locally. Could you please try v11.0.0 to see if this fixes your issue?

Also is a full pending dispatch normal with your provider? Is this useful? Should this be following the ohme model and not be reported?

[github-actions[bot]]

This issue has become stale because it has been open for 30 days with no activity. If you still think it's an issue, please respond soon.

[andynash]

Hi Dave, sorry, a combination of being busy, and this situation not arising as much over the last few weeks for holiday and other reasons (though it will again) has meant I haven't had the opportunity to test.

Yes, these sorts of pending dispatches are perfectly normal (given the right conditions, ir battery SoC low enough, plugged in, correct settings for charge and departure time). At least for us they are not that unusual, partly as we charge using a 3-pin plug - as the car does long journeys but also spends long periods at home, and we have solar, this works fine for us.

I'm afraid I don't understand the second question as I'm not sure what the 'Ohme model' means?

As soon as I can I'll try and test the scenario again 👍

[BottlecapDave]

No problem. Ohme is a brand of charger which when used provides a large number of pending dispatches but only a subset are determined and used by the charger instead of the usual where OE tells the charger when to charge. This results in this data being not very useful as people could charge other things during periods that are ultimately not charged at off peak rates. For this type of charger, the pending dispatches are not exposed by this integration.