BottlecapDave
commented
9 months ago Hello. Sorry for the late response. The current off peak sensor is pretty basic and takes the days worth of rates and finds the rate that is the lowest, and compares that against the current rate to determine if it's in an off peak period. This currently only works for tariffs that have 2 or 3 (as octopus are starting to introduce these) unique rates for a given day. The API doesn't provide anything that indicates off peak or peak periods explicitly.
Therefore for agile tariff, this process won't work as the rates during the specified period could be different values, and as octopus just advise that they're the most expensive periods that will skew the price, these in theory could be lower than other parts of the day depending on renewable energy (e.g. could be high fossil fuel use in the morning and then high renewable use during this peak period).
As an alternative, you could use a template sensor to turn on during these "peak" times. Or better yet you can take advantage of the target rate sensors which can turn on/off during lowest or highest periods of your choosing. These sensors provide min/max/average for the time they're on which can then be compared to the average for the day on the current price sensor.
Because of this, I don't think this is a good fit for the integration, but thank you for raising the suggestion.
Describe the feature
If I understand it correctly currently the binary_sensor for peak is pulled from the API for tariffs that have a peak and off peak. if you look at the Agile calcultion https://octopus.energy/blog/agile-pricing-explained/#pricing there is a Peak time premium between 16:00 and 19:00. I know I can set up a helper to do this but if that binary_sensor could be updated using that it would be awsome.
And further to that it would be pretty cool if the Current day average rate could be expanded to show Current day average rate (excluding peak), and possibly even the average of just the peak time.
Expected behaviour
the binary_sensor for Peak is true between 16:00 and 19:00 for Agile tariffs a Current day average excluding peak and average for peak only attribute is added.
Use Case
I've got relatively low battery capacity so have been charging twice a day once in the morning before 6am and then again a top up before the peak period starts. One of the conditions I use for the top up is that the average for the top up period is lower that the average price for the day. There have been a few really high priced days recently when the batteries didn'g charge and I think adding a peak binary sensor and the 2 additional average cost attributes would allow for more flexabilily.
Confirmation