Energy flexibility dashboard
An interactive web tool that lets companies read from their load profile how much energy cost can be saved by shifting flexible production blocks. The client was Fraunhofer; the project was developed in cooperation with them. Below: a re-built, simplified version of the principle using invented data.
The client was Fraunhofer; the project was developed in cooperation with them. The optimisation model and the subject-matter content come from Fraunhofer, who hold the rights. Source code and original data are confidential and not public; the demo here uses invented data.
Data sheet
| Identification no. | JS-2026-05 |
|---|---|
| Period | Winter semester 2025/26 (submitted 12/2025) |
| Role | Individual project: software architecture and user interface |
| Tools | Python · Streamlit · pandas · NumPy · Plotly · TypeScript · SVG |
| Key result | Interactive simulation of load-shifting potential over a whole year (over 35,000 quarter-hour values per series) |
| Status | Completed (seminar paper, logistics management) |
1Result
Zone B- Cost without optimisation
- 23,453 €
- Cost with optimisation
- 19,490 €
- Saving (year)
- 3,963 €
- Saving relative
- 16.9 %
Year overview: cost per month
Cost after optimisation Saving (stacked on top: full height = cost without optimisation)
Day view: Thursday 31 July
81.70 € → 57.68 € · saving 24.02 €
Dashed: original position. Red: after optimisation. The curve above is the electricity price of this day.
2Problem and motivation
Zone CWith the expansion of wind and solar power, energy prices have turned from a stable planning figure into a fluctuating risk; supply and prices change within hours. Energy flexibility means adjusting consumption to supply without endangering production targets. Small and medium-sized companies in particular have load profile data but no tools to evaluate it systematically: existing solutions are mostly too complicated or too theoretical for everyday use. The dashboard is meant to close that gap.
3Set-up
Zone D- 01Requirements: kick-off, interactivity, performance
- 02Framework choice: React, Plotly Dash, Streamlit
- 03Architecture: model, view, controller
- 04Interface: info, best practice, tools, contact
- 05Performance: caching and vectorisation
The project began with a kick-off meeting that set the requirements: users should be able to change parameters such as shift duration or price assumptions and see updated results immediately; the software should be cleanly built, fast and easy to use; and the simulation runs over a whole year in quarter-hour values (4 × 24 × 365 = 35,040 points per series). Three approaches were compared: React with Node.js (maximum design freedom, but high development and maintenance effort), Plotly Dash (built for visualisation, slower and less flexible for pages with a lot of text and images) and Streamlit. Streamlit was chosen: seamless connection to pandas, the whole development in Python, fast iteration and good documentation. The optimisation model and the subject-matter content were provided by Fraunhofer; my focus was the software architecture and the user-centred interface.
4Verification
Zone EVerification here mostly meant performance: users should not have to wait after changing a parameter. Two mechanisms take care of that. An adapter between interface and calculation core keeps results and input data in memory (caching), and the session state remembers results and the active page across page changes. At start-up a progress bar loads the large data sets in the background, so the pages open without delay afterwards.
5Insight and next iteration
Zone F- Separation of concerns (model-view-controller): the calculation core knows nothing about the interface, each page is its own file and an adapter mediates in between. That keeps the code clear and the parts independent.
- Progressive disclosure: the aggregated year overview first, details on demand through expanders and popovers. This way the user is not overwhelmed by a wall of text.
- Honest charts: instead of artificially scaling savings, the saving is stacked on top of the optimised cost, so the total height equals the original cost. Small savings stay visible without distorting proportions. The day view opens directly on the day with the largest saving.
Possible next iteration
The dashboard is designed as an extensible platform; further flexibility measures and scenarios can be added as extra modules in the calculation core without rebuilding the interface.
Technical details: Project structure and data flow
app.py is the deliberately minimal entry point: it builds the navigation (sidebar) and loads the matching page, without calculation logic. A session variable remembers the active page because Streamlit re-runs the script on every interaction.
The interface has four pages: info and best practice (static content with call-to-action buttons), tools (simulation with year and day view) and contact (form, technically separated from the rest). The tools page never accesses files or the calculation core directly but asks the adapter.
The adapter wraps calls in caching functions. Behind it sits the calculation logic: a data loader (read files, convert types) and the optimiser as a plain Python class without Streamlit code. Passwords for mail sending are kept in a protected configuration file and not in the code.