This article was originally posted at FlexMeasures
Version 0.19 of FlexMeasures has a few minor improvements, each of which might mean a lot to someone. We’ll focus on our first steps into nested asset structures, as it is visual and part of FlexMeasures’ strategic roadmap.
See the changelog for a complete list. Read on below about the larger new features we added.
UI NAVIGATION OF NESTED SITES
Behind the scenes, we work with more complex asset structures. We have introduced the capability of assets being the child of another asset. Now, tree-like structures can be built (where sensors are the leaves, usually) in order to model whole sites or different scenarios for simulation projects.
This also calls for efforts to navigate this structures. We are looking to develop a visual representation of this tree-structure. But until we get there, we made it easier to navigate the structure.
(Note: We actually started work on this in v0.18, but now we have a more complete picture)
First, we introduced a breadcrump-bar above the asset and sensor pages. This example has the account, the asset and the currently shown sensor:
Second, we added a drop-down on the last breadcrump, should there be a lot of child assets. Highly useful for navigating charging hubs:
Third, we added a list of child assets to each asset page:
This work was done in Pull Request 930, 967 and 977.
We believe this is useful for everyone, even if your site is small and you optimize only one asset, but you still have other (inflexible) ones.
However, the next steps will be to make sure the in-built schedulers can be told to optimise an asset structure with multiple flexible assets, like a charging hub. At Seita, we are working on this internally at the moment on a few projects.
MISCELLANEOUS
As we mentioned, there were several smaller but crucial improvements. Some highlights:
- SoC-minima and maxima as ranges: It’s now much easier for developers to tell FlexMeasures (via the flex-model in API requests) that minima and maxima of storage levels should be kept for whole ranges of time points, see Pull Request 899.
- Support for ARM-based processors (e.g. Macbooks). Some installations, like docker compose, would not build correctly on MacBooks or Raspberry Pis. We believe we have found a fix, see Pull Request 956.
- Support SQLAlchemy 2.0 – an important library for data modeling in Python, which we use in many many places changes its syntax. So this was an important chore, to be able to stay up to data, see Pull Request 938.
- Support Flask 2.3 – this also holds for Flask. The changes we needed to make here were not that many, but it’s crucial chore work. See Pull Request 907.
