Add roundtrip efficiency to scheduler

[ArdJonker]

My charger + battery has a roundtrip efficiency of about 80 - 85%. I'd like the scheduler to take this into account.
It is temperature dependant, could this be in the equation.

[Flix6x]

That would be useful indeed. I'll treat this as two feature requests.

Can the scheduler take into account a round-trip efficiency?

There are a couple of ways we could implement this.

Efficiency set as a sensor property

We could add an optional attribute to (Charge Point) sensors, with which you can set and control such a round-trip efficiency η. We can then have the Charge Point scheduler check for this attribute, and if it exists, either:

• scale discharging prices by a factor η, or
• scale charging prices by a factor 1/η, or
• scale discharging prices by a factor √η and charging prices by a factor 1/√η.

You should then be able to update the efficiency attribute as needed, e.g. short-term when temperature changes or long-term as your battery deteriorates or is replaced.

Efficiency passed as part of the UDI event

That is, each time you ask FlexMeasures to compute a schedule, you tell it explicitly what efficiency it should take into account. This could be optional, too, with the sensor's efficiency as a sensible fallback. Imo, this option makes more sense for communicating short-term updates (e.g. with changing temperature), because you can communicate information relevant to the flexibility model within a single API call. Do you expect the efficiency to vary within the duration of a charging session (say, several hours), or would it be within reason to apply a constant efficiency for the entire schedule?

Can we take into account the temperature dependency of the round-trip efficiency?

Client side

If you have a function describing the efficiency/temperature dependency, and already measure the temperature, you could compute the efficiency on the client side and use the UDI-event approach described above to communicate it to the scheduler.

Server side

We would set up the temperature dependency as a sensor property (or have it passed as part of the UDI event). This would mean we assign a temperature sensor to the Charge Point, and store the temperature dependency as a model. When asked to compute a schedule, we then read out the temperature sensor and apply the dependency to compute the efficiency. Our data model doesn't accommodate this yet, though, but we are working on such features as part of two ongoing projects (project 9 and project 6](https://github.com/FlexMeasures/flexmeasures/projects/6)).

[Flix6x]

@ArdJonker My initial approach of scaling prices only worked when those prices (being part of some energy contract) are used to bill the Charge Point separately. To support residential settings, in which the energy contract is applied to the house + Charge Point prosumption, I had to implement the discharging and charging efficiencies differently. Our device scheduler now models energy flows more distinctly, so efficiencies can be taken into account separately per (flexible) device within the house. This work will be released soon as part of flexmeasures=0.8.0.

[Flix6x]

Given the success you reported with our latest dev version, I'm closing this issue now.