Grafana für Energiedaten: Netzdaten in Erkenntnisse verwandeln

Der Energiesektor basiert auf Daten, aber Rohdaten allein reichen nicht aus. Netzbetreiber, Versorgungsunternehmen und Energy-Technology-Teams benötigen eine Möglichkeit, Zeitreihensignale, Marktinformationen und Netzereignisse in klare operative Erkenntnisse zu übersetzen. Genau hier kommt Grafana ins Spiel.

In diesem Beitrag zeigen wir, wie wir Grafana nutzen, um Energie-Dashboards für Deutschland zu erstellen – mit öffentlichen Strom-APIs, Python für Ingestion und Transformation, Docker für ein reproduzierbares Deployment-Setup sowie PostgreSQL mit TimescaleDB für schnelle Zeitreihenspeicherung und Abfragen. Diese Kombination schafft eine praxisnahe Architektur, mit der fragmentierte Stromsystemdaten in visuelle Analysen verwandelt werden können, die für Ingenieure, Analysten, Betreiber und Stakeholder nützlich sind.

Ein modernes Energie-Dashboard muss mehrere Arten von Informationen gleichzeitig zusammenführen: Erzeugung nach Quelle, Verbrauch und Prognose, Strompreise, Anteil erneuerbarer Energien und grenzüberschreitende Stromflüsse. Diese Signale sind zeitbasiert, stammen häufig aus unterschiedlichen Systemen und müssen gemeinsam interpretiert werden, nicht isoliert voneinander. Deshalb eignet sich Grafana besonders gut für den Energiebereich.

Was ist Grafana?

Grafana ist eine Open-Source-Plattform für Visualisierung und Dashboarding, mit der Teams Daten aus vielen unterschiedlichen Quellen abfragen, visualisieren, überwachen und explorieren können. Dashboards in Grafana bestehen aus Panels, die Rohdaten in visuelle Ansichten wie Zeitreihendiagramme, Tabellen, Heatmaps und Stat-Panels umwandeln.

Hinter Grafana stehen drei zentrale Konzepte:

• Datenquellen
  Das sind die Systeme, mit denen Grafana verbunden wird, zum Beispiel PostgreSQL, TimescaleDB, Prometheus oder Elasticsearch. In unserem Fall ist PostgreSQL die wichtigste Datenquelle.
• Panels
  Ein Dashboard besteht aus visuellen Komponenten wie Liniendiagrammen, gestapelten Flächendiagrammen, Heatmaps, Stat-Cards, Tabellen und Donut-Charts. Jedes Panel führt eine Abfrage aus und stellt das Ergebnis so dar, dass es für Entscheidungen nutzbar wird.
• Dashboards
  Ein Dashboard ist eine Sammlung von Panels, die um einen geschäftlichen oder operativen Anwendungsfall herum angeordnet sind. Dashboards können vollständig angepasst und auf jede Branche, jedes Team oder jede Anforderung zugeschnitten werden. Im Energiebereich bedeutet das, dass dieselbe Grafana-Plattform Markt-Dashboards, Prognoseansichten für erneuerbare Energien, Bildschirme für den Netzbetrieb oder Executive Reporting unterstützen kann.

Das ist wichtig, weil die Visualisierung von Stromnetz- und Energiemarktdaten nicht trivial ist. Die Herausforderung liegt nicht nur in der Datenmenge, sondern auch in ihrer Struktur. Energiedaten sind zeitbasiert, häufig geografisch und stark beeinflusst von Zustandsänderungen, Wetterbedingungen, grenzüberschreitenden Interaktionen und Marktsignalen. Ein nützliches Dashboard muss diese Perspektiven an einem Ort zusammenführen. Grafana eignet sich dafür sehr gut, weil es verschiedene Visualisierungstypen in derselben Oberfläche unterstützt und natürlich mit Zeitreihen- und SQL-basierten Daten arbeitet.

Bei Kickstage betrachten wir Grafana nicht als alleinstehendes Charting-Tool, sondern als Teil einer umfassenderen Softwarearchitektur für den Energiesektor. Öffentliche oder interne Netzdaten können in PostgreSQL oder TimescaleDB aufgenommen, mit technischer oder marktbezogener Logik in Python angereichert und anschließend in Grafana-Dashboards für Analyse und Betrieb bereitgestellt werden.

Die Architektur hinter den Dashboards

Der gesamte Systemablauf ist einfach und effektiv: Öffentliche API-Daten werden von Python-Ingestion-Skripten abgerufen, in PostgreSQL und TimescaleDB geladen und von Grafana abgefragt.

Systemübersicht

• SMARD API
  Öffentliche deutsche Energiedaten mit 15-Minuten-Auflösung von der Bundesnetzagentur.
• Fraunhofer Energy-Charts API
  Erweiterte Energiedaten, einschließlich Lastanalyse, installierter Leistung und grenzüberschreitender Flüsse vom Fraunhofer ISE.
• Python-Ingestion-Skripte
  Abrufen, Transformieren, Validieren und Laden von Daten.
• PostgreSQL + TimescaleDB
  Zeitreihenspeicherung mit Hypertables, Voraggregation und Kompression.
• Grafana
  Dashboards, Diagramme, Tabellen, Heatmaps und optionales Alerting.

Diese Architektur funktioniert gut, weil sie Verantwortlichkeiten klar trennt. Python übernimmt Datenerfassung und Transformation, PostgreSQL und TimescaleDB bieten robuste Speicherung und effiziente Abfragen, und Grafana wird zur Oberfläche, über die Nutzer die Daten explorieren.

Warum wir Python verwendet haben

Python bildet in diesem Setup die Ingestion- und Transformationsschicht. Das ist bei Energieprojekten sinnvoll, weil der Engpass normalerweise nicht rohe CPU-Leistung ist, sondern externe API-Aufrufe, Validierung, Wiederholungslogik, Timestamp-Handling und sichere Datenbank-Schreibvorgänge.

