v9.2.0-Beta 1

[BottlecapDave]

This beta release introduces a new way that data is retrieved. Taken from the FAQ

---

Based on a request from Octopus Energy, the integration polls and retrieves data at different intervals depending on the target data. Below is a rough table describing how often the integration targets refreshing various bits of data. This has been done to try and not overload the API while also providing useful data in a timely fashion.

Area	Refresh rate (in minutes)	Notes
Account	30	This shouldn't change often so no need to poll often. This is used to get active tariffs
Intelligent tariff based sensors	5	Trying to balance refreshing settings and new dispatch information without overloading the API
Rate information	15	This is what drives most people's automations, but doesn't change that frequently
Current consumption data	Configurable (minimum 1)	This is most useful for a smart home to be as up-to-date as possible, but at the same time we don't want to flood the API with requests
Previous consumption data	30	This doesn't change frequently, so no need to request too often.
Standing charges	30	This should only change if the user's tariff changes, so no need to request data too often.
Saving sessions	15	Inactive for most of the year and new sessions have enough warning
Wheel of fortune	30	Doesn't change that frequently, so no need to request too often.

If data cannot be refreshed for any reason (e.g. no internet or APIs are down), then the integration will attempt to retrieve data as soon as possible, slowly taking longer with each attempt. Below is a rough example assuming the first (failed) scheduled refresh was at 10:35.

Attempt	Target time
1	10:35
2	10:36
3	10:38
4	10:41
5	10:45

---

This discussion was created from the release v9.2.0-Beta 1.

[JRascagneres]

Hey Dave. I'm running this version of the integration as the old one isn't pulling my agile rates. I still have the issue with this new integration version and getting the following lines:

I'm running agile import and fixed export.

[BottlecapDave]

Hello. This is part of the fallback (as per the FAQ) which is raised when the API cannot be connected for some reason and will automatically retry steadily waiting longer. If you're not seeing any other accompanying warnings (e.g. Octopus Energy server error or Failed to send request), the most likely scenario is timeouts when attempting to connect to the API. These are set to 15 seconds (which should be more than enough for an API call). This could be caused by the API being slow to respond (due to overwhelming demand and scaling issues), internet issues on your side or something else.

I'm currently adding some additional logging around timeouts and raised issues.

Unfortunately these changes alone won't necessarily help until the majority of users are using this version of the integration.

[JRascagneres]

I'm not seeing any other errors or warnings so I'm struggling to see what's happening. But yeah might be nice to have additional logging around it. Print HTTP status codes etc.
That's the reason I posted the message mostly there was nothing else giving me indication into what was wrong.

[BottlecapDave]

I've noticed some of their APIs are a bit broken. For instance consumption data on my account can't currently be filtered but is present without filters. Which specific tariff are you on?

[JRascagneres]

Looks like it just managed to pull the data but it's "AGILE-FLEX-22-11-25"

[borpin]

Do you offset the times at all? Most systems have very accurate clocks so even if you adjust the gap between the retries, everyone will retry pretty much at the same time.

I suggest you need to try and spread it out a bit from the minute boundary. Perhaps use the seconds field from the last system or integration start time and offset the main attempts or the retries by that or add in a random (pseudo) number of seconds/milliseconds. This would then spread all the requests out over a minute at all the boundaries.

Just a thought.

[BottlecapDave]

The refreshes are not on the minute. This is handled two fold

1. The initial start time is based on when the integration first starts (including seconds) so this reduces the chances of "everyone" trying at the same time as everyone won't be reloading/starting the integration at the same time.

2. HA already adds some jitter to when the coordinators/entities are updated otherwise all entities across your HA instance would grind to a hault.

[BottlecapDave]

New beta release has been...released. This includes some additional logging for failures which are now reported as warnings.

[subby28]

Dave - just a query about how the new polling intervals work in practice. If using the saving session binary sensor to control inverters etc like i am, does this mean there could be a 15 minute delay from the start of the saving session before the sensor changes to on?

[BottlecapDave]

These changes are purley for the retrieval of the data. The sensors should continue evaluating their state every minute as they do today.

[subby28]

Ah, just me not understanding the wording correctly then haha. Thanks for clarifying.

[WowHesTall]

Appreciate the release Dave, I'm still hitting my head against a brick wall with the Octopus API being painfully slow to respond. If I query the API in console, we're looking at 45s for the first page to return. Nothing wrong with my internet connection 😵‍💫

[BottlecapDave]

@WowHesTall I know there have been issues reported in the last few days around slow responses. Unfortunately, I'm not associated with OE so if you're having API issues you'll need to contact them.