Rolling Target Doesn't Return If Rates are Not Available

[sshaikh]

Describe the bug

If the look ahead hours value is greater than the rates that are available, no target is set.

This may be by design, although the Rolling Target docs do not have the same disclaimer seen in the normal Target Rate docs:

The target rate will not be evaluated until all rates are available for the specified timeframe. 

Reproduction steps

Set look ahead to be 24 hours. Assuming rates are typically received at 4pm on D and cover till 11pm on D+1, this sensor will stop resolving from 11pm on D.

Expected behaviour

I wanted to move from the normal target rate sensor (set to 4pm) to the rolling target rate so that I could get usage windows for times when we have cheaper rates available past 4pm. At the moment, those windows are only generated at 4pm.

Tariff Code

E-1R-AGILE-24-04-03-C

Integration Version

13.2.1

Home Assistant Version

2024.12.0

Fresh Install?

After upgrading

Home Assistant Logs

No errors seen

Confirmation

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

[BottlecapDave]

This is currently by design for the same reason as the normal sensor as it wouldn't necessarily pick the correct times if all of the data isn't available.

This means if you look back at when the sensor comes on, you could incorrectly determine it picked the wrong times even though it picked it based on the limited data it had (unfortunately HA doesn't surface historic attributes with historic states).

[sshaikh]

That makes sense and happy to accept it as a (current) limitation. It's important for these things to be traceable.

Is there a current workaround to use "all rates available" without a complicated service call manipulating start and end times dynamically? Knowing that Agile is probably the most expensive between 4pm and 7pm kinda mitigates this, but it would be nice to be able to search post 4pm rates if they're available.

[BottlecapDave]

If you use the standard target rate sensor set to 16:00-16:00 as recommended in the docs, then this should find the next set of target times as soon as the times are published (assuming they're published near 4pm). You could shift the times a little later to account for rates coming in late (e.g. 17:00-17:00).

As for the rolling target rate sensor, you'd need to dynamically shift the look ahead hours down depending on hour many rates are available, as you've already suggested. I'm hoping that HA will make the attribute history available at some point (there's an open what the heck request), where I can then add more flexibility without opening the issues up to people saying something didn't turn on correctly when it did based on the data available at the time.

[sshaikh]

If you use the standard target rate sensor set to 16:00-16:00 as recommended in the docs, then this should find the next set of target times as soon as the times are published (assuming they're published near 4pm). You could shift the times a little later to account for rates coming in late (e.g. 17:00-17:00).

This is my understanding of how it is designed to work and largely does the job. However at the time of writing I have the following rates available in HA (yes, ouch):

And so as expected asking for the cheapest 1 hour window returns 1430, when it would be useful to know about the 2200 window before the configured 4pm. Perhaps (with the existing semantics) I want to set the times to 1600 - 2300(+1)? But generally it's the rolling target with a dynamic look ahead that I'm really after.

That said I do have a better understanding of why it's this way - happy for this issue to be closed if required (or moved to a feature request).

[SteveGBuck]

I've been working on how to dynamically work out hours to work around this exact issue. Happy to share what I've got to give you a head start...

In my automation I add variables:

variables:
  battery_hours: |
    {% set battery_hours = 24 %}

    {% set current_hour = now().hour %}

    {% if current_hour < 16 %}
      {% set battery_hours = min(battery_hours, 23 - current_hour) %}
    {% else %}
      {% set battery_hours = min(battery_hours, 30 - (current_hour - 16)) %}
    {% endif %}

    {{ battery_hours }}

  look_ahead_hours: |
    {% if now().hour < 16 %}
      {% set look_ahead_hours = 23 - now().hour %}
    {% else %}
      {% set look_ahead_hours = 30 - (now().hour - 16) %}
    {% endif %}
    {{ look_ahead_hours }}

Then to run the action:

data:
  target_hours: |
    "{{ battery_hours | round(0) | string }}"
  target_look_ahead_hours: |
    "{{ look_ahead_hours | string }}"
target:
  entity_id: [your target sensor]
action: octopus_energy.update_rolling_target_config
enabled: true

[sshaikh]

Thanks for that! I see it assumes that rates are delivered at 1600 for 2300 the next day? Based on the code at https://prices.fly.dev/api_how_to I think we can make it a little more generic with the following:

{{ state_attr('event.octopus_energy_electricity_23j0379480_1200041807630_current_day_rates', 'rates') | count / 2}}
{{ state_attr('event.octopus_energy_electricity_23j0379480_1200041807630_next_day_rates', 'rates') | count / 2}}

gives the number of hours available today and tomorrow, so we can probably knock up a template sensor that represents "number of hours left" with these two without having to hard code 16 and 23 above?

[SteveGBuck]

Ah nice yeah I will explore that suggestion further! thanks!