Skip to content

Separate data source for forecasts and measurements #8

Description

@nhoening

I'd like forecasts and measurements to be saved under a separate DataSource (type), so we can treat them separately in e.g. the FlexMeasures UI.

I propose to use the following. For measurements:

Source(
    name="OpenWeatherMap",
    model="onecall/timemachine",  # name of the API, see https://openweathermap.org/api/one-call-api#history
    version="2.5",
    type="archive",  # alternatives: "historian" or "logger"
)

And for forecasts:

Source(
    name="OpenWeatherMap",
    model="onecall"  # name of the API, see https://openweathermap.org/api/one-call-api#current
    version="2.5",
    type="forecaster",
)

Two notes:

  • FlexMeasures could use a database migration to fill in the model and version (to this date, this plugin only used the onecall endpoint and not the onecall/timemachine endpoint). Even though such a migration would be specific to this plugin, I reckon it should be part of the db versioning of FlexMeasures.
  • As a related issue, I'm considering using a db migration to rename the "forecasting script" data source type to "forecaster" in FlexMeasures.
  • OWM's latest API version is actually 3, see https://openweathermap.org/api/one-call-3, so let's consider updating (in a separate issue).

Originally created by @Flix6x

See also the discussion in SeitaBV#8

There we concluded we might need a tech spike. And that first it is needed to discuss whether (each) forecasting service lets us actually make a call after the fact to get real measurements.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions