Welcome to the FlexMeasures documentation!

FlexMeasures is the intelligent & developer-friendly EMS to support real-time energy flexibility apps, rapidly and scalable.

The problem it helps you to solve is: What are the best times to run flexible assets, such as batteries or heat pumps?

In a nutshell, FlexMeasures turns data into optimized schedules for flexible assets. Why? Planning ahead allows flexible assets to serve the whole system with their flexibility, e.g. by shifting energy consumption to more optimal times. For the asset owners, this creates CO₂ savings but also monetary value (e.g. through self-consumption, dynamic tariffs and grid incentives).

https://raw.githubusercontent.com/FlexMeasures/screenshots/main/architecture/simple-flexEMS.png

FlexMeasures is written in Python, and runs on Flask and Postgres. We aim to create developer-friendly technology that saves time in developing complex services. Read more on this in Why FlexMeasures adds value for software developers.

FlexMeasures proudly is an incubation project at the Linux Energy Foundation.

A quick glance

The main purpose of FlexMeasures is to create optimized schedules. Let’s have a quick glance at what that looks like in the UI and what a code implementation would be like:

https://raw.githubusercontent.com/FlexMeasures/screenshots/main/tut/toy-schedule/asset-view-without-solar.png

A short explanation of the optimization shown above: This battery is optimized to buy power cheaply and sell it at expensive times - the red-dotted line is what FlexMeasures computed to be the best schedule, given all knowledge (in this case, the prices shown in blue). However, in the example in the middle tab, the battery has to store local solar power as well (orange line), which constrains how much it can do with its capacity (that’s why the schedule is limited in capacity and thus cycling less energy overall than on the left).

Want to read more about the example case shown here? We discuss this in more depth at Toy example I: Scheduling a battery, from scratch and the tutorials that build on that.

What FlexMeasures does

  • Scheduling

    The main purpose of FlexMeasures is to create optimized schedules. That’s also what the “quick glance” section above focuses on. Everything else supports this main purpose. FlexMeasures provides in-built schedulers for storage and processes. Schedulers solve optimization problems for you and are highly customizable to the situation at hand. Read more at Scheduling and, for hands-on introductions, at Toy example I: Scheduling a battery, from scratch and Toy example III: Computing schedules for processes.

  • Reporting

    FlexMeasures needs to give users an idea of its effects and outcomes. For instance, computing the energy costs are an important use case. But also creating intermediate data for your scheduler can be a crucial feature (e.g. the allowed headroom for a battery is the difference between the grid connection capacity and the PV power). Read more at Reporting and Toy example IV: Computing reports.

  • Forecasting

    Optimizing the future (by scheduling) requires some predictions. Several predictions can be gotten from third parties (e.g. weather conditions, for which we wrote a plugin), others need to be done manually. FlexMeasures provides some support for this (read more at Forecasting and Forecasting & scheduling), but you can also create predictions with one of the many excellent tools out there and feed them into FlexMeasures.

  • Monitoring

    As FlexMeasures is a real-time platform, processing data and computing new schedules continuously, hosting it requires to be notified when things go wrong. There is in-built Error monitoring for tracking connection problems and tasks that did not finish correctly. Also, you can connect to Sentry. We have further plans to monitor data quality.

Use cases & Users

Here are a few relevant areas in which FlexMeasures can help you:

  • E-mobility (smart EV charging, V2G, V2H)

  • Heating (heat pump control, in combination with heat buffers)

  • Industry (best running times for processes with buffering capacity)

You decide what to optimize for ― prices, CO₂, peaks.

It becomes even more interesting to use FlexMeasures in integrated scenarios with increased complexity. For example, in modern domestic/office settings that combine solar panels, electric heating and EV charging, in industry settings that optimize for self-consumption of local solar panels, or when consumers can engage with multiple markets simultaneously.

In these cases, our goal is that FlexMeasures helps you to achieve “value stacking”, which is often required to achieve a positive business case. Multiple sources of value can combine with multiple types of assets.

Where to start reading?

You (the reader) might be a user connecting with a FlexMeasures server or working on hosting FlexMeasures. Maybe you are planning to develop a plugin or even core functionality. Maybe you are a CTO looking for a suitable open source framework.

In Getting started, we have some helpful tips how to dive into this documentation!

flexmeasures.api

FlexMeasures API routes and implementations.

flexmeasures.app

Starting point of the Flask application.

flexmeasures.auth

Authentication and authorization policies and helpers.

flexmeasures.cli

CLI functions for FlexMeasures hosts.

flexmeasures.data

Models & schemata, as well as business logic (queries & services).

flexmeasures.ui

Backoffice user interface & charting support.

flexmeasures.utils

Utilities for the FlexMeasures project.