Maximise return instead of minimising import rates

[ccristal]

Describe the feature

This applies to intermittent slot selection. Think about users who have Agile for both import and export. Basically, for every 1/2 hour slot, I need to decide whether to use it or export it. I want to use if it's "the cheapest", otherwise I would be better off exporting it.

The problem is the meaning of "cheapest". At the moment, your automation selects the cheapest slots based on import rate only. My point is that it should, instead, choose them based on the difference between import rate of the slected slots and export rate of all the other slots in the selection period, and select the slots that minimise that difference.

Expected behaviour

The slots selected by a target rate sensor would no longer be the ones with the lowest import rates. Instead, they would be the ones that maximise the overall return over the whole selection period.

Use Case

So, suppose I have two 1/2 hour slots A and B, and that I need 1/2 hour to run my appliance:

Slot	Import rate	Export rate
A	1p	10p
B	2p	5p

Your current sensor would activate on slot A, but it would make much more sense exporting slot A and running my appliance on slot B: yes, I would pay more, but I would be better off overall, earning net 8p over the whole period instead of 4p.

Confirmation

• [X] By submitting this feature request, you agree that you have read the documentation and confirmed it does not already exist
• [ ] I am willing/able to help contribute to the solution of this feature

[BottlecapDave]

Thanks for raising. I haven't forgotten your original request. Implementing this would require a significant amount of work, so for now I'm marking this as requiring more demand.

[chrisys]

@ccristal I'm interested in your use case here, purely from a point of view of finding a solution. I think I get what you're trying to do, but am getting caught up on the fact your examples show an import rate lower than the export rate - surely that's never the case (otherwise you could just import power and export it immediately for a profit)? I've seen edge cases where this does happen but the difference is usually <1p so I doubt it caters for the inefficiencies.

[ccristal]

Oh, it happens all the time. I am on fixed export rate, I get 15p per KW exported. The import rate is very often less than that. It can go to 0, or even negative (i.e. you get paid to consume electricity). And yes, charge and resell is exactly what people may want to do (assuming it's not forbidden by the T&Cs, and that they don't care about battery lifespan ;-) ).

Here's an example:

[chrisys]

Oh, I was working on the basis you had said 'Think about users who have Agile for both import and export' - makes sense if you're using fixed price export.

[chrisys]

I had thought about something similar when it comes to battery lifespan - i.e I want to know how much the energy in the battery cost, to know if it's worth it to discharge the battery (based on a cost per cycle estimation), or if it makes more sense to just import. You'd have a to have a spread between the charge cost and import cost that you're offsetting large enough to offset the cost of using a battery cycle. I guess ideally you'd even want to look forward and know that there's a spread large enough before you even charge in the first place!

[BottlecapDave]

With the release of v11.0.0, it brings the ability to set minimum/maximum rates for target rate sensors. This was mainly added due to demand and ease of adding the feature.

As this original issue was around fixed exports, I believe this can be achieved with a target rate sensor which

• Targets the import meter
• Has a maximum rate set of 0.15
• Has Invert targeted rates set to true, which will find the most expensive rate in this scenario.

This will find the slots with the most expensive rates below 15p which will be the slots with your maximum return based on your examples. If there are not enough slots below 15p, then the sensor will not turn on.

Based on this, I'm not sure if this feature is required other than the convenience of not needing to set the maximum rate manually.

As for agile exports, my assumption is these would always increase/decrease inline with imports so not sure if this would be applicable, but would be interesting to know.

@chrisys with your feature, something like predbat might give you what you're after, but I'm not sure.

[irata-coder]

I attempted to implement a similar feature using the latest release, in my example below I am focusing primarily on the import side first. The same logic would be applicable for an export target rate sensor, but it would use a calculated minimum rate and target_hours from what was acheived on the import side. These calculated minimum/maximum can ensure at least an x pence delta.

I was able to calculate the maximum rate required using a template and subsequently updated the target rate sensor by calling the service.

However, I'm puzzled as to why the rates aren't populated with as many slots as possible based on the maximum rate when there aren't enough slots. Even if only half of the slots match, there's still value in knowing this. Given that the values (e.g., hours) are always presented as a target, it seems logical to populate as many slots as possible up to the target hours when a maximum or minimum rate is set. For instance, if the target hours are 24, the system should find as many slots below the maximum as possible.

There could be an attribute called "target hours achieved", although a template could easily count the rates list and compare to the hours attribute.

I've managed to find a solution, albeit a bit messy. I used another template to calculate the number of hours below the maximum rate, then called the service to change the target rate sensor, including this calculated target_hours.

As a summary, if not enough slots are found when minumum/maximum is used, I think it should still populate the rates with as many as it can and toggle accordingly.

[ccristal]

With the release of v11.0.0, it brings the ability to set minimum/maximum rates for target rate sensors. This was mainly added due to demand and ease of adding the feature.

As this original issue was around fixed exports, I believe this can be achieved with a target rate sensor which

• Targets the import meter
• Has a maximum rate set of 0.15
• Has Invert targeted rates set to true, which will find the most expensive rate in this scenario.

This will find the slots with the most expensive rates below 15p which will be the slots with your maximum return based on your examples. If there are not enough slots below 15p, then the sensor will not turn on.

Based on this, I'm not sure if this feature is required other than the convenience of not needing to set the maximum rate manually.

As for agile exports, my assumption is these would always increase/decrease inline with imports so not sure if this would be applicable, but would be interesting to know.

@chrisys with your feature, something like predbat might give you what you're after, but I'm not sure.

Thank you, Dave! I'll let you know how I get on... :-)

[BottlecapDave]

However, I'm puzzled as to why the rates aren't populated with as many slots as possible based on the maximum rate when there aren't enough slots

@irata-coder Because if someone states they want 2 hours and I give them 1 hour worth of slots, they'll rightfully raise a bug :) It could be the device they're powering with the sensor might use the most amount of energy on slot 3 of 4, which could be expensive if the sensor didn't meet the required hours.

With the introduction of the min/max values, the target rate sensor could be updated to have hours be optional if min and/or max is specified. However I'm struggling to determine the use case.

The idea behind a continuous slot is for devices that run for a certain amount of time or requires to be on for a certain amount of time (e.g. a dishwasher). The idea behind an intermittent slot is a device that can turn on/off but is required for a set amount of time during the day (e.g. a charger). If you don't require a certain number of hours then it doesn't feel like a target rate sensor is needed. You shouldn't need a continuous slot and an intermittent slot should come on as much as possible. In this scenario you could simply look at the current rate sensor and perform checks on the rate would work. If you needed the slots up front, then you could filter the collection rates via a template sensor.

I've raised https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/issues/869, which if you're requiring this would be good to give a thumbs up and give your example scenarios.

[BottlecapDave]

@ccristal I made a slight mistake in my sample. You want to turn on Invert targeted rates not Find last applicable rates