In unserem Projekt übernimmt die Python-Ingestion-Schicht die operativen Details, die in der Praxis wichtig sind:

• Rate Limiting, um die API nicht zu überlasten
• Retry-Logik mit exponentiellem Backoff bei Fehlern
• Datenvalidierung für Nullwerte oder ungültige Werte
• Timestamp-Konvertierung von Unix-Millisekunden zu Python datetime
• Paralleles Abrufen mehrerer Filter
• Inkrementelle Updates, sodass nur neue Daten aufgenommen werden
• Fehlerbehandlung, die partiellen Fortschritt ermöglicht
• Logging für Transparenz und Troubleshooting
• Idempotente Upsert-Logik, damit die Pipeline sicher erneut ausgeführt werden kann

Python bietet uns eine wartbare Möglichkeit, Datenpipelines zu bauen, die leicht zu testen, zu erweitern und zu betreiben sind. Außerdem funktioniert Python sehr gut mit Batch-Inserts und Upsert-Logik – genau das, was man für wiederkehrende Dashboard-Aktualisierungen benötigt.

Über die Datenquellen

SMARD API (Bundesnetzagentur)

Die SMARD API wird von der deutschen Bundesnetzagentur bereitgestellt und dient als primäre Quelle für Echtzeit- und historische Strommarktdaten. SMARD steht für „Strommarktdaten“ und bietet:

• Erzeugungsdaten nach Quelle: Wind, Solar, Biomasse, Kernenergie, fossile Energieträger wie Kohle, Gas und Öl, Wasserkraft und Pumpspeicher mit 15-Minuten-Auflösung
• Verbrauchs- und Prognosedaten: tatsächlicher Stromverbrauch und prognostizierte Last
• Day-Ahead-Strompreise: Marktpreise in EUR/MWh von der European Power Exchange (EPEX)
• Grenzüberschreitende Austauschflüsse: Stromimporte und -exporte mit Nachbarländern wie Frankreich, Österreich, Schweiz, Polen, Tschechien, Dänemark, Schweden, Niederlande und Luxemburg

Die SMARD API ist besonders wertvoll, weil sie offizielle, maßgebliche Daten direkt vom Netzregulator bereitstellt. Die Daten werden kontinuierlich aktualisiert und repräsentieren tatsächliche operative Messwerte der deutschen Übertragungsnetzbetreiber. Die API verwendet ein filterbasiertes System, bei dem jede Datenreihe durch eine numerische Filter-ID identifiziert wird. Zum Beispiel steht Filter 410 für den tatsächlichen Stromverbrauch, während Filter 411 den prognostizierten Verbrauch darstellt.

Fraunhofer Energy-Charts API

Die Fraunhofer Energy-Charts API wird vom Fraunhofer-Institut für Solare Energiesysteme ISE bereitgestellt und bietet ergänzende Daten mit zusätzlichen analytischen Perspektiven:

• Installierte Leistung: historische und aktuelle Erzeugungskapazität nach Technologie und Jahr, einschließlich geplanter Leistung im Rahmen des EEG
• Last- und Residuallastanalyse: Gesamtstromnachfrage und Residuallast, also Nachfrage minus Wind- und Solarerzeugung, wodurch sichtbar wird, welcher Anteil durch disponierbare Erzeugung gedeckt werden muss
• Solarerzeugungsprognosen: Vergleich von tatsächlicher und prognostizierter Solarleistung zur Analyse der Prognosegenauigkeit
• Grenzüberschreitende physische Flüsse und Handel: detaillierte Import-/Exportdaten mit Nachbarländern, inklusive Unterscheidung zwischen physischen Stromflüssen und kommerziellen Handelsvolumina
• Momentaufnahmen der öffentlichen Stromerzeugung: aktuelle Aufschlüsselung des Erzeugungsmixes für Echtzeit-Monitoring

Die Energy-Charts API erweitert SMARD-Daten um forschungsorientierte Metriken, die besonders hilfreich sind, um Deutschlands Energiewende zu verstehen. Die Daten zur installierten Leistung liefern zum Beispiel strukturelle Einblicke darin, wie sich das Erzeugungspotenzial des Netzes über zwei Jahrzehnte entwickelt hat – Informationen, die die operativen Erzeugungsdaten aus SMARD ergänzen.

Zusammen bieten diese beiden APIs einen umfassenden Blick auf das deutsche Stromsystem: SMARD deckt operative und marktbezogene Daten mit hoher zeitlicher Auflösung ab, während Energy-Charts strukturelle, prognosebezogene und grenzüberschreitende Handelsperspektiven ergänzt. Beide APIs sind öffentlich zugänglich, gut dokumentiert und für programmatischen Zugriff ausgelegt, was sie zu idealen Grundlagen für produktionsreife Energie-Dashboards macht.

Warum wir PostgreSQL und TimescaleDB verwendet haben

Wir haben PostgreSQL mit TimescaleDB verwendet, weil es sich im Kern um ein Zeitreihenanalyseproblem handelt. Energie-Dashboards fragen Daten wiederholt nach Zeitfenstern ab: die letzten 24 Stunden, die letzte Woche, ein Monatsmuster, eine stündliche Heatmap oder einen historischen Trend erneuerbarer Energien.

TimescaleDB verbessert dies, indem es Zeitreihenfunktionen auf PostgreSQL aufsetzt und gleichzeitig die Einfachheit und das Ökosystem von SQL beibehält.

Speicherdesign

Das System enthält mehrere zentrale Tabellen:

• generation_data
  Speichert MW-Erzeugung pro 15-Minuten-Intervall nach Quellentyp.
• consumption_data
  Speichert tatsächliche Nachfrage und prognostizierte Nachfrage.
