Not finding 3 hour overnight Cosy slot

[gcoan]

Describe the bug

I have two target timeframes setup, one for 1.5 hours, the other for 3 hours.

The setup of both of them is identical, they are continuous targets, re-evaluated multiple times a day, and set to always mode. Max rate 14.5p (although shows rounded as 15p in the attributes)

I am on Octopus Cosy, so 2 hour cheap period form 10-midnight which the 1.5 hour sensor is finding fine, and then 3 hours cheap from 4-7 which I would expect the 3 hour sensor to find but it is not.

1.5 hour sensor:

3 hour sensor:

Octopus Cosy rates:

Reproduction steps

Create a target timeframe sensor configured as follows:

Expected behaviour

I would expect the 3 hour sensor to find the 4-7am Cosy cheap rate period

Integration Version

1.4.0

Home Assistant Version

2025.9.4

Fresh Install?

Not specified

Home Assistant Logs

Turned on debug log, reloaded the integration, waited for the target timeframe sensors to update

home-assistant_target_timeframes_2025-10-30T21-39-06.891Z.log

Confirmation

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

[gcoan]

I forgot to mention that I did try deleting the target rate and resetting it up again in case it had been corrupted, but still same behaviour

Thinking about it later on, I thought the issue might be that the logic finding the target period had a < rather than a <= in somewhere, so it wasn’t finding the precisely 3 hour period.

To test this I reduced the target period to 2.5 hours, but still the time period wasn’t found

reduced to 2 hours, and also not found

so much for that theory

[BottlecapDave]

