grammar and typos

Signed-off-by: Victor Garcia Reolid <victor@seita.nl>

documentation/tut/toy-example-process.rst

@@ -127,4 +127,4 @@ Let's list the power price the policies achieved for each of the four blocks the
 
 Quantitatively, comparing the total cost of running the process under each policy, the BREAKABLE policy achieves the best results. This is because it can fit much more consumption blocks in the cheapest hours.
 
-This tutorial showed a quick way to optimize the activation of processes. In :ref:`tut_toy_schedule_reporter`, we'll turn to something different: using *reporters* to apply transformations to data stored in sensors.
+This tutorial showed a quick way to optimize the activation of processes. In :ref:`tut_toy_schedule_reporter`, we'll turn to something different: using *reporters* to apply transformations to sensor data.

documentation/tut/toy-example-reporter.rst

@@ -3,16 +3,17 @@
 Toy example IV: Computing reports
 =====================================
 
-So far, we have worked on the scheduling batteries and processes. Now, we are moving to one of the other three pillars of FlexMeasures: reporting. 
+So far, we have worked on scheduling batteries and processes. Now, we are moving to one of the other three pillars of FlexMeasures: reporting. 
 
 In essence, reporters apply arbitrary transformations to data coming from some sensors (multiple inputs) and save the results to other sensors (multiple outputs). In practice, this allows to compute KPIs (e.g. profit, total daily energy production, ...), apply operations to beliefs (e.g. change sign of a power sensor for a time period), among other things. 
 
-Currently, FlexMeasures comes with the following reporters:
-    - `PandasReporter`: applies arbitrary pandas methods to sensor data. 
-    - `AggregatorReporter`: combines data from multiple sensors into one using any of the Pandas `aggregate` function supported method (e.g. sum, average, max, min...).
-    - `ProfitLossReporter`: computes the profit/loss due to an energy flow under a specific tariff.
+.. note:: 
+    Currently, FlexMeasures comes with the following reporters:
+        - `PandasReporter`: applies arbitrary pandas methods to sensor data. 
+        - `AggregatorReporter`: combines data from multiple sensors into one using any of the Pandas `aggregate` function supported methods (e.g. sum, average, max, min...).
+        - `ProfitLossReporter`: computes the profit/loss due to an energy flow under a specific tariff.
 
-Moreover, it's possible to implement your custom reporters in plugins. Instructions for this to come.
+    Moreover, it's possible to implement your custom reporters in plugins. Instructions for this to come.
 
 Now, coming back to the tutorial, we are going to use the `AggregatorReporter` and the `ProfitLossReporter`. In the first part, we'll use the `AggregatorReporter` to compute the (discharge) headroom of the battery in :ref:`tut_toy_schedule_expanded`. That way, we can verify the maximum power at which the battery can discharge at any point of time. In the second part, we'll use the `ProfitLossReporter` to compute the profit of operating the process of Tut. Part III in the different policies.
 
@@ -30,8 +31,8 @@ Just as in previous sections, we need to run the command ```flexmeasures add toy
 Under the hood, this command is adding the following entities:
     - A yearly sensor that stores the capacity of the grid connection.
     - A power sensor, `headroom`, to store the remaining capacity for the battery. This is where we'll store the report.
-    - A `ProfitLossReporter` configured to use the prices that we setup in Tut. Part II.
-    - Three sensors to register the profit of running the process of Tut. Part III.
+    - A `ProfitLossReporter` configured to use the prices that we set up in Tut. Part II.
+    - Three sensors to register the profits/losses from running the three different processes of Tut. Part III.
 
 Let's check it out! 
 
@@ -68,7 +69,7 @@ Run the command below to show the values for the `grid connection capacity`:
                         ██ grid connection capacity
 
 
-Moreover, we can check the freshly created source `<Source id=6>` which defines the `ProfitLossReporter` with the required configuration. You'll notice that the `config` is under `data_generator` field. That's because reporters belong to a bigger category of classes that also contains the `Schedulers` and `Forecasters`.
+Moreover, we can check the freshly created source `<Source id=6>` which defines the `ProfitLossReporter` with the required configuration. You'll notice that the `config` is under the `data_generator` field. That's because reporters belong to a bigger category of classes that also contains the `Schedulers` and `Forecasters`.
 
 .. code-block:: bash
 
@@ -123,7 +124,7 @@ Finally, we can create the reporter with the following command:
        --start-offset DB,1D --end-offset DB,2D \
        --resolution PT15M
 
-Now we can visualize the headroom in the following `link <http://localhost:5000/sensor/8/>`_, it should resemble the following image.
+Now we can visualize the headroom in the following `link <http://localhost:5000/sensor/8/>`_, which should resemble the following image.
 
 .. image:: https://github.com/FlexMeasures/screenshots/raw/main/tut/toy-schedule/sensor-data-headroom.png
     :align: center
@@ -141,16 +142,17 @@ process from Tut. Part III, under the three different policies: INFLEXIBLE, BREA
 In addition, we'll explore another way to invoke reporters: data generators. Without going too much into detail, data generators
 create new data. The thee main types are: `Reporters`, `Schedulers` and `Forecasters`. This will come handy as the three reports that
 we are going to create share the same `config`. The `config` defines the price sensor to use and sets the reporter to work in **losses** mode which means
-that it will return positive values cost and negative values revenue.
+that it will return cost as positive values and revenue as negative values.
 
-Still, we need to define the parameters. The three reports share the same structure for the paramters with the following fields:
-* `input`: sensor that stores the power/energy flow. The number of sensors is limit to 1.
-* `output`: sensor to store the result of the report. We can provide sensors with differen resolutions to store the same results at different time scales.
+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.
 
-It's possible to define the `config` and `parameters` in JSON or YAML formats.
+.. note::
+    It's possible to define the `config` and `parameters` in JSON or YAML formats.
 
-After setting up `config` and `paramters`, we can invoke the reporter using the command ``flexmeasures add report``. The command takes the data source id,
-the files containing the paramters and the timing paramters (start and end). For this particular case, we make use of the offsets to indicate that we want the
+After setting up `config` and `parameters`, we can invoke the reporter using the command ``flexmeasures add report``. The command takes the data source id,
+the files containing the parameters and the timing parameters (start and end). For this particular case, we make use of the offsets to indicate that we want the
 report to encompass the day of tomorrow.
 
 Inflexible process