View code on Github

v0.25: flex context fully editable, nicer status page 

Setting a value for site power capacity in the new flex-context editing dialogue
Setting a value for site power capacity in the new flex-context editing dialogue

Version v0.25 of FlexMeasures supports editing the flex-context on an asset (instead of sending it each time a schedule is triggered). This can improve interactions for developers, but also service desk personnel! Also, we improved the status page.

See the changelog for a complete list of improvements.

Let's dive int the two main features!

Fully editable flex context

Behind-the-meter orchestration can become a complex problem, with multiple optimization goals potentially competing. We talked about this in the blog post about the 0.24 release, as well.

The flex-context is very important way to describe contraints and optimization goals (and is accompanied by the flex-model).

Editing the flex context in the new modal dialogue
Editing the flex context in the new dialogue

We extended the flex-model and now it is time to make it possible to add it to the data model. The current only way to specify this information is with every call to API or CLI when requesting FlexMeasures to compute a new schedule.

For developers, this might make it easier (less work on coding requests), but also this opens possibilities for maintaining this information by somebody else than developers. Maybe service personnel can now update these fields (which will be logged in the audit log :), or installers do that by themselves?

This work was done in Pull Requests 1293 and 1320, and several smaller follow-ups..

Nicer status page

The status page is also a feature meant to increase the serviceability of FlexMeasures. You can see when the latest data entries for sensors came in, what jobs (scheduling, forecasting) happend recently and if they failed.

However, the page could be more useful. The first iteration on this since more than six months cleans the page visually, and separates the rows per data source types.

Forecasts and schedules for a power sensor are about the future, after all, while the measurements are about the past. Obviously, the traffic light needs to reflect what kind of source the data comes from - we expect forecasts to always be available into the future, while measurements (which are used in forecasts and schedules) are not, but should also not be too old.

Status page, now differentiated by data source type
Status page, now differentiated by data source type

Next work on the status page will address its speed, which still seems underwhelming if there is much data, and enable to select which sensors should be shown.

This work was done in Pull Request 1022.