Hello. The attributes of the sensor is indicating that not enough data is available for it to calculate it. I believe this is because you have it set to rolling target, it is calculating the target timeframe between 21:29 and 00:00 of the current day you're setting up the sensor. At this time, that's only 2.5 hours, which is less than the required 3. When you changed it at 22:59 to 2 hours, it then only had 1 hour of data available for the time period is was evaluating. If you had not configured for rolling target, then it would have found the target timeframe between 00:00 and 00:00 (as you didn't specify this) for the the current day and would have picked one in the past. My guess is as soon as the new day started, it would have found you a target timeframe. I'm guessing the sensor is providing data now?

[gcoan]

thanks, the sensors were setup as target timeframes, and as I re-read the documentation and your comment I think this is probably wrong as it is evaluating over a 24 hour period. When I was on Agile this was fine as I evaluated with a 16:00-16:00 start-end time period, but now I am on Cosy with fixed periods and I found I wasn't getting the 3 hour session, I removed the start and end times.

Looking again at the documentation I think I should be setting this up as a rolling target timeframe.

I will try that.

And yes, at the moment I am getting a 3 hour period for this afternoon proposed, but last night I wasn't, same issue, evaluation was only up to midnight.

[gcoan]

Thanks for your feedback about the sensor being limited to the current 24 hour period, I now realise I should have created these as rolling target timeframes to find the next available slot.

Recreating as rolling target timeframes resolves this problem of not finding the 3 hour Cosy slot, but I have found 2 different problems!

Firstly with both the 3 hour rolling sensor and the 1.5 hour rolling sensor, they find the last available slot, not the next.
So instead of finding the Cosy slot from 1-4pm, they find the overnight one from 4-7am:

1.5 hour target:

1.5 hour rolling:

3 hour target:

3 hour rolling:

Second problem is that the target timeframe sensors set the Next time attribute to the start time of the next session, whereas the rolling target timeframes resolves sensors do not (well, sometimes they do, but most of the time they do not).
I've been using the next time attribute to determine whether there is a cheap slot coming up, and what the dishwasher delay should be.

[BottlecapDave]

The rolling target times are picking different slots, which are in the past because you don't have enough data available at the time of writing.

It's evaluating at 2025-11-04 at 00:01:45 looking for 24 hours worth of data. Because the OE integration pulls down data every 15 minutes, it doesn't look like it's refreshed the data for the next day (I know this is fixed rates for some tariffs, but it still checks with the servers and ensures it's correct regardless if you're on a fixed rate tariff due to the complications with the tariffs), so it only has data available up to 2025-11-05 00:00. Because the minimum required time in slots is 29 minutes, it's only using 47 applicable slots (2025-11-04 00:30 to 2025-11-05 00:00), which is less than required. This is indicated by the time periods incomplete attribute.

Again, once the data is available it should find the correct slot. If you want it sooner, you can either reduce your look ahead hours to something like 23.5 to account for this time when there's less data available or you can reduce the minimum required minutes in slot to something lower like 15 or 5.

The next time attributes will be set once a time frame has been discovered.

[gcoan]

The rolling target times are picking different slots, which are in the past because you don't have enough data available at the time of writing.

It's evaluating at 2025-11-04 at 00:01:45 looking for 24 hours worth of data. Because the OE integration pulls down data every 15 minutes, it doesn't look like it's refreshed the data for the next day (I know this is fixed rates for some tariffs, but it still checks with the servers and ensures it's correct regardless if you're on a fixed rate tariff due to the complications with the tariffs), so it only has data available up to 2025-11-05 00:00. Because the minimum required time in slots is 29 minutes, it's only using 47 applicable slots (2025-11-04 00:30 to 2025-11-05 00:00), which is less than required. This is indicated by the time periods incomplete attribute.

Again, once the data is available it should find the correct slot. If you want it sooner, you can either reduce your look ahead hours to something like 23.5 to account for this time when there's less data available or you can reduce the minimum required minutes in slot to something lower like 15 or 5.

The next time attributes will be set once a time frame has been discovered.

thanks for your reply, now you highlight the time last evaluated just after midnight, it makes sense.

I didn't really need 24 hours forward evaluation, it was just to encompass the whole day, so have changed it to 23 hours.
At the moment all looking good, I will keep an eye on the sensors and in particular the next time and see if I can see any issues

thanks

[gcoan]

Looked this morning (9:40, 6th November), and we are back to the rolling target timeframes not working.

Set to 23 hours look ahead on both the 1.5 and 3 hour TT

They last evaluated at 01:01 and report that they had incomplete data.

They're both showing the Cosy period from 4am to 7am this morning (6th), which is in the past.

Evaluation mode is always so I would expect them to have re-evaluated and them both showing target times of this afternoon 1-4pm but they are not.

And next time isn't set either but I think that's a consequence of the TT's not being re-evaluated when they should

1.5 hour non rolling showing next slot correctly:

1.5 hour rolling showing the historical slot, not having re-evaluated:

3 hour rolling also showing the historical slot, not re-evaluated:

[BottlecapDave]

That implies your data source is not updating properly. When was the automation last run that imports the prices from OE? It should be running whenever previous, current or next event sensors update. The available data should be available as an attribute of the data source last update sensor.

[gcoan]

The automation is running every 10 minutes. I'm using your blueprint

data source last updated is also updating regularly

the 1.5 hour rolling is now showing the correct target timeframe for this afternoon 1-4pm, updated at 12:30

as is the 3 hour rolling:

not touched anything at all with the automation.

I'll keep looking to try to identify if there is any data issues that might prevent the TT updating correctly

[BottlecapDave]

That looks fine. That's very odd as it should have enough data. I assume the rates up to the end of tomorrow are available in the attribute of the data source entity?

[gcoan]

Hello again Dave

7:15am and am seeing the same pattern.

Just focussing on the 1.5 hour sensor (but 3 hour shows same behaviour).

The 1.5 hour non rolling sensor was last updated at 7:14am and correctly shows the next cheap period Cosy as being 1-2:30pm:

Curiously (separate minor issue) the rolling sensor does not appear in the Activity log at all:

The 1.5 hour rolling sensor was last updated at 01:01am and incorrectly still reports that data was incomplete and the target timeframe as being 4-5:30am. It should have been recalculated as 4:30-6:00am, then 5:00-6:30am, then 5:30-7:00am, and should now be showing 1-2:30pm the same as the non rolling sensor:

The 1.5 hour rolling last turned on from 4:00-5:30 and does show in the Activity log:

The automation is firing regularly with events from the next/previous/current rate electricity:

And data source last updated for the target timeframes is regularly updating:

Looking at the data in the data source last updated, it is correctly showing import rates from previous (6th) and today (7th) up to midnight so the data is available and not incomplete.

One further bit of information, this is from yesterday, I took the screenshots but didn't upload them. They are of the 3 hour rolling sensor, but same behaviour in the 1.5.

At about 10am was seeing the same pattern with the 3 hour rolling sensor still incorrectly showing the historical 4-7am slot and not the 1-4pm slot:

but at 12:30 the rolling sensor then correctly identifies the afternoon slot:

In summary:

• no activity log for non-rolling sensors
• rolling sensors set to always mode are not re-evaluating when the session passes, still showing historical target timeframe and that data is incomplete (which it isn't). This persists until 30 minutes before the start of the next sensor

Hopefully this is enough information for you, please let me know if there is any more diagnosis I can do.

[gcoan]

update: at 12:30 the 1.5 hour rolling target rate sensor updated itself and correctly identified that the cheap slot is from 1pm:

13:42 and the 1.5 rolling target rate now correctly shows the cheap slot is from 2pm:

[BottlecapDave]

Yesterday I'd have expected rates in your data source to be available up to 2025-11-09T00:00:00, which is explaining why it's reporting as data being incomplete. If it recalculated at 2025-11-08T01:01 with a look ahead of 23 hours, then it would need data up to at least 2025-11-09T00:01.

There is a bug in the description of the next rate sensor (the third sensor) in the standard and free electricity OE blueprints which points at current rate sensor, but should point at the next rate sensor. Your activity looks like the blueprint automation is being triggered by previous and free electricity updates, but not current or next day updates. This could be just because it's being triggered at the same time as the previous rate sensor.

Are you able to take a screenshot of the automation that is based on the blueprint? Specifically the triggers.