• price_data
  Speichert Strompreisdaten in EUR/MWh.
• exchange_data
  Speichert grenzüberschreitende Flüsse, wobei positive und negative Werte Importe und Exporte darstellen.

Für Performance verwenden wir außerdem materialisierte Views und Voraggregationsmuster.

Verwendete TimescaleDB-Funktionen

• Hypertables für automatische zeitbasierte Partitionierung
• Chunk-Größe von einem Tag
• Schnellere Performance bei Zeitbereichsabfragen
• Parallele Abfrageausführung
• Optionale Kompression älterer Chunks
• Deutliche Speicherreduktion für historische Daten

Wir haben TimescaleDB aus drei Hauptgründen verwendet:

• Es verbessert die Performance von Zeitbereichsabfragen für Dashboard-Workloads
• Es skaliert besser als einfache relationale Tabellen für kontinuierlich wachsende historische Energiedaten
• Es unterstützt produktionsfreundliche Funktionen wie Kompression, Hypertables und Voraggregation

Das ist wichtig, weil sich Grafana-Dashboards interaktiv anfühlen sollten. Selbst wenn Nutzer auf mehrere Monate Daten herauszoomen, müssen Panels schnell laden.

Zwei mit Grafana erstellte Energie-Dashboards für Deutschland

In diesem Beitrag haben wir Grafana verwendet, um Dashboards zu erstellen, die das Verhalten des deutschen Stromsystems mithilfe von zwei öffentlichen APIs visualisieren. Zusammen zeigen diese Dashboards, wie Grafana öffentliche Netz- und Marktdaten in operative Erkenntnisse verwandeln kann.

1. Germany Power Mix & Price Dashboard

Das erste Dashboard konzentriert sich auf Erzeugungsmix, Nachfrage, Prognosen, Großhandelsstrompreise, Anteil erneuerbarer Energien und grenzüberschreitende Abhängigkeit.

Verwendete APIs

Dieses Dashboard basiert primär auf der SMARD API. Im größeren Projekt unterstützen wir außerdem optionale Anreicherungen aus der Fraunhofer Energy-Charts API.

Das Muster ist klar: Python ruft die Daten ab und validiert sie, PostgreSQL speichert sie, und Grafana fragt sie ab, um Dashboards zu erstellen.

Business Use Case

Dieses Dashboard kann verwendet werden, um Marktverhalten, den Anteil erneuerbarer Energien, Preisvolatilität und Import-/Exportabhängigkeiten zu erklären. Es eignet sich für interne Analysen, Innovationsdemos, öffentlich zugängliche Energieeinblicke oder als Grundlage für ein fortgeschritteneres operatives Dashboard.

Grafana ist dafür gut geeignet, weil Panels Rohdaten abfragen und in Visualisierungen transformieren, und weil Grafana SQL-Quellen wie PostgreSQL direkt abfragen kann.

Widget 1: Nachfrage vs. Prognose

Dieses Panel vergleicht die tatsächliche Stromnachfrage mit der prognostizierten Nachfrage im Zeitverlauf. Es hilft Nutzern zu verstehen, ob die reale Last den Erwartungen folgt oder davon abweicht.

1SELECT
2  date_trunc('hour', timestamp) AS time,
3  AVG(consumption_mw) AS "Actual",
4  AVG(forecast_mw) AS "Forecast"
5FROM consumption_data
6WHERE $__timeFilter(timestamp)
7GROUP BY 1
8ORDER BY 1;
9

In Grafana speist diese Abfrage ein Zeitreihen-Panel, in dem die tatsächliche Nachfrage als eine Linie und die prognostizierte Nachfrage als zweite Linie dargestellt wird. Dadurch sind Abweichungen visuell leicht zu erkennen.

Widget 2: Erzeugungsmix im Zeitverlauf (gestapelt)

Das Widget „Generation Mix Over Time“ zeigt, wie jede Erzeugungstechnologie im Zeitverlauf zur Gesamtversorgung beiträgt.

Diese Visualisierung zeigt die dynamische Natur des Energiesystems: wie Solarerzeugung zur Mittagszeit ihren Höhepunkt erreicht und nachts auf null fällt, wie Wind mit Wetterbedingungen schwankt und wie konventionelle Erzeugung wie Gas, Kohle und Kernenergie Lücken füllt, die durch intermittierende erneuerbare Energien entstehen. Die gestapelte Ansicht macht leicht erkennbar, ob das Netz gerade sauber läuft oder stark auf fossile Brennstoffe angewiesen ist.

1SELECT
2  date_trunc('hour', timestamp) AS time,
3  source_type AS metric,
4  AVG(generation_mw) AS value
5FROM generation_data
6WHERE $__timeFilter(timestamp)
7GROUP BY 1, 2
8ORDER BY 1, 2;

Das funktioniert in Grafana besonders gut, weil die Spalte metric zu einer separaten visuellen Serie wird und das Panel dadurch ein gestapeltes Zeitreihendiagramm rendern kann.

Dieses Panel ist wertvoll, weil es eine vollständige Geschichte über die Angebotsseite erzählt: wie Solar tagsüber ansteigt, wie Wind sich im Zeitverlauf verändert und wie konventionelle Erzeugung den Rest abdeckt.

Widget 3: Stündliche Preis-Heatmap

Die stündliche Preis-Heatmap verwandelt Day-Ahead-Preisdaten in eine farbcodierte Ansicht der Preisintensität. Anders als Zeitreihendiagramme, die Preisänderungen chronologisch zeigen, machen Heatmaps wiederkehrende Muster nach Tagesstunde und Wochentag oder Monat sichtbar. Dadurch lassen sich strukturelle Marktverhalten leicht erkennen: wann Preise regelmäßig hoch sind, etwa in Abendspitzen, wann sie niedrig sind, etwa durch starke Solarproduktion zur Mittagszeit, und wie sich Wochenenden von Werktagen unterscheiden. Energiehändler, Scheduler und Demand-Response-Betreiber nutzen Heatmaps, um Arbitragemöglichkeiten zu erkennen und Verbrauchsmuster zu optimieren.

