Merge cdb9b61 into 64beb24

documentation/tut/toy-example-expanded.rst

@@ -103,6 +103,29 @@ First, during the sunny hours of the day, when solar power is being send to the
 
 Second, charging of the battery is also changed a bit (around 10am), as less can be discharged later.
 
+Moreover, we can use reporters to compute the capacity headroom (see :ref:`tut_toy_schedule_process` for more details). The image below shows that the scheduler is respecting the capacity limits.
+
+.. image:: https://github.com/FlexMeasures/screenshots/raw/main/tut/toy-schedule/sensor-data-headroom-pv.png
+    :align: center
+|
+
+In the case of the scheduler that we run in the previous tutorial, the PV is not taken into consideration and the discharge power exceeds the headroom:
+
+.. image:: https://github.com/FlexMeasures/screenshots/raw/main/tut/toy-schedule/sensor-data-headroom-pv.png
+    :align: center
+|
+
 We hope this part of the tutorial shows how to incorporate a limited grid connection rather easily with FlexMeasures. There are more ways to model such settings, but this is a straightforward one.
 
 This tutorial showed a quick way to add an inflexible load (like solar power) and a grid connection. In :ref:`tut_toy_schedule_process`, we'll turn to something different: the optimal timing of processes with fixed energy work and duration.
+
+
+
+
+
+
+
+
+.. image:: https://github.com/FlexMeasures/screenshots/raw/main/tut/toy-schedule/sensor-data-headroom-nopv.png
+    :align: center
+|

documentation/tut/toy-example-reporter.rst

@@ -148,8 +148,9 @@ we are going to create share the same `config`. The `config` defines the price s
 that it will return costs as positive values and revenue as negative values.
 
 Still, we need to define the parameters. The three reports share the same structure for the parameters with the following fields:
-* `input`: sensor that stores the power/energy flow. The number of sensors is limited to 1.
-* `output`: sensor to store the report. We can provide sensors with different resolutions to store the same results at different time scales.
+
+    - `input`: sensor that stores the power/energy flow. The number of sensors is limited to 1.
+    - `output`: sensor to store the report. We can provide sensors with different resolutions to store the same results at different time scales.
 
 .. note::
     It's possible to define the `config` and `parameters` in JSON or YAML formats.
@@ -242,5 +243,6 @@ Check the results `here <http://localhost:5000/sensor/11/>`_. The image should b
     :align: center
 |
 
+
 Now, we can compare the results of the reports to the ones we computed manually in :ref:`this table <table-process>`). Keep in mind that the
 report is showing the profit of each 15min period and adding them all shows that it matches with our previous results.