Do rolling targets consider the current time?

[sshaikh]

I have the following rolling target set up:

name: 05_hours
hours: 0.5
hours_mode: exact_hours
type: Continuous
look_ahead_hours: 24
target_times_evaluation_mode: always
kind: rolling_target_rate
target_times: 
- start: '2025-06-15T12:30:00+01:00'
  end: '2025-06-15T13:00:00+01:00'
  value: 0.0315
  metadata:
    is_capped: false

target_times_last_evaluated: 2025-06-15T12:54:27.361834+01:00
time_periods_incomplete: false
overall_average_value: 0.0315
overall_min_value: 0.0315
overall_max_value: 0.0315
current_duration_in_hours: 0.5
current_average_value: 0.0315
current_min_value: 0.0315
current_max_value: 0.0315
next_time: null
next_duration_in_hours: 0
next_average_value: null
next_min_value: null
next_max_value: null
data_source_id: octopus_energy_import
icon: mdi:camera-timer
friendly_name: 05_hours (octopus_energy_import)

The 1230 target was correct pre 1230, and all of the next_ attributes had been populated. Enough data is available for look ahead (of 24 hours), and checking manually, the next cheapest rate is at 1330.

I just allowed it to tick over, and it changed to this:

name: 05_hours
hours: 0.5
hours_mode: exact_hours
type: Continuous
look_ahead_hours: 24
target_times_evaluation_mode: always
kind: rolling_target_rate
target_times: 
- start: '2025-06-15T13:30:00+01:00'
  end: '2025-06-15T14:00:00+01:00'
  value: 0.04032
  metadata:
    is_capped: false

target_times_last_evaluated: 2025-06-15T13:01:27.375311+01:00
time_periods_incomplete: false
overall_average_value: 0.04032
overall_min_value: 0.04032
overall_max_value: 0.04032
current_duration_in_hours: 0
current_average_value: null
current_min_value: null
current_max_value: null
next_time: 2025-06-15T13:30:00+01:00
next_duration_in_hours: 0.5
next_average_value: 0.04032
next_min_value: 0.04032
next_max_value: 0.04032
data_source_id: octopus_energy_import
icon: mdi:camera-timer
friendly_name: 05_hours (octopus_energy_import)

Which means that if we're currently in the middle of a target, we won't know when the next target might start. With longer hours, this means we may even miss a qualifying timeframe.

For instance:

1. Let's say I have a job (a wash) that I know takes 1 hour, but I don't know when I might start it.
2. I set up a rolling target for 1h, set to look ahead 24h. It returns 1300.
3. We become ready to start the job at 1315, but the rolling target still reports 1300.
4. If we wait till 1400, it might report 1900 (say)
5. However the correct cheapest target at 1315 was actually at 1330, since 1330-1430 would have been cheaper than 1900-2000.

My questions:

1. Is the above understanding correct?
2. Is there currently a way to "force" the evaluation of the rolling target to actually consider the time of evaluation, and not prices in the past? I tried forcing a reconfigure and that still returned the already-started-window (even though the evaluation time updated).

[sshaikh]

To answer my own questions: the above understanding is incorrect and prices in the past are not considered.

My confusion during my testing was due to the current price still being considered in the evaluation, even up to 29 mins after it had started. This is the behaviour regardless of the evaluation mode.

Keeping or ignoring the current price probably depends on the use so I'll raise a FR to offer possible improvements to that.