1SELECT
2  timestamp AS time,
3  EXTRACT(HOUR FROM timestamp) AS "Hour of Day",
4  price_eur_mwh
5FROM price_data
6WHERE $__timeFilter(timestamp)
7  AND market_type = 'day_ahead_price'
8ORDER BY 1;

Grafana nutzt dieses Ergebnis, um eine Heatmap zu rendern, in der wärmere Farben höhere Preisniveaus anzeigen. Hotspots häufen sich oft am frühen Abend, insbesondere zwischen 19:00 und 21:00 Uhr, wenn die Nachfrage hoch bleibt, während die Solarleistung bereits abgefallen ist.

Diese Art von Panel ist leistungsfähig, weil sie wiederkehrende Marktstrukturen zeigt und nicht nur isolierte Preisspitzen.

2. Energy-Charts-Dashboard mit der Fraunhofer Energy-Charts API

Das zweite Dashboard basiert auf der Fraunhofer Energy-Charts API.

Dieses Dashboard erweitert die analytische Sicht um zusätzliche Daten wie Residuallast, Solarprognosevergleich, grenzüberschreitende physische Flüsse und Erzeugungs-Snapshots.

Widget: Last vs. Residuallast

Dieses Widget zeigt Gesamtlast und Residuallast im selben Panel.

Residuallast ist in Stromsystemen besonders wichtig, weil sie die Nachfrage darstellt, nachdem Wind- und Solarerzeugung berücksichtigt wurden. Anders gesagt: Sie zeigt den Teil der Nachfrage, der weiterhin durch konventionelle Erzeugung, Speicher oder Importe gedeckt werden muss. Mit steigendem Anteil erneuerbarer Energien wird die Residuallast zur Schlüsselkennzahl, um zu verstehen, welche disponierbare Kapazität tatsächlich benötigt wird. Eine niedrige oder negative Residuallast bedeutet, dass erneuerbare Energien den größten Teil oder die gesamte Nachfrage decken, während eine hohe Residuallast bedeutet, dass konventionelle Kraftwerke deutlich hochfahren müssen.

1SELECT
2  timestamp AS time,
3  series_name AS metric,
4  value
5FROM energy_charts_series
6WHERE endpoint = 'public_power'
7  AND series_name IN ('load', 'residual_load')
8  AND $__timeFilter(timestamp)
9ORDER BY 1;

In Grafana funktioniert dies als Zeitreihen-Panel mit Multi-Series-Hover-Tooltips, sodass beide Linien zum gleichen Zeitpunkt verglichen werden können. Die sichtbare Lücke zwischen Gesamtlast und Residuallast zeigt den Beitrag von Wind und Solar in Echtzeit: Wenn die Lücke groß ist, leisten erneuerbare Energien einen hohen Beitrag; wenn sie kleiner wird, hängt das Netz stärker von disponierbaren Quellen ab. Diese Kennzahl ist wesentlich, um den Duck-Curve-Effekt zu verstehen und flexible Erzeugungsressourcen zu planen.

Widget: Solar tatsächlich vs. Prognose

Dieses Widget vergleicht tatsächliche Solarerzeugung mit prognostizierter Solarerzeugung. Solarprognosen sind anspruchsvoll, weil Bewölkung, atmosphärische Transparenz und Temperatur die Leistung beeinflussen und diese Faktoren über mehrere Stunden hinaus schwer präzise vorherzusagen sind. Dieses Panel ermöglicht Netzbetreibern und Betreibern erneuerbarer Anlagen, die Prognosequalität zu bewerten und zu verstehen, wann Vorhersagen zuverlässig sind und wann sie deutlich abweichen. Anhaltende Prognosefehler können auf Probleme bei der Modellkalibrierung, saisonale Verzerrungen oder Änderungen der installierten Leistung hinweisen, die nicht in der Prognosebasis berücksichtigt sind.

1SELECT
2  timestamp AS time,
3  CASE
4    WHEN endpoint = 'public_power' THEN 'solar_actual_mw'
5    ELSE 'solar_forecast_mw'
6  END AS metric,
7  value
8FROM energy_charts_series
9WHERE $__timeFilter(timestamp)
10  AND (
11    (endpoint = 'public_power' AND series_name = 'solar')
12    OR (endpoint = 'public_power_forecast' AND series_name = 'solar_forecast_mw')
13  )
14ORDER BY 1;

Im Dashboard wird die tatsächliche Serie als durchgezogene Linie und die Prognoseserie als gestrichelte Linie dargestellt. Dadurch werden Prognosefehler visuell sofort sichtbar, und das Panel wird zu einem nützlichen operativen Vergleich statt nur zu einem allgemeinen Diagramm.

Widget: Installierte Leistung nach Technologie (jährlich, GW) – gestapeltes Balkendiagramm

Eine der sehr wirkungsvollen Visualisierungen zum Verständnis der deutschen Energiewende ist das Diagramm zur installierten Leistung. Anders als Erzeugungsdaten, die zeigen, was das Netz zu einem bestimmten Zeitpunkt produziert, zeigt die installierte Leistung das strukturelle Potenzial des gesamten Stromsystems – also die maximale verfügbare Erzeugungsfähigkeit jeder Technologie.

Dieses Widget zeigt, wie sich die deutsche Stromerzeugungsinfrastruktur in den letzten zwei Jahrzehnten entwickelt hat, und macht zentrale Trends sichtbar, etwa den Ausstieg aus der Kernenergie, den Ausbau erneuerbarer Energien und Veränderungen bei fossilen Kapazitäten.

