Documentation/v2g use case

[Flix6x]

Description

Add a documentation page detailing how to construct a flex-model for a case in which SoC targets may occasionally go outside of a typical SoC range.

Look & Feel

(There are more sections after this.)

How to test

Run make update-docs, then head to http://localhost:5000/ui/static/documentation/html/api/v2g.html

Related Items

Closes #693.

---

• I agree to contribute to the project under Apache 2 License.
• To the best of my knowledge, the proposed patch is not based on code under GPL or other license that is incompatible with FlexMeasures

[nhoening]

Great to have this. A few improvements could happen.

And also, this should maybe be linked in better places.

• Add it in the index under the API
• Actually, it's not a topic limited to the API once we find a permanent home for the flex model (see #827)

One could even consider this a (not self-contained) tutorial. It could actually be implemented once someone has followed the toy tutorial (as what really is needed is just that - a battery).

I see two ways to do this:

1. We could at the very least link to this from the toy tutorial as an example how to do more with a battery, like controlling schedules through the flex-model through the API (the CLI is actually limited as it cannot send a fresh flex-model).

2. The usual toy example I (scheduling a battery by price from scratch, using the CLI) is to become part A of example I, and this PR becomes part B of example I (still scheduling one battery by price, but now introducing the highly important flex-model and flex-context, and using V2G as a tangible example). Part B is not executable by the user right now. We could add a note of that and an create a Github issue to make that happen. Maybe using the flexmeasures-client is fitting, even - everything is in place, like sensors and price data, just requesting schedules with an updated flex-model is needed.

As you might be able to tell, I prefer the second option, and I believe it would not be much work in this PR, mostly giving it a new location, introducing it a little differently, adding the note for future work.

[nhoening]

Wouldn't it be helpful to add the time of day to the x-axis (it's being used a lot in this example)?

[Flix6x]

The chart, which was graciously created for us by @ArdJonker, was meant as a stylized example. @ArdJonker it's up to you whether you want to update it with some relevant time labels.

I update the times in my example to try and achieve an intuitive scale with respect to the current stylized schedule (charge in the afternoon, discharge in the evening, charge in the night, leave in the morning), but I could easily update the times, of course:

• start of graph: 10.35 on February 4th
• start of constraint relaxation window: 04.25 on February 5th
• start of calendar target: 08.00 on February 5th

[ArdJonker]

Nice chart ;-)! Great documentation, clarifies a lot. Your process with review look solid and professional!

[Flix6x]

One could even consider this a (not self-contained) tutorial. It could actually be implemented once someone has followed the toy tutorial (as what really is needed is just that - a battery).

I feel the current tutorials focus on a host perspective, while this use case focuses on a client perspective. So I found it hard to simply write it into the tutorials sections. I'd like to leave it in the API section for now, and you can choose to move it as part of a larger documentation refactoring. I think you and @victorgarcia98 already formed ideas in #763, and I'd gladly entrust you with rearranging the docs accordingly.

[nhoening]

Host and client usually converge in "application builder" right now. Also, the flex model and context can partly come to live on the data structure, and then be part of the host's way to design the system.

Your choice to leave it to me.

[nhoening]

Can you leave a note in that docs discussion for me to maybe pick this up as well?