Issue 46 show screenshots in documentation #60
Conversation
nhoening
commented
Mar 11, 2021
nhoening
commented
- incorporate screenshots from SeitaBV/screenshots
- add some missing content
- talk about flexibility opportunities rather than flexibility actions
- remove two old pics
…ots higher up, talking about opportunities rather than actions and that certain functionality visualising them is only mocked; delete components page and images
There was a problem hiding this comment.
- Great to see the screenshots coming out of a separate repo.
- The terminology around flexibility opportunities and activation requires more discussion, but considering that we take out the control page for now, we can tackle that later.
- Some smaller reformulation requested.
documentation/views/control.rst
Outdated
| @@ -1,34 +1,33 @@ | |||
| .. _control: | |||
|
|
|||
| ***************** | |||
| Flexibility actions | |||
| Flexibility opprtunities | |||
There was a problem hiding this comment.
A lot of underdefined/ambiguous terminology in this section. I propose we discuss this thoroughly in case we activate this UI view.
There was a problem hiding this comment.
Just a note: this page is currently visible in the documentation. I suggest to move the content which does not talk about the UI into a new page which deals with concepts. That PR for #45 will land soon in your queue. There we might give it another look.
| Costs and revenues are calculated based on the internal method for profit sharing. | ||
| Asset owners that provide flexibility actions via the platform will generate revenues. | ||
| Suppliers that order flexibility action via the platform will generate both costs and revenues, where the revenues come from interacting with external markets. | ||
| Costs and revenues are calculated based on an internal method for profit sharing (TODO: explain). |
There was a problem hiding this comment.
This assumes a contractual relationship between multiple stakeholders, for example:
- between Aggregator and Prosumer, where the Aggregator sells the balancing power to a third party and shares the profits with the Prosumer according to some contracted method for profit sharing. In this case the stated costs and revenues for the Prosumer may be after deducting the Aggregator fee (which typically include price components per flex activation and price components per unit of time, but may include arbitrarily complex price components).
- between ESCo and Prosumer, where the ESCo advises the Prosumer to optimise against e.g. dynamic prices. Likewise, stated numbers may be after deducting the ESCo fee.
Alternatively, we can assume that all profit from activating flexibility goes to the Prosumer, or simply report the profits before sharing (and before deducting any service fees).
There was a problem hiding this comment.
I will use this content in my work on #45, thanks.
