EcoPulse - Plattform für Energiemonitoring und Laststeuerung

Ausgangslage #

Energie- und Ladeinfrastruktur wächst selten geplant. Sie wächst in Schritten: erst die Photovoltaik, dann der Speicher, später die Wallboxen, irgendwann ein zweiter Zähler für den neuen Gebäudeteil. Jedes Gerät bringt seine eigene Schnittstelle mit, jeder Hersteller sein eigenes Datenmodell.

Das Ergebnis ist ein Betrieb, der viele Zahlen hat und trotzdem keine Entscheidungsgrundlage: Der Wechselrichter kennt seine Erzeugung, die Wallbox kennt ihren Ladezustand, der Zähler kennt den Netzbezug - aber niemand kennt das Gesamtbild zum selben Zeitpunkt.

Aufgabenstellung #

Gesucht war keine Visualisierung, sondern eine Entscheidungsgrundlage. Die Plattform sollte:

• Geräte unterschiedlicher Hersteller anbinden, ohne dass jede neue Geräteklasse die Auswertung anfasst,
• Telemetrie in einer gemeinsamen, zeitlich hochauflösenden Datenbasis zusammenführen,
• daraus automatisiert Lade-, Entlade- und Lastverschiebungsentscheidungen ableiten,
• und beides können: on-premises laufen oder in der Cloud.

Architekturentscheidungen #

Die Plattform ist als ereignisgetriebene Microservice-Landschaft in fünf klar getrennten Verarbeitungsstufen aufgebaut. Die Trennung ist der Kern des Entwurfs: Sie erlaubt, eine Stufe zu ändern, ohne die anderen anzufassen.

1. Geräteanbindung / Edge - Wechselrichter und Zähler über Modbus und SunSpec, Ladeinfrastruktur und Fremdsysteme über herstellerspezifische Schnittstellen. Vorverarbeitung und Normalisierung passieren nahe am Gerät, damit nur belastbare Werte weiterlaufen.
2. Ingest & Streaming - Aufnahme der Telemetrie über MQTT, Weiterverarbeitung über Kafka beziehungsweise Redpanda. Erfassung, Verarbeitung und Auswertung sind damit entkoppelt: Ein Ausfall der Auswertung kostet keine Messwerte.
3. State-Projektion - Ableitung des aktuellen Anlagenzustands aus dem Ereignisstrom, Persistenz historischer Verläufe in PostgreSQL mit TimescaleDB, Caching heißer Werte in Redis.
4. REST-API & Live-Stream - versionierte REST-/OpenAPI-Schnittstelle für Abfragen und Konfiguration, SignalR für die Push-Aktualisierung der Oberfläche.
5. Weboberfläche - Angular-Frontend mit Echtzeit-Dashboards, historischen Auswertungen und Steuerungsfunktionen.

Warum ereignisgetrieben #

Ein Energiesystem ist ein Strom von Ereignissen, kein Zustand, den man abfragt. Die ereignisgetriebene Verarbeitung hat drei praktische Konsequenzen: Historische Verläufe sind vollständig rekonstruierbar, neue Auswertungen lassen sich auf vorhandenen Daten nachrüsten, und Lastentscheidungen sind im Nachhinein nachvollziehbar - was bei automatisierten Eingriffen in eine Anlage keine akademische Eigenschaft ist.

Umsetzung #

Marktdatenintegration #

Day-Ahead-Strompreise aus europäischen Gebotszonen und CO₂-Intensitätsdaten des Netzes laufen als Eingangsgrößen in die Optimierung ein. Damit entscheidet die Anlage nicht nur nach Eigenverbrauch, sondern nach Preis und Emissionsintensität.

Prognose und Optimierung #

Vorhersagemodelle für Strompreis, Erzeugung und Verbrauch bilden die Grundlage für Lade- und Entladestrategien der Speicher sowie für die zeitliche Verschiebung flexibler Lasten. Trainiert und ausgewertet wird auf den hochauflösenden Zeitreihen der Plattform selbst - mit Python, Pandas, NumPy und scikit-learn gegen TimescaleDB.

Lastmanagement #

Peak-Shaving, Eigenverbrauchsoptimierung und dynamische Bilanzierung zwischen Netzbezug, Speicher und Erzeugung. Für die E-Mobilität kommen Ladeinfrastruktur und fahrzeugseitige Datenquellen hinzu - Ladezustand und Standort erlauben ladezeitpunkt- und preisoptimiertes Laden.

KI-Assistenz #

Anlagenzustand und Auswertungen sind zusätzlich natürlichsprachlich zugänglich, über eine STT → LLM → TTS-Pipeline. Der praktische Nutzen liegt weniger in der Sprache als in der Abfrage: Wer nach „Wie war der Eigenverbrauch letzte Woche im Vergleich zum Vorjahr?" fragt, muss kein Dashboard bedienen können.

Qualitätssicherung #

Die Testarchitektur ist der Teil dieses Projekts, auf den wir am ehesten verweisen, wenn jemand wissen will, wie wir arbeiten.

• Automatisierte Tests über sämtliche Microservices hinweg - von der Geräteanbindung über die Streaming-Verarbeitung bis zur Weboberfläche.
• End-to-End-Tests gegen eine real hochgefahrene API, inklusive echter Datenbank über Testcontainers und einschließlich Autorisierungs- und Fehlerpfaden. Nicht gegen Mocks: Ein Mock bestätigt die eigene Annahme, eine echte Datenbank widerspricht ihr.
• Frontend-Tests der Angular-Oberfläche - Komponenten-, Service- und Verhaltenstests als verpflichtendes CI-Gate.
• Test-Driven Development (red/green/refactor) als verbindlicher Teamstandard.
• Validierung von Streaming- und Echtzeitdaten sowie zeitreihenbasierter Auswertungen - der Teil, den Standardtestwerkzeuge nicht abdecken.
• Reproduzierbare Testumgebungen und synthetische Testdatenbestände über Docker und Testcontainers.

Betrieb #

Metriken, Logs und Traces laufen durchgängig über Grafana, Prometheus, Loki und OpenTelemetry. Bei einer Plattform, die automatisiert in eine Anlage eingreift, ist Observability keine Betriebszugabe, sondern Teil der Sicherheitsargumentation: Jede Entscheidung muss im Nachhinein erklärbar sein.

Fazit #

EcoPulse zeigt das Muster, nach dem wir Systeme dieser Art bauen: Verarbeitungsstufen sauber trennen, Geräteanbindung isolieren, Entscheidungen aus einem Ereignisstrom ableiten statt aus Momentaufnahmen - und die Testarchitektur so aufsetzen, dass sie die Fehler findet, die in verteilten Systemen tatsächlich auftreten.