Creation of Reporter class

[victorgarcia98]

The Reporter class serves as a basis class for the development of new reporters. Reporters are parametrized through the input dictionary report_config. Once it's instantiated, the reporter object can generate new reports by using the method compute. In addition, the parameters can be updated by passing them to the compute method.

On calling of compute, the base Reporter class does the following:

1. Triggers config deserialization.
2. Fetches the data of the sensors described by the field tb_query_config of the report_config.
3. Runs the private method _compute that needs to be implemented in the subclasses.
4. If the output is a BeliefsDataFrame, it simplifies it into a DataFrame.

In addition, this PR includes the class PandasReporter, which allows applying pandas methods to the sensor's data. Also, for cases where we need to use a DataFrame object as input of the method, we can reference to it by prepending @. For example, let's see a transformation to merge the dataframe sensor_2_source_1 into sensor_1_source_1:

            dict(
                df_output="df_merge",
                df_input="sensor_1_source_1",
                method="merge",
                args=["@sensor_2_source_1"],
                kwargs=dict(on="event_start", suffixes=("_sensor1", "_sensor2")),
            ),

This PR Closes #626 .

Please, let me know your thoughts on this.

[Flix6x]

Two quick comments.

(I'm still in the process of understanding the rationale behind your df_input / df_output approach. It's basically an additional feature next to the ability to pipe methods, right?)

[victorgarcia98]

Two quick comments.

(I'm still in the process of understanding the rationale behind your df_input / df_output approach. It's basically an additional feature next to the ability to pipe methods, right?)

Yes! Basically we have a controlled scope (self.data) which is used to create and update variables.

In more detail, the logic is the following:.

• when df_output and df_input are provided:
  <df_output> = <df_input>.<method>(*args, **kwargs)
• when df_output is not provided and df_input is provided:
  <df_input> = <df_input>.<method>(*args, **kwargs)
• when df_input is not provided, df_output is provided (and there's exist a previous transformation):
  <df_output> = <df_previous>.<method>(*args, **kwargs)
• when none is provided:
  <df_previous> = <df_previous>.<method>(*args, **kwargs)

[Flix6x]

Thanks for adding the Tibber test. I helped me greatly in understanding how I would be able to define new reporters in practice. I'm focusing my reviews on the tests at the moment, still with an eye on ways to simplify the reporter_config. The functionality is already very expressive (by which I mean powerful). Let's discuss the use of timely-beliefs classes and their (current) limitations in a call.

[Flix6x]

Nearing completion, I think.

[Flix6x]

Awesome work! I basically approve.

Besides a few minor comments, I should note that I haven't reviewed nor tested the Reporter registration from plugins. I wanted to do that in a separate PR, but if you prefer to include it in this one, I can maybe review it in a later PR that extends the plugin documentation section, as a follow-up issue? What do you think?

[victorgarcia98]

Thanks for the review @Flix6x!
I agree, we can leave the Reporter registration for a future PR on documentation.

[Flix6x]

I think one last variable is misnamed, but other than that: looks great!