flexmeasures.data.models.forecasting.inputs

How a forecaster’s config describes the sensors it reads, including the one it forecasts.

A forecaster’s config says which sources to train on and how to clean what it reads. The sensor being forecast is named in the forecast parameters rather than in the config, so a config that wants to say the same about that sensor writes "auto" in place of its ID.

Module Attributes

Functions

flexmeasures.data.models.forecasting.inputs.fold_target_qualifiers_into_config(config: dict[str, Any], parameters: dict[str, Any], recorded_source: DataSource | None = None) → bool

Move source filters and cleaning bounds off the target in the parameters, into the config.

Both were briefly settable on the target in the forecast parameters, where they never reached the data source’s data-generator attributes. A payload that still carries them keeps working: the qualifiers move to a config entry naming "auto", and the parameters name the sensor alone.

Where the forecaster was set up from a data source that already exists, moving them is refused instead. That source records the config as it was, and nothing here can change what it records: the forecast would be computed with the qualifiers and attributed to a source saying it ran without them, which is the very gap this release closes. Such a payload is stored, so it would run that way again on every recurrence.

Parameters:

  • config – The forecaster’s config, mutated in place where the parameters carry qualifiers.

  • parameters – The forecast parameters, whose target is replaced by the sensor it wraps.

  • recorded_source – The data source the forecaster was set up from, where it was set up from one.

Returns:

Whether anything was moved.

Raises:

ValueError – if the parameters carry qualifiers while the config is already recorded on a data source.

flexmeasures.data.models.forecasting.inputs.resolve_forecast_inputs(config: dict[str, Any], target_sensor: Sensor) → tuple[dict[str, Any], Sensor | SensorReference]

Resolve a config against the sensor being forecast.

The config holds one entry per sensor the forecaster reads. The sensor being forecast is read as well, as the labels the model learns from, so an entry written as "auto" says how to read those labels rather than adding a column to the model: such an entry is taken out of the regressor lists and describes the target instead. Where several entries name it, the last one wins.

An entry naming that same sensor by its ID is left where it is, as the regressor it has always been. The two say different things: the labels leave out what forecasters recorded, while a regressor column does not, so an entry by ID adds the sensor’s own history including its earlier forecasts.

Parameters:

  • config – The forecaster’s config, as loaded.

  • target_sensor – The sensor the forecast is made for.

Returns:

The config to run with, whose regressor lists name concrete sensors, and the target as its entry describes it.

flexmeasures.data.models.forecasting.inputs.target_qualifiers(target: Sensor | SensorReference) → dict[str, Any]

The source filters and cleaning bounds a target reference carries, as a config entry would write them.

Read both by the fold here and by the service refusing them when an automation is created, so that the two agree on what counts as a qualifier.