flexmeasures.data.models.reporting.aggregator

Module Attributes

Functions

flexmeasures.data.models.reporting.aggregator.units_match(unit: str, units: list[str]) → bool

Tell whether a sensor unit is one of the units to filter on.

A unit matches when it is spelled exactly like one of them, or when it measures the same quantity, so that filtering on “MW” also finds sensors recording in “kW”, but not sensors recording in “MWh”.

Classes

class flexmeasures.data.models.reporting.aggregator.AggregatorReporter(config: dict | None = None, save_config=True, save_parameters=False, **kwargs)

This reporter applies an aggregation function to multiple sensors.

The sensors to aggregate can be listed one by one, as input parameters, but they can also be selected in the reporter’s configuration, which is what makes this reporter useful for a whole site: name an asset and every sensor below it is aggregated, optionally narrowed down by a pattern on the sensor name and by the units the sensors record in. A site’s flex-context already describes its portfolio, so naming a portfolio reads the sensors from there instead, along with the sensor to record the aggregate on.

Values are converted to the unit of the output sensor, and resampled to its resolution, so that sensors recording in different units and at different resolutions can be aggregated.

_collect_input_descriptions(input: list[dict[str, Any]], output_sensor: Sensor) → list[dict[str, Any]]

List what to read, combining the input parameters with the sensors selected in the config.

The input descriptions are copied, so that reading them does not consume the parameters the reporter was given. A selected sensor that is already described as an input is left to that description, which is the more specific of the two. The output sensor is never aggregated into itself, which it otherwise would be when it sits below the configured asset.

_compute_report(start: datetime, end: datetime, output: list[dict[str, Any]], input: list[dict[str, Any]] | None = None, resolution: timedelta | None = None, belief_time: datetime | None = None, belief_horizon: timedelta | None = None) → list[dict[str, Any]]

This method merges all the BeliefDataFrames into a single one, dropping all indexes but event_start, and applies an aggregation function over the columns.

_convert_to_output_unit(df: DataFrame, sensor: Sensor, output_sensor: Sensor, resolution: timedelta) → DataFrame

Convert the values read from one input sensor to the unit of the output sensor.

A sensor without a unit is left alone, with a warning, because an empty unit says nothing about what its values mean.

_find_sensors() → list[Sensor]

Find the sensors that the reporter’s configuration selects.

The pool of candidates holds the sensors of the asset named in the asset field and of its offspring, together with the sensors listed in the sensors field. The sensor-name-pattern and sensor-units fields then narrow that pool down. Sensors are returned ordered by ID, so that an aggregation over a site does not depend on the order in which its sensors happen to be loaded.

A configured portfolio reads the asset’s flex-context instead of walking its subtree, so that naming a portfolio aggregates the sensors it lists and not every sensor that happens to sit below the asset. The sensors field still contributes alongside it.

_flex_context_field(which: int) → tuple[Any, str] | tuple[None, None]

Return the asset’s flex-context value for the configured portfolio, and the field name it came from.

which picks the field from PORTFOLIO_FLEX_CONTEXT_FIELDS: 0 for the sensors to aggregate, 1 for the sensor to record on. Returns (None, None) when no portfolio is configured.

_portfolio_input_descriptions() → list[dict[str, Any]]

Read the sensors to aggregate from the configured portfolio in the asset’s flex-context.

Each entry there may carry source filters, which are passed on to the belief search as they are, so that a portfolio naming a forecaster’s values aggregates exactly those.

_resolve_output(output: list[dict[str, Any]]) → list[dict[str, Any]]

Settle which sensor the aggregate is recorded on.

An output named in the parameters wins, so a caller can send a portfolio’s aggregate somewhere else for once. Otherwise the configured portfolio’s aggregate-consumption or aggregate-production says where it goes.

property input_sensors: list

Return the sensors read by this reporter, including the ones selected in its config.

A selected sensor that the report is recorded on is left out, just as it is when the report is computed. A sensor named in the input parameters is kept, even when it is also an output sensor, because naming it there asks for it to be read.

property output_sensors: list

Return the sensors this reporter records on, including one taken from the asset’s flex-context.

This is what an automation checks a report against, so it has to name the sensor the report will really be written to.