Zum Inhalt

PQopen – Open Data für das Stromnetz von morgen

Das PQopen Monitoring System folgt einer klaren Vision: Eine offene, zugängliche Datenbasis für alle zu schaffen, die sich mit der Analyse und dem Verständnis unseres elektrischen Energiesystems beschäftigen. Während Plattformen wie energy-charts.info bereits eindrucksvolle Daten zur Erzeugungsstruktur liefern, bleibt ein detaillierter Einblick in die Netzqualität – also Frequenz- und Spannungsverhalten – bislang oft unzugänglich. Genau hier setzt PQopen an.

Das Projekt verfolgt dabei mehrere Leitlinien:

  • Open Source & Open Data: Offenheit steht im Zentrum – für Software wie auch für die gewonnenen Daten.
  • Sensibilisierung für Netzqualität: Die Öffentlichkeit soll ein Gefühl für die Sensibilität unseres Verbundsystems entwickeln.
  • Maximaler Nutzen bei minimalem Budget: Mit schlanken Mitteln wird eine leistungsfähige Monitoring-Lösung aufgebaut.

Anforderungen

Funktional

Das PQopen System ist mehr als nur die Sammlung von Messdaten – es ist eine umfassende Plattform zur Erfassung, Analyse und Bereitstellung von Netzdaten.

  • Datenendpunkt für PQopen-Messgeräte: Diese senden kontinuierlich Spannungs- und Frequenzdaten.
  • Robuste Zeitreihen-Datenbank: Speicherung inklusive Unterstützung für verspätete oder unsortierte Datenpakete.
  • Visualisierung über Web-Frontend: Einfache, öffentliche Zugriffsmöglichkeiten auf die erfassten Daten.
  • HTTP-API für Rohdatenzugriff: Nutzerfreundlicher Zugang zu den Daten in Echtzeit.
  • Langzeitarchivierung via Parquet-Dateien: Daten älter als 30 Tage werden komprimiert gespeichert.

Nicht-funktional

Um eine nachhaltige und kontrollierte Infrastruktur zu gewährleisten, sind folgende Rahmenbedingungen essenziell:

  • Serverstandort in Europa
  • Vollständige Systemkontrolle (Root-Zugriff)
  • Einsatz bewährter Open-Source-Komponenten (z. B. Grafana, Mosquitto)
  • Verwendung einer Timeseries-Datenbank
  • Sichere Datenübertragung mittels MQTT + TLS

Qualitätsanforderungen

Die erste Ausbaustufe sieht vor, mindestens 10 Messgeräte simultan zu bedienen. Dabei müssen folgende Punkte erfüllt sein:

  • Cycle-by-cycle Daten (bei 50 Hz ca. 20ms) sollen für 30 Tage rückwirkend gespeichert werden.
  • Reduzierte 1-Sekunden-Daten stehen für mindestens 1 Jahr zur Verfügung.
  • Skalierbarkeit: Das System muss einfach auf leistungsfähigere Server umziehbar sein.

Konzept & Umsetzung

Blockschaltbild des Monitoring Systems (rechts). Die Datenquelle ist das PQopen-Messgerät (links teilweise dargestellt)

Auswahl des Servers

Für den Start bietet sich ein V-Server mit 4 Kernen, 8 GB RAM und 80 GB SSD an. Ideal geeignet sind hier Anbieter wie Hetzner (schnelle Bereitstellung, gute Performance) oder Strato (günstig, aber leicht eingeschränkter Komfort bei der Einrichtung).

Datenbankwahl

Bisher habe ich vielfach InfluxDB 1.8 genutzt – stabil, jedoch veraltet. Neuere Versionen setzen stark auf Enterprise-Modelle oder bieten nur kurze Speicherzeiträume (z. B. 72 h bei InfluxDB OSS v3). Alternative Datenbanken wie TimescaleDB oder QuestDB scheiterten an Speicherbedarf, fehlender Out-of-Order-Performance oder hoher Komplexität bei der Datenabfrage.

Fazit: InfluxDB bleibt (vorerst) die praktikabelste Lösung, trotz stagnierender Open-Source-Entwicklung.

Web-Frontend: Grafana

Grafana überzeugt durch:

  • starke Community
  • umfangreiche Schnittstellen zu Zeitreihen-Datenbanken
  • flexible Visualisierungen

Es wird als zentrale Oberfläche für die Visualisierung verwendet.

MQTT Broker

Mosquitto ist der Broker der Wahl: leichtgewichtig, stabil, weit verbreitet. Die Konfiguration ist etwas sperrig, aber für wenige Clients absolut ausreichend. TLS-Verschlüsselung und Access Control Lists (ACL) sorgen für Sicherheit.

Containerisierung

Das gesamte System läuft in Docker-Containern, orchestriert über Docker Compose. Langfristig ist auch ein Umstieg auf Podman denkbar.

Reverse Proxy

