Off peak sensor stopped updating 3 days ago

[blacknell]

Describe the bug

My offpeak sensor has stopped updating (since 18 February 5 days ago). This also true of my current electricity rate sensor which is stuck at peak rate.

binary_sensor.octopus_energy_electricity_REDACTED_off_peak

I don't know why this is happening but online at Octopus I'm still getting billed correctly.

The only thing I did a few days ago (can't recall the date) was I noticed that I had dispatches set to automatic refresh when my automations call the refresh action manually. I had noticed rate limiting errors in my logs (similar to 6 months ago in #1369). I switched off Enable polling for changes in system options

Reproduction steps

It's constantly like this so I can't specifically reproduce it.

Expected behaviour

Should update regularly

Tariff Code

E-1R-INTELLI-VAR-24-10-29-H

Integration Version

18.0

Home Assistant Version

2026.2.1

Fresh Install?

Not specified

Home Assistant Logs

2026-02-23 04:00:30.314 ERROR (MainThread) [homeassistant.components.automation.ev_refresh_intelligent_dispatches] Refresh Octopus Intelligent Dispatches: Error executing script. Error for call_service at pos 2: Maximum requests of 20/hour reached. Will reset after 2026-02-23 04:00:30.315678+00:00
2026-02-23 05:03:30.313 ERROR (MainThread) [homeassistant.components.automation.ev_refresh_intelligent_dispatches] Refresh Octopus Intelligent Dispatches: Error executing script. Error for call_service at pos 2: Maximum requests of 20/hour reached. Will reset after 2026-02-23 05:03:30.313016+00:00
2026-02-23 06:14:42.144 ERROR (MainThread) [homeassistant.components.template.template_entity] TemplateError('TypeError: 'NoneType' object is not iterable') while processing template 'Template<template=({% set ns = namespace(target=[]) %} {% set completed=state_attr('binary_sensor.octopus_energy_00000000_0002_4000_8020_0000000b56e8_intelligent_dispatching','completed_dispatches') %}

Confirmation

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

[DebuggingMax]

Root Cause Analysis

I analyzed the code and found the bug in custom_components/octopus_energy/coordinators/intelligent_dispatches.py.

The Problem

The rate limit counter and last_reset timestamp are not being properly persisted after the hourly reset period. Looking at your logs:

2026-02-23 04:00:30.314 ERROR ... Will reset after 2026-02-23 04:00:30.315678+00:00
2026-02-23 05:03:30.313 ERROR ... Will reset after 2026-02-23 05:03:30.313016+00:00

The reset time is essentially "now" in both cases, which means the code IS detecting that an hour has passed and computing the reset. However, the reset values are never persisted because the return statements use the OLD values from existing_intelligent_dispatches_result instead of the locally computed reset values.

The Bug (3 locations)

1. Line 149-150 (rate limit return):

# BUG: Returns OLD values, losing the reset
existing_intelligent_dispatches_result.requests_current_hour,
existing_intelligent_dispatches_result.requests_current_hour_last_reset,

2. Line 165-166 (manual throttle return):

# BUG: Same issue
existing_intelligent_dispatches_result.requests_current_hour,
existing_intelligent_dispatches_result.requests_current_hour_last_reset,

3. Line 215-216 (API failure return):

# BUG: Uses old counter, losing the reset
existing_intelligent_dispatches_result.requests_current_hour + 1,
existing_intelligent_dispatches_result.requests_current_hour_last_reset,

The Fix

All three locations should use the local variables requests_current_hour and requests_last_reset which properly reflect any hourly reset that occurred:

requests_current_hour,  # or requests_current_hour + 1 for failure path
requests_last_reset,

Patch Available

I have prepared a patch: https://gist.github.com/DebuggingMax/8e3451704c554c886013730c411b5b5d

The code is also available at: https://github.com/DebuggingMax/HomeAssistant-OctopusEnergy/tree/fix-rate-limit-reset-1656

(Note: I was unable to fork the repo through the API to create a PR directly, but the fix is ready to be applied.)

[BottlecapDave]

Hello @blacknell sorry for the late response and that you've encountered this issue. Are you still experiencing this? I'm failing to recreate it locally. The fact your current rate sensor is also stuck suggests HA has somehow "forgot" about these entities. I assume previous/next sensors are updating correctly?

@DebuggingMax If you could please not just spout out an AI response, it would make things easier for myself when managing issues. Based on the output that feels copied/pasted, my thought below on why this has nothing to do with the problem at hand

lines 149-150
Yes this can be updated to use the local variable, however if it reaches this branch, it will be the same value.

line 165-166
This is using the wrong data, however it doesn't impact anything other than feedback in attributes as it will be reset in the next cycle.

lines 215-216
This could be an issue from a feedback pov, but because it's in the fallback scenario of a failed request will be reset properly in the next cycle.

[blacknell]

@BottlecapDave - i finally chanced upon what was wrong. By switching off Enable polling for changes in system options I was effectively stopping home assistant getting updates and the integration appeared dead. when one does this your supposed (or can choose) to call the update action.

I apologise.

That said I am still getting many many max requests error messages and I don't know why. It's unrelated to this issue but it is to a previous occurrence #1369

it causes me much concern what with Octopus being so central to my HA setup.

[BottlecapDave]

Even if you stop calling the update pending dispatches action/service, the off peak sensor should still come on during the standard off peak times (same with the current rate sensor). Were you not seeing this behaviour?

The above changes may have an impact on the feedback sensor which will be included in the next update. Also make sure you have the latest version of the blueprint.

[blacknell]

It stayed at off for 4-5 days.

The service I call every 3 mins is action: octopus_energy.refresh_intelligent_dispatches

[blacknell]

Here are some more traces. Am I getting confused between home mini polling and the standard dispatches polling?

2026-03-15 07:21:46.597 WARNING (MainThread) [custom_components.octopus_energy.api_client] Errors in request (https://api.octopus.energy/v1/graphql/) (home-mini-consumption): [{'message': 'Too many requests.', 'locations': [{'line': 2, 'column': 2}], 'path': ['smartMeterTelemetry'], 'extensions': {'errorType': 'AUTHORIZATION', 'errorCode': 'KT-CT-1199', 'errorDescription': 'There were too many requests. Please try again later.'}}]
2026-03-15 07:22:15.763 WARNING (MainThread) [custom_components.octopus_energy.api_client] Errors in request (https://api.octopus.energy/v1/graphql/) (home-mini-consumption): [{'message': 'Too many requests.', 'locations': [{'line': 2, 'column': 2}], 'path': ['smartMeterTelemetry'], 'extensions': {'errorType': 'AUTHORIZATION', 'errorCode': 'KT-CT-1199', 'errorDescription': 'There were too many requests. Please try again later.'}}]

[BottlecapDave]

Those traces are for your home mini. These are restricted to 100 calls per hour across all devices/meters/services. This is why the default values are 1 minute for electricity and 2 minutes for gas. If you have other services using this data or use the app a lot then you can reach the limits easily.

[blacknell]

Ah. You say other services. What could these be?