Support target rate sensors not meeting target hours

[David Kendall]

Describe the feature

Based on #894, add an option to support finding slots equal or below the target hours.

Expected behaviour

If the target hours is 3 but only 2 hours are found, then it should turn on during those times instead of never.

The thing that needs to be taken into consideration is agile pricing when all rate information isn't available. It should probably either

• Not calculate if the full rate period isn't available
• Require from/to times to be 11pm to guarentee the data or
• Provide a disclaimer that this setting might cause sensors to come on more than the desired number of hours.

Use Case

See #894.

Confirmation

• 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

[tim-b2]

In a couple of the cases you linked to this you were asking for a use case so hope it's helpful to provide mine - have set up a target rate sensor to switch on the ev charger for the cheapest 4 hours overnight (regardless of actual cost) - this isn't a full charge but is enough to cover several days use and keeps the battery in its optimum capacity for longevity.

However if electricity is very cheap I would prefer to import as much as possible (upto a full charge - this needs around 7 hours) , but even an extra 0.5h slot above the standard 4h is cost saving if means less charging needed on high cost days.

Setting a 2nd sensor with a 7h timer with a cost threshold (in a 13h overnight window) means if there are only 6 hours below the threshold it won't fire at all.

Using an intermittent, re-evaluating sensor (set at 0.5h to get as many slots as possible also creates possible issues:
1-If values were eg 3, 3,5,5,2,2,2,2,4,4,2,2 and threshold <4.5p then the first (3p) slots is ignored even though it would be usable. (the 4p slots are also ignored by this sensor but would be in the cheapest 4h window so my first sensor covers those.
2- I've also tried just triggering the charger on if current rate < max target rate but this isn't optimal, if there are e.g. 8 hours of 3p, then 3 hours at negative prices it would be best to use just some of the 3p hours along with the later slots, but currently although the trigger will still turn on the car will be full so won't take more charge.

(Ultimately would use data from the car to set the max hours dynamically to ensure always getting the right max duration).

Thanks for everything you've created so far.

[edc1]

I have the same use case. I'd like to turn on an EV charger when Agile prices go negative, even if there aren't enough slots with a negative price to meet the number set in required hours.

[John Bradshaw]

I have a similar use case for EV charging, if I need 6 hours to get to full charge but only 4 hours are cheap enough I'll quite happily only take the 4 hours of charging. I do this at the moment with automations and use the rate sensor in combination with other checks (current price), if the target rate sensors supported this I could use them to set the schedule on the charger instead of automating turning charge on/off when the target rate comes on/off alongside my other checks being valid.

[David Kendall]

As of v12.0.0, target rate sensors now support changing the mode for how defined hours are interpreted. The full rate information still needs to be available until the target rates are picked. Some config options are either not available or required in modes other than exact.