v0.29: Flex-model & SwaggerUI

Version v0.29 of FlexMeasures moves the flex-model of assets on the data model and adds a UI to edit it. Also, the API docs are moving to OpenAPI format, and developers can interact with it via SwaggerUI!

Both of these larger features make FlexMeasures much more applicable to real-world integrations. FlexMeasures not only needs to do smart things, it needs to be interactive and configurable.

Plus, as always, a lot of small tweaks have happened!

See the changelog for a complete list of improvements.

Flex-model

As you might know, FlexMeasures has ways to configure flexibility in the given assets - the flex-model and flex-context . The flex-context has been configurable on the asset via a UI dialogue since version 0.25 (and not only via the API when scheduling). Now, the flex-model also is supported.

This screenshot probably says more than a thousand words:

You can specify in this dialogue how any schedule needs to treat this asset. Here, state of charge (SoC) settings matter a lot - it is a heat buffer. Charging Efficiency is 300% ― a COP of 3.

As with the flex-context, many settings can be dynamic. In essence, they can be sensors. For example, the SoC Min setting can be a sensor, so you can plan different flexibility headrooms for different days of the week (an office can be cold in the weekend, so the heat storage has more flex to "play" with in the scheduling). Often, forecasts are instrumental in such dynamic settings, and we will have a major update on those in v0.30!

This work was done in Pull Requests 1429, 1565 and 1713. (the PR IDs tell you that we needed to work on this a long time, as it touches the core of scheduling, and we took care of migrating older attributes that were used for similar things beforehand, for backwards compatibility)

Open API / SwaggerUI

The FlexMeasures API is rather rich (and has grown!). It is crucial for integrating FlexMeasures into other systems, i.e. IoT gateways that send data and pull schedules, or custom UIs / dashboards. Or custom client scripts which setup new assets and sensors, for automating the addition and control of sites.

We document the API endpoints via Sphinx, but it would be much more developer-friendly to do that with the OpenAPI standard. In particular, developers want to browse available endpoints on a host, and even try them out live - this is possible with SwaggerUI, which was the originator for what is now OpenAPI, and still the most-used API UI.

This work was done in Pull Request 1703.