Intelligent planned dispatch slot not turning on

[vansteedens]

I utilise the planned dispatch slot to trigger automations and stop my house batteries from draining. Recently, I've noticed that the slot is never turning on, instead it goes from off to unknown and then unknown to off. This means that my battery automations aren't correctly firing and updating the discharge settings. I can't use the 'any state' option either because unknown doesn't necessarily mean it's in a dispatch slot. The only time any state is useful is when turning off the automation, however this then fires at random times in the day when the service becomes unavailable. You can see the last few days examples in the screenshot. The car was charging between 23:00 - 07:30 with a few 30 slots of stopping.

[pdcastro]

Are you running version 1.6.3 released two weeks ago? Since I updated to that release, stability improved significantly. I still see occasional ~5min unavailable gaps as in your screenshot, but I see ‘turned on’ slots too:

I am currently running the latest HASS version 2024.2.1, and for the past week or so I was running HASS version 2024.1.6.

[vansteedens]

I'm running the same versions as you so not sure what's going on and why it's not changed to on for a while. I've changed my automations over to the Bottlecapdave version for now as the dispatching sensor on there seems to have recorded all my recent sessions.

[matt7aylor]

Hi, I have been having the same issue (running latest v1.6.3). After a little digging I believe have found what is causing the problem for me and a temporary workaround. (I need the workaround as I rely on the planned dispatch slot to automate turning on the car charger to actually charge the car.) However, I think the problem might lie in the Octopus API, unfortunately (if we can confirm this does anyone know how we can report it?).

It seems that the plannedDispatches metadata returned by the API changes after the schedule is updated (by Octopus). Once the charge schedule first appears, for each entry in plannedDispatches the metadata will look like {'meta': {'source': 'smart-charge', ...}}, which is the expected behaviour and the planned dispatch slot entity will work if the schedule is not changed before it begins (sometimes I would get working dispatches in the morning after fiddling with the settings). However, it seems that the schedule often gets altered after it is set the first time and then the metadata seems to change instead to {'meta': {'source': None, ...}}. This causes the planned dispatch slot to not register in the integration.

A workaround that allows me to still charge the car in the dispatch slot is to change the line https://github.com/megakid/ha_octopus_intelligent/blob/9f45e5987abdee6ddf6d1c190a61f14b7e20e513/custom_components/octopus_intelligent/octopus_intelligent_system.py#L126

to:

    if source is None or state.get('meta', {}).get('source', '') in [source, None]:  # HACK workaround empty meta

This works for me since I don't use the "bump charge" feature but this may not be a good permanent solution if it potentially results in other dispatches(?) being shown in the planned dispatch slot. The bigger problem would be how to fix the intelligent offpeak sensor to allow for this as the equivalent of the above change might not discriminate between a smart charge that had lost it's metadata and a bump charge that had lost it's metadata (if such a thing happens).

[stintov]

I have the same issue. I’m on 1.6.3 but I’ve been having the issue for two weeks now.

[pdcastro]

”However, it seems that the schedule often gets altered after it is set the first time and then the metadata seems to change instead to {'meta': {'source': None, ...}}.”

Great findings @matt7aylor! 👍 Given your explanation that the metadata source is initially valid ('smart-charge' or 'bump-charge') but then becomes None, how about saving the “last seen” valid source value in a variable, and assuming the saved value whenever source is None in the metadata? I assume that planned dispatches cannot simultaneously be ‘smart’ and ‘bump’, so the last seen source (other than None) is the correct one.

[matt7aylor]

The problem I think is that the metadata is lost when the plannedDispatches changes so where before you might have had a dispatch e.g. from 01:00 to 01:30 with smart-charge, now you might have one 04:30 to 05:00 with None. I'm not sure how reliable it will be to remember them and try to guess metadata for the new ones, because maybe the new one is not actually a smart-charge.

[stintov]

Any update on this please? I’ve found that running the automation manually works.

I believe that as only started after applying the last 1.6.3 integration.

[matt7aylor]

@stintov Have you tried the workaround here https://github.com/megakid/ha_octopus_intelligent/issues/35#issuecomment-1949942197 , works perfectly for me.

[stintov]

@stintov Have you tried the workaround here #35 (comment) , works perfectly for me.

Thanks @matt7aylor, I will put my big boys pants on and try and alter the code. I can't say I know what I'm doing here :). Was hoping the dev would write a fix for us.

[stintov]

@stintov Have you tried the workaround here #35 (comment) , works perfectly for me.

Lets see if this works now. Great work if this fixes it.

[davebarrett1959]

Was having the same issue but using the "Octopus Intelligent Slot" in my HA NodeRed automations. https://github.com/megakid/ha_octopus_intelligent/issues/35#issuecomment-1949942197 has fixed it. Many thanks @matt7aylor

[pdcastro]

[...] How about saving the “last seen” valid source value in a variable, and assuming the saved value whenever source is None in the metadata?

[...] I'm not sure how reliable it will be to remember them and try to guess metadata for the new ones, because maybe the new one is not actually a smart-charge.