Die SQL-Abfrage

Dieses Panel verwendet eine SQL-Abfrage, die Zeitreihendaten in ein Format pivotiert, das für gestapelte Balkendiagramme geeignet ist:

1WITH latest AS (
2  SELECT MAX(timestamp) AS ts
3  FROM energy_charts_series
4  WHERE endpoint = 'installed_power'
5),
6raw_data AS (
7  SELECT
8    (regexp_match(e.series_name, '^(.*)_([0-9]{4})$'))[2] AS year_str,
9    (regexp_match(e.series_name, '^(.*)_([0-9]{4})$'))[1] AS technology,
10    e.value
11  FROM energy_charts_series e
12  INNER JOIN latest l ON e.timestamp = l.ts
13  WHERE e.endpoint = 'installed_power'
14    AND e.series_name ~ '_[0-9]{4}$'
15)
16SELECT
17  year_str AS "Year",
18  SUM(CASE WHEN technology = 'biomass' THEN value END) AS "Biomass",
19  SUM(CASE WHEN technology = 'fossil_brown_coal_lignite' THEN value END) AS "Fossil Brown Coal",
20  SUM(CASE WHEN technology = 'fossil_hard_coal' THEN value END) AS "Fossil Hard Coal",
21  SUM(CASE WHEN technology = 'fossil_gas' THEN value END) AS "Fossil Gas",
22  SUM(CASE WHEN technology = 'fossil_oil' THEN value END) AS "Fossil Oil",
23  SUM(CASE WHEN technology = 'hydro' THEN value END) AS "Hydro",
24  SUM(CASE WHEN technology = 'hydro_pumped_storage' THEN value END) AS "Hydro Pumped Storage",
25  SUM(CASE WHEN technology = 'nuclear' THEN value END) AS "Nuclear",
26  SUM(CASE WHEN technology = 'other_non_renewable' THEN value END) AS "Other Non-Renewable",
27  SUM(CASE WHEN technology = 'solar_ac' THEN value END) AS "Solar AC",
28  SUM(CASE WHEN technology = 'solar_dc' THEN value END) AS "Solar DC",
29  SUM(CASE WHEN technology = 'wind_offshore' THEN value END) AS "Wind Offshore",
30  SUM(CASE WHEN technology = 'wind_onshore' THEN value END) AS "Wind Onshore",
31  SUM(CASE WHEN technology = 'battery_storage_capacity' THEN value END) AS "Battery Storage Capacity"
32FROM raw_data
33GROUP BY year_str
34ORDER BY year_str ASC;

Wie diese Abfrage funktioniert

Schritt 1: Das neueste Datenbatch finden

Die latest CTE identifiziert den neuesten Ingestion-Timestamp für Daten zur installierten Leistung. Das ist wichtig, weil die Energy-Charts API Snapshot-Daten bereitstellt, die periodisch aktualisiert werden, und wir sicherstellen möchten, dass alle Technologien auf Basis desselben Datenstands verglichen werden.

1WITH latest AS (
2  SELECT MAX(timestamp) AS ts
3  FROM energy_charts_series
4  WHERE endpoint = 'installed_power'
5)

Schritt 2: Technologie und Jahr aus Seriennamen extrahieren

Die Energy-Charts API speichert Daten mit Seriennamen im Format {technology}_{year}, zum Beispiel solar_ac_2015 oder wind_onshore_2023. Wir verwenden die PostgreSQL-Funktion regexp_match, um beide Komponenten zu extrahieren:

1raw_data AS (
2  SELECT
3    (regexp_match(e.series_name, '^(.*)_([0-9]{4})$'))[2] AS year_str,
4    (regexp_match(e.series_name, '^(.*)_([0-9]{4})$'))[1] AS technology,
5    e.value
6  FROM energy_charts_series e
7  INNER JOIN latest l ON e.timestamp = l.ts
8  WHERE e.endpoint = 'installed_power'
9    AND e.series_name ~ '_[0-9]{4}$'
10)

Schritt 3: Die Daten pivotieren

Das finale SELECT-Statement pivotiert Zeilen mithilfe bedingter Aggregation in Spalten. Jeder CASE WHEN-Ausdruck filtert eine bestimmte Technologie, und SUM aggregiert den jeweiligen Wert. Dadurch werden Daten im Long-Format – viele Zeilen, jeweils eine pro Technologie und Jahr – in ein Wide-Format transformiert: eine Zeile pro Jahr, eine Spalte pro Technologie.

Dieses Format entspricht genau dem, was Grafanas Balkendiagramm-Visualisierung erwartet: eine einzelne Dimension, also das Jahr, auf der X-Achse und mehrere Metriken, also jede Technologie, als separate Serien.

Was dieses Widget zeigt

Diese Visualisierung liefert mehrere wichtige Erkenntnisse über die deutsche Energiewende:

1. Atomausstieg
Der stetige Rückgang der Kernenergiekapazität von über 20 GW Anfang der 2000er-Jahre bis zum vollständigen Ausstieg im Jahr 2023 ist als schrumpfender Abschnitt der gestapelten Balken klar sichtbar.

2. Ausbau erneuerbarer Energien
Solar- und Windkapazitäten zeigen ein starkes Wachstum. Solar, sowohl AC als auch DC, wächst von nahezu null im Jahr 2002 auf über 60 GW bis 2023. Wind Onshore wächst im selben Zeitraum von etwa 12 GW auf über 50 GW, während Wind Offshore weitere mehr als 8 GW hinzufügt.

3. Fossiler Übergang
Die Steinkohlekapazität sinkt deutlich, was Deutschlands Bestreben widerspiegelt, kohlebefeuerte Erzeugung zu reduzieren. Gaskapazität bleibt relativ stabil oder wächst leicht und dient als flexible Reserve für intermittierende erneuerbare Energien.

