Weighting for target rate sensors

[rozza-m]

Describe the feature

When you set up a target rate sensor, the end goal isn't to find the cheapest rates, it's to run whatever the power-consumer is for the least amount of money. Which might seem like the same thing, but:

• My car tails off its consumption as it gets nearly full, so the last hour of charging I'm less sensitive to cost if I can save money overall by having a cheaper rate in the first part
• I want my immersion heater running for 3 hours, but it's normally up to temperature in the first hour so I care less about the following hours
• My washer-dryer uses much more energy for the dry cycle at the end than the beginning so I really want that at the cheapest rate, even if it pushes the earlier part into a slightly more expensive rate.
• I think probably most devices have some kind of non-constant power profile to them that could benefit from this.

Therefore I propose than an optional "weighting" could be added to the target rate sensor. In its simplest form, it is an array that's the same length as the number of half-hour slots and is a set of numbers that act as multipliers to the weight. Could be between >0 and 1, or 1 and 100, or floats. So for my car that's charging for 8 hours I might have [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0.7, 0.5]. For my 3-hour long washer-dryer cycle I'd have [0.3, 0,3, 0.3, 0.3, 1, 1]. For my immersion heater perhaps it's [1, 1, 0.4, 0.2] or [2, 2, 1, 0.5]

It might also be worth thinking about a partial weights function so that people who use the service to update target rate sensors can keep a weighting without having to re-calculate it each time which might make automations more difficult. So if my car sometimes needs to charge for 4 hours and sometimes 10 hours I could have something like [..., 0.7, 0.5] to mean "a weighting of 1 until the last 2 slots which are 0.7 and 0.5] and my immersion heater could be [3, ...] which means that the first half hour is weighted 3 times as strongly as the rest. If there's a better solution than ... then obviously that could be used instead.

Expected behaviour

Target rate sensor updated with an optional weights property. The weights applied affect the evaluation of the cheapest (or, I guess most expensive if it's inverted) tariffs. It simply applies a multiplication factor to the rates before the evaluation.

e.g.

Tariff prices (p)                  14   14   10    7   15   21
Cheapest 3h with no weights                  ^^   ^^   ^^

With weights [0.5, 0.5, 1]	   ^^   ^^   ^^

With weights [1, 0.2, 0.2]			  ^^   ^^   ^^     

Weights supplied as an array or list of values, each of which is the weight for a half-hour period.
Some method of partially establishing weights at the beginning or end only.

Use Case

To be able to find the cheapest price to run appliances that have a non-linear power usage, for example using much more power at the end or beginning.

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

[BottlecapDave]

Hello and sorry for the late response. This looks like a duplicate of #733 so closing in favour of that.

[rozza-m]

Aw. I should have checked! Glad it's been raised though!