View code on Github

v0.20: Faster data reads

highway with long exposure
highway with long exposure Photo by Julian Hochgesang on Unsplash

Version v0.20 of FlexMeasures brings a major speed improvement when reading times series data, which makes loading graphs much faster than before. Other than that, there are power tools for FlexMeasures hosts, more work on flexibility modelling with dynamic times series data and some smaller fixes and improvements.

See the changelog for a complete list. Read on below about the larger new features we added.

Speed

Loading data has been too slow, which was mostly visible when loading charts in the asset and sensor UIs. We found two issues and addressed both, which has led to a major speed improvement. Loading charts now feels more natural.

The improvements actually happened in the data model library timely-beliefs at version 2.1.0, see PRs here and here. We also have been patched this version into FlexMeasures 0.19.2

Power-user tooling for hosts to move assets & data around

Hosting FlexMeasures means to manage accounts, their assets and their data. Sometimes you need some powerful tooling to move things.

  • We introduce a new command to transfer the ownership of an asset and its children to a different account. Example: 
    flexmeasures edit transfer-ownership --asset 1 --account 2
     See Pull Request 983.
  • And it is now simple to delete time series data for an entire site (i.e. with child assets) while keeping its structure, including asset and sensor IDs, intact. We added the --offspring flag to the command flexmeasures delete beliefs which will include the beliefs of the offspring assets' sensors to the list of to-be-removed beliefs. See Pull Request 1003.
  • Also, deleting time series data via the CLI command flexmeasures delete beliefs is much faster now, too. See Pull Request 1005.

Flex info as sensors

In our ongoing effort to describe (most of) our flex-model and flex-context in dynamic settings (instead only constant values), we are still plowing ahead:
  • FlexMeasures now supports the site-consumption-capacity and site-production-capacity fields in the flex-context to be sensors (and thus represent time series) - an interesting use case from (Dutch) reality is a contract with the DSO where your capacity is higher for some hours, e.g. during the night. See Pull Request 985. Here is an example:
    {
    "flex-context": {
        "site-power-capacity": "500 kVA",
        "site-consumption-capacity": {"sensor": 8},
        "site-production-capacity": "400 kW",
    }
}
  • We added the possibility to define SOC (State of Charge) Targets, SOC Maxima and SOC Minima as sensors. For example: "soc-minima": {"sensor" : 300} The existing way of defining those (within API calls) is still supported.
    Why is this useful? Well, these flex-model fields are quite powerful in defining the storage boundaries within which FlexMeasures shall compute the best schedules. Ans these storage boundaries usually come from the user's environment, e.g. as targets for EVs to be charged, comfort-optimized settings for heating or from production planning in an industry setting. Thus, this data is important enough to be stored in its own sensor ― then it can easily be updated from a different data source (e.g. EV logistics system) and be displayed on its own. We believe this makes for a more powerful FlexMeasures :) 
    See Pull Request 996.

Miscellaneous

As we mentioned, there were several smaller but crucial improvements. Some highlights:

  • The unit of non-schedulable (inflexible) sensors had to be MW. Now it can be any power unit, e.g. kW, kWh or MWh, which ever you represent it as. FlexMeasures converts the data when reading it from the database and feeding it to the scheduler. See Pull Request 1007. 
  • FlexMeasures can now be run on MacOS. There were some package installation troubles. This might be quite crucial for developers on MacOS (although they could have used docker compose). See Pull Request 1000.