4. Wachstum der Gesamtsystemkapazität
Die Höhe jedes gestapelten Balkens zeigt die gesamte installierte Leistung. Dadurch wird sichtbar, dass das deutsche Netz seine gesamte Erzeugungsfähigkeit deutlich erhöht hat – hauptsächlich getrieben durch erneuerbare Zubauten, die den Rückbau von Kernenergie- und Kohlekapazitäten mehr als ausgleichen.

5. Speicherinfrastruktur
Batteriespeicherkapazität erscheint in den letzten Jahren und signalisiert Deutschlands Investitionen in netzskalierte Energiespeicherung, um die Variabilität erneuerbarer Energien zu managen.

Warum gestapelte Balken für diese Daten gut funktionieren

Wir haben uns aus mehreren Gründen für ein gestapeltes Balkendiagramm entschieden:

• Zusammensetzung im Zeitverlauf: Gestapelte Balken zeigen sowohl die Gesamtkapazität, also die Balkenhöhe, als auch die Aufteilung dieser Gesamtheit nach Technologie, also die farbigen Segmente
• Sichtbarkeit von Trends: Das Wachstum erneuerbarer Energien und der Rückgang konventioneller Erzeugung sind sofort erkennbar
• Vergleichende Analyse: Nutzer können die relative Größe jedes Technologiesegments über verschiedene Jahre hinweg vergleichen
• Kategorische Zeitachse: Jahre sind diskrete Kategorien und keine kontinuierliche Zeitreihe, weshalb Balken geeigneter sind als Linien

Panel-Konfiguration in Grafana

Im Dashboard-JSON ist dieses Panel mit den folgenden zentralen Einstellungen konfiguriert:

• Visualisierungstyp: barchart
• Stacking: auf "normal" gesetzt, sodass alle Technologieserien übereinander gestapelt werden, statt sich zu überlappen
• X-Achse: Jahresbeschriftungen um -45 Grad gedreht, um Überlappungen zu vermeiden und die Lesbarkeit zu verbessern
• Legende: als Tabelle auf der rechten Seite dargestellt, mit der Berechnung "lastNotNull", die den aktuellsten Kapazitätswert jeder Technologie zeigt
• Field Overrides: Das Feld Year wird explizit als String/Kategorie statt als numerischer Wert behandelt, um die korrekte kategoriale Darstellung auf der X-Achse sicherzustellen
• Tooltip: auf "multi"-Modus mit absteigender Sortierung gesetzt, sodass beim Hover über ein Jahr alle Technologien nach Kapazität sortiert angezeigt werden

Hier ist die relevante Konfiguration aus dem Dashboard-JSON:

1{
2  "type": "barchart",
3  "options": {
4    "stacking": "normal",
5    "orientation": "auto",
6    "barWidth": 0.85,
7    "groupWidth": 0.7,
8    "xTickLabelRotation": -45,
9    "legend": {
10      "displayMode": "table",
11      "placement": "right",
12      "showLegend": true,
13      "calcs": ["lastNotNull"]
14    },
15    "tooltip": {
16      "mode": "multi",
17      "sort": "desc"
18    }
19  },
20  "fieldConfig": {
21    "defaults": {
22      "unit": "short",
23      "decimals": 1,
24      "custom": {
25        "axisLabel": "Installed Capacity (GW)",
26        "fillOpacity": 80
27      }
28    },
29    "overrides": [
30      {
31        "matcher": {
32          "id": "byName",
33          "options": "Year"
34        },
35        "properties": [
36          {
37            "id": "unit",
38            "value": "string"
39          }
40        ]
41      }
42    ]
43  }
44}

Diese Konfiguration stellt sicher, dass die Visualisierung sowohl informativ als auch visuell klar ist und Nutzer die Entwicklung der Energieinfrastruktur über Jahrzehnte hinweg auf einen Blick erfassen können.

Weitere nützliche Widgets in diesem Dashboard

Das Energy-Charts-Dashboard enthält außerdem mehrere weitere starke Beispiele für Grafana-Panels im Bereich Energieanalyse:

• Snapshot des Erzeugungsmixes mit einem Donut-Chart
• Grenzüberschreitende physische Flüsse nach Nachbarland in MW
• Grenzüberschreitender Stromhandel nach Nachbarland in MW
• Anteil erneuerbarer Energien an Last und Erzeugung im Zeitverlauf

Wie wir Widgets im Code erstellen

Es gibt zwei praktische Wege, Grafana-Widgets zu erstellen.

Der erste besteht darin, sie als Konfiguration im Dashboard-JSON zu definieren. Das ist nützlich, wenn Dashboards versioniert und als Teil der Anwendung ausgeliefert werden. In diesem Projekt liegen die Dashboards als JSON-Dateien unter grafana/dashboards/, und jedes Panel enthält seine SQL-Abfrage, seinen Visualisierungstyp, Styling, Legendenverhalten und Tooltip-Einstellungen.

Dieser Ansatz ist ideal, wenn reproduzierbare Dashboards gewünscht sind, die in Git committed, automatisch deployed und wie Code überprüft werden können.

Versionierung und Deployment

In unserem Beispiel liegen Dashboards als JSON-Dateien unter grafana/dashboards/.

Grafana ist so konfiguriert, dass Dashboards beim Start automatisch aus diesem Verzeichnis provisioniert werden. Das bedeutet:

• Dashboards werden gemeinsam mit dem Anwendungscode versioniert
• Änderungen können in Pull Requests geprüft werden
• Dashboards werden automatisch mit docker-compose up deployed
• Der gesamte Stack, also Datenbank, Ingestion und Dashboards, kann aus einem einzigen Repository reproduziert werden

