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
|