Target rate sensor not creating next session when agile rates available

[gcoan]

Describe the bug

I have a 3 hour target rate sensor, no max/min price and start/end time currently set to 20:00, i.e. any time.

The sensor is currently on:

But it hasn’t been re-evaluated since 14:38 and the ‘next’ time slots identified:

Agile rates for tomorrow are available:

Sensor config:

Reproduction steps

Create a sensor similar to my setup

I suspect the problem is due to a combination of the sensor being on now and the agile rates arriving whilst the sensor is on. I’ll keep checking but I am guessing that once this 3 hour period is over the sensor will correctly re-calculate the next time period.

Expected behaviour

As soon as agile rates are made available the target rate sensors recalculate with the ‘next time’ details (assuming the other criteria such as min/max rate etc are met)

Tariff Code

E-1R-AGILE-23-12-06-A

Integration Version

12.2.1

Home Assistant Version

2024.8.3

Fresh Install?

Not specified

Home Assistant Logs

Not sure this is much use:

2024-09-05 16:36:40.232 DEBUG (MainThread) [custom_components.octopus_energy.coordinators.previous_consumption_and_rates] Finished fetching 1012444237400_22J0452464_previous_consumption_and_rates data in 0.000 seconds (success: True)
2024-09-05 16:36:40.232 DEBUG (MainThread) [custom_components.octopus_energy.electricity] Skipping electricity consumption and cost calculation as last reset has not changed
2024-09-05 16:36:40.232 DEBUG (MainThread) [custom_components.octopus_energy.electricity] Skipping electricity consumption and cost calculation as last reset has not changed
2024-09-05 16:36:40.233 DEBUG (MainThread) [custom_components.octopus_energy.coordinators.previous_consumption_and_rates] Finished fetching 1050002821319_22J0452464_previous_consumption_and_rates data in 0.000 seconds (success: True)
2024-09-05 16:36:40.234 DEBUG (MainThread) [custom_components.octopus_energy.electricity] Skipping electricity consumption and cost calculation as last reset has not changed
2024-09-05 16:36:40.234 DEBUG (MainThread) [custom_components.octopus_energy.electricity] Skipping electricity consumption and cost calculation as last reset has not changed
2024-09-05 16:36:50.236 DEBUG (MainThread) [custom_components.octopus_energy.coordinators.previous_consumption_and_rates] Finished fetching 1012444237400_22J0452464_previous_consumption_and_rates data in 0.000 seconds (success: True)
2024-09-05 16:36:50.237 DEBUG (MainThread) [custom_components.octopus_energy.coordinators.previous_consumption_and_rates] Finished fetching 1050002821319_22J0452464_previous_consumption_and_rates data in 0.000 seconds (success: True)

Confirmation

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

[gcoan]

Something else not quite right with the target rate sensor.

target rate sensor for overnight time for the washing machine. 1.5 hours, max 15p overnight any time between 20:00 and 08:00 (outside of these hours I would be just as cheap running it off otherwise exported solar).

No time slots identified:

Its currently Sunday 18:52 and looking at the agile prices, Monday evening 21:30 onwards should have been selected:

[BottlecapDave]

Hello and sorry for the late response, I've been away for a couple of weeks. As per the docs, the target times will not be re-evaluated until all existing target times are in the past. By the looks of your initial screenshots, your target rates were set to finish at 18:00, so they should have re-evaluated soon after that. In the next release, there will be a newer type of target rate sensor (rolling times) which might be better suited for your circumstance.

As per your second post, the target times are evaluated during the periods you've specified, and they'll only look at the next block of times once the current block is in the past. For your setup, at 18:44 at 8/9/24, it would be looking at target times between 20:00 7/9/24 and 20:00 8/9/24. It would only look at the new agile rates between 20:00 8/9/24 and 20:00 9/9/24. This is to ensure the sensor doesn't come on too much during the specified time frame. I'll add this clarification to the docs at some point this week. Again, the upcoming new target rate sensor might be better suited for your scenario.