Das ist ein erheblicher operativer Vorteil. Traditionelle BI-Tools speichern Dashboards häufig in proprietären Datenbanken oder erfordern manuelle Export-/Import-Workflows. Grafanas JSON-basierter Ansatz macht Dashboards so portabel und überprüfbar wie jedes andere Code-Artefakt.

Wie wir Widgets in der Grafana UI erstellen

Der zweite Ansatz besteht darin, Panels direkt in der Grafana UI zu erstellen. Das ist besonders nützlich während der Exploration oder wenn ein Team ein Panel schnell prototypisieren möchte, bevor es in versioniertes JSON exportiert wird.

Ein typischer Workflow sieht so aus:

1. Grafana öffnen und ein Dashboard erstellen oder öffnen
2. Auf Add panel klicken
3. Die PostgreSQL-Datenquelle auswählen
4. Die SQL-Abfrage einfügen oder erstellen
5. Den Visualisierungstyp auswählen, zum Beispiel Time series, Heatmap, Stat, Table oder Pie chart
6. Legende, Tooltip, Einheiten, Schwellenwerte, Stacking und Linienstile konfigurieren
7. Das Panel speichern und anschließend das Dashboard speichern

add panel in grafana

Warum das für Energieunternehmen wichtig ist

Grafana ist für Energie- und Netzdaten besonders relevant, weil Energiesysteme nicht nur zeitbasiert sind, sondern auch operativ und kontextabhängig. Teams müssen verstehen, was sich geändert hat, wann es sich geändert hat, wie stark es sich geändert hat und was das für das System bedeutet.

Das ist mit isolierten Tabellen oder generischen BI-Dashboards schwierig. Grafana ist besser geeignet, weil es SQL-gesteuerte Abfragen, mehrere Visualisierungsmodi, Interaktivität und Dashboard-Komposition an einem Ort kombiniert.

Für Energieunternehmen liegt der eigentliche Wert nicht nur im Charting. Er liegt in der Integration. Ein Public-Data-Prototyp auf Basis von SMARD oder Energy-Charts kann sich später zu einer produktionsreifen Plattform entwickeln, die SCADA, EMS-Ausgaben, Prognosesysteme, Simulationstools und interne Analysepipelines umfasst, während Grafana die Visualisierungs- und Alerting-Schicht bleibt.

Grafana als Visualisierungsschicht für modernen Netzbetrieb

Bei Kickstage bauen wir SCADA- und EMS-Plattformen, Tools für dynamische Sicherheitsbewertung und Next-Generation-Control-Center-Architekturen für TSOs und DSOs. In diesen Systemen dient Grafana als Frontend-Visualisierungsschicht, die Daten aus mehreren Backend-Quellen zusammenführt.

SCADA-Integration

Moderne SCADA-Systeme erzeugen enorme Mengen an Echtzeit-Telemetrie: Spannung, Strom, Frequenz, Wirkleistung und Blindleistung, Schalterstatus, Transformator-Stufenschalterpositionen und Alarmsignale. Diese Daten fließen über Kommunikationsprotokolle wie IEC 60870-5-104, TASE.2/ICCP, Modbus und OPC UA.

Durch die Speicherung von SCADA-Messwerten in PostgreSQL oder TimescaleDB kann Grafana Folgendes abfragen und visualisieren:

• Echtzeit-Überwachung von Umspannwerken: Spannungsprofile, Transformatorauslastung, Leistungsschalterzustände
• Netz-Topologieansichten: Live-Karten mit unter Spannung stehenden Betriebsmitteln und Schaltzuständen
• Alarm-Dashboards: Zeitreihen von Alarmanzahlen, Quittierungsraten und Erkennung von Alarmfluten
• Performance-Metriken: SCADA-Polling-Latenz, Kommunikationsqualität und Datenverfügbarkeit

Grafanas Alerting-System kann Benachrichtigungen auslösen, wenn Messwerte Schwellenwerte überschreiten, und Betreibern dadurch proaktive Transparenz über Netzbedingungen geben.

EMS-Ausgaben und Netzanalyse

Energy Management Systems führen kritische Analysefunktionen aus, etwa Zustandsschätzung, Lastflussanalyse und Kontingenzprüfung. Diese Tools erzeugen Ergebnisse, die überwacht, validiert und umgesetzt werden müssen. Grafana kann Folgendes visualisieren:

• Qualität der Zustandsschätzung: Residuen, Bad-Data-Erkennung und Observability-Metriken
• Ergebnisse der Kontingenzanalyse: Anzahl von N-1- und N-2-Verletzungen, Überlastungsschwere, Spannungsabweichungen
• Optimal Power Flow: Empfehlungen zur Erzeugungseinsatzplanung, Engpasskosten, Knotenpreise
• Stromsystem-Snapshots: Knotenspannungen, Leitungsflüsse, Transformatorauslastung im Netz

Durch die Verbindung von Grafana mit der EMS-Datenbank oder einem Message Bus erhalten Betreiber Einblick in Gesundheit und Performance ihrer Analysewerkzeuge – nicht nur in das Netz selbst.

Simulation and Planning Tools

Simulationsframeworks wie PandaPower, Powsybl und PowerFactory® sind essenziell für Offline-Studien, Planungsszenarien und dynamische Sicherheitsbewertung. Diese Tools erzeugen Studienergebnisse, die häufig als CSV exportiert, in Datenbanken gespeichert oder über APIs veröffentlicht werden.

Grafana kann Simulationsergebnisse in interaktive Dashboards verwandeln:

• Ergebnisse von Lastflussstudien: Spannungs-Heatmaps, Auslastungsprozentsätze, Blindleistungsreserven
• Dynamische Stabilitätsanalyse: Rotorwinkelschwingungen, Frequenznadir, Spannungserholungszeit
• Studien zur Integration erneuerbarer Energien: Hosting-Capacity-Kurven, Abregelungsstatistiken, Netzimpact-Metriken
• FACTS- und PST-Regelstrategien: Performance-Vergleich über verschiedene Steuerungsszenarien hinweg