With two weeks of testing, I have found the “last seen valid source” approach to be effective in practice and I submitted PR #37 for it. Empirically, so far it has held true that when the source changes from smart-charge to bump-charge or vice-versa, then at least one non-None value appears in the metadata with the integration's 5-minute polling interval. If Home Assistant is down for maintenance for a longer period of time and bump charging is started or stopped before the integration gets to poll the API again, then there is a chance that this solution would mistake smart charging for bump charging, but even then it would fix itself as soon as the Octopus API returned the first non-None source value. And if one only ever cared about smart charging, then the “last seen valid source” solution always gets it right, so it is at least as effective as the hot patch in https://github.com/megakid/ha_octopus_intelligent/issues/35#issuecomment-1949942197.

[megakid]

Hey @pdcastro thanks so much for all the activity here. Would you like to become a maintainer so you can do merges? I'm not able to dedicate the time I'd like to this

[pdcastro]

@megakid, thanks for the invite. I wrote to you at the email address in your public GitHub profile. Could my emails be ending up in your spam folder? Even after accepting your GitHub invite, merging the PRs still requires the approval of a reviewer with write permissions, other than the PR author.

[megakid]

Thanks @pdcastro I have approved - hopefully I can alter the settings to allow you to unilaterally merge PRs

[pdcastro]

GitHub automatically closed this issue because of the ‘fix’ verb used in the message of a commit that was merged to the main branch, however a tagged release hasn’t been created yet. Reopening this issue until the release is created.

[pdcastro]

@megakid, I’ve created a draft release v1.7.0: https://github.com/megakid/ha_octopus_intelligent/releases/tag/untagged-4635435e5eda7b2b65f4

Let me know if you’d like to make any changes before it is published. I considered whether the new release tag should be v2.0.0 or v1.7.0 under semver, because this release drops support for Python 3.10 or older (because of the use of asyncio.timeout() introduced in Python 3.11), aligning with Home Assistant 2023.8.0 or later that also requires Python 3.11 or later.

There does not seem to be a consensus on whether dropping support for a “minor” version of Python (e.g. 3.10 vs. 3.11) should be a breaking change for a Python project, warranting a major semver version bump. On the one hand, any users of this integration who were using an old version of Home Assistant with Python 3.10 or older would find that upgrading the integration breaks it, and in this regard it would make sense to for the new tag to be v2.0.0 rather than v1.7.0. On the other hand, some argue that requiring a new minor version of Python should only require a new minor version for Python projects. Importantly, this release is not a breaking change in relation to its “public API:” sensors, switches, etc. Users do not need to make any changes to their automations or scripts in order to use the new release. Bumping the version to v2.0.0 might falsely give users the impression that they’d need to update their automations or scripts, and this is why I am currently inclined to use the v1.7.0 tag.

[hammerhead2000]

Personally I think 1.7.0 is fine, I think users expect significant new features if you change from 1.x to 2.x.

Thank you for fixing this, I was about to start digging through the code myself as this problem is breaking my AppDaemon automations! I would happily pull this as a beta release to give you some extra testing if that would be helpful.

[pdcastro]

Thanks @hammerhead2000 and @stintov 👍 I went ahead and published release v1.7.0. It’s already available for installation through HACS (custom repositories) as well. Hopefully it sufficiently solves this issue. 🤞

[pdcastro]

[...] changed my automations over to the Bottlecapdave version for now as the dispatching sensor on there seems to have recorded all my recent sessions.

On this note, I’ve been running Bottlecapdave’s integration with debug logging out of interest, as I wanted to see if somehow it was immune to this issue that we believe to be an issue with Octopus’ API. Today I saw the issue happening to me with Bottlecapdave’s integration:

2024-03-20 00:01:05.606 DEBUG (MainThread) [custom_components.octopus_energy.api_client] async_get_intelligent_dispatches: {'data': {
    'plannedDispatches': [{
        'startDt': '2024-03-20 00:00:00+00:00',
        ...
        'meta': {'source': None, 'location': None}
    }], ...

So there we go: This issue affects Bottlecapdave’s integration as well, and right now megakid’s integration is thus more reliable. (Well, apart from #43, but #44 is already awaiting to be released as 1.7.1...) 😄

[vansteedens]

[...] changed my automations over to the Bottlecapdave version for now as the dispatching sensor on there seems to have recorded all my recent sessions.

On this note, I’ve been running Bottlecapdave’s integration with debug logging out of interest, as I wanted to see if somehow it was immune to this issue that we believe to be an issue with Octopus’ API. Today I saw the issue happening to me with Bottlecapdave’s integration:

2024-03-20 00:01:05.606 DEBUG (MainThread) [custom_components.octopus_energy.api_client] async_get_intelligent_dispatches: {'data': {
    'plannedDispatches': [{
        'startDt': '2024-03-20 00:00:00+00:00',
        ...
        'meta': {'source': None, 'location': None}
    }], ...

So there we go: This issue affects Bottlecapdave’s integration as well, and right now megakid’s integration is thus more reliable. (Well, apart from #43, but #44 is already awaiting to be released as 1.7.1...) 😄

Awesome, I switched back once you said it was fixed and going to do another charge tonight so hopefully all my automations work as expected 😁