Ein NGINX Proxy Manager übernimmt die HTTPS-Verschlüsselung (Let’s Encrypt) und ermöglicht die einfache Anbindung mehrerer Webdienste (z. B. API, Grafana, zukünftige Admin-Interfaces).

Eigene Software-Komponenten

Neben bestehenden Open-Source-Komponenten ist speziell entwickelte Software nötig:

  • MQTT-Empfangslogik: Verarbeitung eingehender Nachrichten (inkl. Topic Parsing, Device-ID-Zuordnung, Format-Erkennung).
  • Device-Verwaltung: Geräteinformationen werden derzeit in einer JSON-Datei verwaltet.
  • Asynchrone Verarbeitung mit asyncio & aiomqtt: Für spätere Skalierung durch parallele Verarbeitung (Worker Tasks).

Datenübertragung & MQTT-Architektur

Authentifizierung

Jedes Messgerät meldet sich über eine eigene Zugangsdaten (Username/Passwort) an. Die Kommunikation erfolgt verschlüsselt über TLS. Ein ACL-File regelt den Zugriff auf spezifische Topics (Schreiben ist nur erlaubt auf Topic mit der festgelegten Device-ID).

Topic-Struktur

private/<device-id>/<data-type>/<encoding>
SubtopicBeschreibung
privateKennzeichner, dass auf das Topic nur geschrieben werden kann und die Daten nur auf Server-Seite gelesen werden können
<device-id>Platzhalter für die Device-Id. Das ist eine UUID, die bei Geräte-Inbetriebnahme zufällig vergeben wird
<data-type>Objekt-Type der übertragenen Nachricht
<encoding>Kodierung der Nachricht (json, gjson, cbor)

Beispielhafte Datenformate:

  • agg_data: z.B. Aggregierte 10-Sekunden-Werte (PQ-Parameter), nach 61000-4-30 cycle-sync
  • dataseries: 1:1 Übertragung der berechneten Kanäle (z. B. Frequenz in Cycle-by-Cycle)
  • event: Ereignisdaten bei Spannungseinbrüchen/-überhöhungen
  • mixed: Kompakte CBOR-Übertragung bei hohem Pufferstand, Übertragung mehrerer gecachter Nachrichten auf einmal
Beispiel Payload für agg_data: Unix-Timestap in Sekunden 
{
  "type": "aggregated_data",
  "measurement_uuid": "b87f04df-f0b5-4a72-9e21-744fdd94c62d",
  "interval_sec": 1,
  "timestamp": 1745601994.0,
  "data": {
    "U1_rms": 235.9918,
    "U2_rms": 236.8720,
    "U3_rms": 237.0291
  }
}
Beispiel Payload für dataseries. Unix-Timestamp in µs 
{
  "type": "timeseries_data",
  "measurement_uuid": "fab1f71f-7f69-447e-b049-8b435b934d13",
  "data": {
    "Freq": {
      "data": [
        50.041617776325154,
        50.058138807492426
      ],
      "timestamps": [
        1746637534637998,
        1746637534657978
      ]
    },
    "U1_1p_rms": {
      "data": [
        238.092918283,
        238.120304937
      ],
      "timestamps": [
        1746637534637998,
        1746637534657978
      ]
  }
}

Datenbankintegration

Ein Listener abonniert alle Topics (private/#) mit QoS 2 und persistenter Client-ID. Die Daten werden entsprechend des Typs interpretiert und in die Datenbank übertragen – ergänzt um Metadaten aus der Geräteverwaltung.

Postprocessing Worker

Ein separater Prozess berechnet zyklisch abgeleitete Metriken wie Power Density Spectrum, liest die Rohdaten aus der Datenbank, verarbeitet sie und speichert die Ergebnisse zur späteren Visualisierung.

Webfrontend: Visualisierung mit Grafana

Zum Projektstart wird das Dashboard grundlegende Funktionen bieten:

  • Frequenz- und Spannungsverlauf je Messstelle
  • Zugriff über Webinterface für die Allgemeinheit
Grafana Welcome Screen unter https://pqopen.com
Power Spectral Density (PSD) der Messstelle Graz in 15-Minuten Auflösung (0.01 Hz Resolution). Gleichzeitig ist der Verlauf der prägnanten 0.21 Hz Linie sichtbar.

Fazit & Ausblick

PQopen ist ein ambitioniertes Projekt mit einem klaren Ziel: Transparenz und Bewusstsein für Netzqualität schaffen – mit offenen Mitteln, für alle zugänglich. Der modulare Aufbau erlaubt eine schrittweise Weiterentwicklung – von der Integration weiterer Messgeräte bis hin zu intelligenten Auswertungen im Backend.

In den nächsten Wochen werden die ersten Messgeräte für interessierte Mitmacher fertiggestellt und nach und nach ab Ende Juni versandt.

Weitere Infos zum PQopen-Projekt hier: https://daqopen.com/pqopen-open-grid-monitoring-for-europe/

Open Source. Open Data. Open Mind.

Euer Michael

Schreibe einen Kommentar