Dadurch werden Simulationsergebnisse für Stakeholder zugänglich, die Einblicke benötigen, ohne die Simulationstools selbst auszuführen.

Forecasting und Predictive Analytics

Netzbetreiber verlassen sich zunehmend auf Prognosen für Last, erneuerbare Erzeugung und Marktpreise. Grafana eignet sich sehr gut zum Vergleich von Prognose- und Ist-Daten, wie die Widgets „Solar Actual vs Forecast“ und „Demand vs Forecast“ in diesem Beitrag zeigen.

Für Produktionssysteme kann Grafana:

• Prognosegenauigkeit verfolgen: Mean Absolute Error (MAE), Root Mean Squared Error (RMSE), Bias-Trends
• Ensemble-Prognosen visualisieren: probabilistische Bänder, mehrere Prognosemodelle nebeneinander
• Gesundheit der Prognosepipeline überwachen: Datenaktualität, Modellausführungszeit, API-Antwortlatenz

Prognose-Dashboards helfen Betreibern, die Zuverlässigkeit von Vorhersagen zu verstehen und bessere Entscheidungen unter Unsicherheit zu treffen.

Interne Analysen und Datenintegration

Moderne Energieunternehmen erzeugen Daten aus vielen internen Systemen: Asset-Management-Datenbanken, Wartungsprotokolle, Outage-Management-Systeme, Kundensysteme und Finanzplattformen. Grafana kann diese unterschiedlichen Quellen zu konsistenten Dashboards zusammenführen.

Beispiele sind:

• Asset-Health-Monitoring: Kombination von Sensordaten, Wartungsplänen und Ausfallprognosen
• Ausfallanalysen: Korrelation zwischen Wetterereignissen, Betriebsmittelausfällen und Kundenauswirkungen
• Performance von Portfolios erneuerbarer Energien: Aggregation von Produktionsdaten aus verteilten Solar-, Wind- und Speicheranlagen
• Korrelation von Markt und Betrieb: Visualisierung von Preissignalen zusammen mit Erzeugungseinsatz und Netzrestriktionen

Durch die Verbindung von Grafana mit internen Datenbanken, APIs und Data Lakes schaffen Teams eine zentrale Sicht auf funktionsübergreifende Erkenntnisse.

Sicherheit, Skalierbarkeit und Zuverlässigkeit

Missionskritischer Netzbetrieb erfordert hohe Verfügbarkeit, Cybersicherheit und deterministische Performance. Grafana passt natürlich in sichere Enterprise-Architekturen:

• Role-Based Access Control (RBAC): Einschränkung der Dashboard-Sichtbarkeit nach Team, Funktion oder Sicherheitsfreigabe
• Audit Logging: Nachverfolgung, wer wann auf welche Daten zugegriffen hat
• Hochverfügbarkeits-Deployment: Grafana in Kubernetes mit redundanten Replikas und Load Balancing betreiben
• Read-only-Datenquellen: Grafana fragt Datenbanken ab, ohne operative Systeme zu verändern
• Netzwerksegmentierung: Deployment von Grafana innerhalb von Control-Center-Netzwerken oder DMZ-Architekturen

Bei Kickstage entwerfen wir Grafana-Deployments, die den Zuverlässigkeits- und Sicherheitsanforderungen von TSO- und DSO-Umgebungen entsprechen. Mehr über unseren Ansatz erfahren Sie auf unserer Seite Software für moderne Energienetze.

Fazit

Grafana ist ein leistungsstarkes Tool für den Aufbau maßgeschneiderter Lösungen für den Energiesektor. Es hilft dabei, komplexe Netz- und Marktdaten in Dashboards zu verwandeln, die visuell klar, operativ nützlich und leicht an veränderte Geschäftsanforderungen anpassbar sind.

In unserem Setup übernimmt Python Ingestion und Transformation, PostgreSQL und TimescaleDB bieten schnelle Speicherung für Zeitreihenanalysen, Docker sorgt für ein reproduzierbares Deployment-Setup, und Grafana wird zur Oberfläche, in der Energiedaten zu Erkenntnissen werden.

Das Ergebnis ist mehr als ein Dashboard. Es ist die Grundlage für eine Decision-Support-Oberfläche für das digitale Stromnetz.

Bei Kickstage unterstützen wir Energieunternehmen dabei, Softwaresysteme zu entwerfen und zu entwickeln, die Netz- und Marktdaten in der realen Welt nutzbar machen. Ob das Ziel ein öffentlich zugängliches Energie-Dashboard, eine Oberfläche für den Netzbetrieb oder eine individuelle Analyselösung mit Anbindung an interne Infrastruktur ist – Grafana kann Teil eines modernen, skalierbaren und hochwirksamen Energie-Software-Stacks sein. Kontaktieren Sie uns , um Ihre Herausforderungen im Bereich Energiedaten zu besprechen.


Haftungsausschluss: Dieser Beitrag demonstriert die Entwicklung von Dashboards mit öffentlich verfügbaren Daten aus Drittanbieter-APIs (SMARD und Energy-Charts). Kickstage übernimmt keine Gewähr für die Richtigkeit, Vollständigkeit, Zuverlässigkeit oder Aktualität von Informationen, die aus diesen externen Quellen stammen. Die Daten und Visualisierungen werden „wie besehen“ bereitgestellt, ohne ausdrückliche oder stillschweigende Garantien. Dieser Inhalt dient ausschließlich Bildungs- und Demonstrationszwecken und sollte nicht als Grundlage für operative, kommerzielle oder Investitionsentscheidungen verwendet werden. Prüfen Sie Daten immer unabhängig, bevor Sie sie in Produktionssystemen einsetzen.