Comments (21)
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
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).
from ha_octopus_intelligent.
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.
from ha_octopus_intelligent.
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. 🤞
from ha_octopus_intelligent.
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
.
from ha_octopus_intelligent.
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.
from ha_octopus_intelligent.
I have the same issue. I’m on 1.6.3 but I’ve been having the issue for two weeks now.
from ha_octopus_intelligent.
”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.
from ha_octopus_intelligent.
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.
from ha_octopus_intelligent.
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.
from ha_octopus_intelligent.
@stintov Have you tried the workaround here #35 (comment) , works perfectly for me.
from ha_octopus_intelligent.
@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.
from ha_octopus_intelligent.
@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.
from ha_octopus_intelligent.
Was having the same issue but using the "Octopus Intelligent Slot" in my HA NodeRed automations. #35 (comment) has fixed it. Many thanks @matt7aylor
from ha_octopus_intelligent.
[...] How about saving the “last seen” valid
source
value in a variable, and assuming the saved value wheneversource
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 #35 (comment).
from ha_octopus_intelligent.
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
from ha_octopus_intelligent.
@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.
from ha_octopus_intelligent.
Thanks @pdcastro I have approved - hopefully I can alter the settings to allow you to unilaterally merge PRs
from ha_octopus_intelligent.
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.
from ha_octopus_intelligent.
@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.
from ha_octopus_intelligent.
[...] 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...) 😄
from ha_octopus_intelligent.
[...] 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 😁
from ha_octopus_intelligent.
Related Issues (20)
- Agile style prices, that change with the IO slots HOT 2
- IO with two accounts doesn't seem to work
- Missing sensors? HOT 4
- Can't set up inegration -
- Integration Failing Setup
- Smart Charging Enable/Disable Not Working
- Binary sensor startup failing HOT 1
- Those with Smart Charger Connected HOT 2
- Sensors missing in HA 2023.11.3 with 1.6.2 HOT 2
- await error in the logs HOT 1
- Entity "Octopus Intelligent Off-Peak End" is unknown. HOT 1
- All entities randomly, become unavailable. HOT 36
- No longer working? HOT 9
- "Intelligent Planned Dispatch Slot" is always "Off" HOT 1
- Documentation clarification
- Intelligent Octopus Slot not on when charging Outside regular hours HOT 3
- Cannot Import Name Override HOT 3
- Smart Charge Schedule
- Integration failing setup after HA update HOT 38
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ha_octopus_intelligent.