Veröffentlicht am:
EEBUS spielt im deutschen Smart-Grid- und HEMS-Kontext eine zunehmend wichtige Rolle. Der Standard definiert eine Kommunikationsschnittstelle, über die energierelevante Geräte im Gebäude, Energiemanagementsysteme sowie Netz- und Marktakteure miteinander interagieren können.
Beitrag Nr. 16 der Veröffentlichungs-Reihe der Anbieter der Prosumer-Plattform Initiative.
EEBUS spielt im deutschen Smart-Grid- und HEMS-Kontext eine zunehmend wichtige Rolle. Der Standard definiert eine Kommunikationsschnittstelle, über die energierelevante Geräte im Gebäude, Energiemanagementsysteme sowie Netz- und Marktakteure miteinander interagieren können. Ziel ist eine herstellerübergreifende Interoperabilität zwischen Komponenten wie Wallboxen, Wärmepumpen, PV-Anlagen, Batteriespeichern, Smart Meter Gateways, Steuerboxen und Home Energy Management Systemen.
Besonders relevant wird EEBUS überall dort, wo Energieanlagen nicht mehr nur überwacht, sondern aktiv koordiniert werden müssen. Beispiele dafür sind die netzorientierte Steuerung steuerbarer Verbrauchseinrichtungen nach §14a EnWG oder technische Vorgaben für Erzeugungsanlagen nach §9 EEG. Mit dem zunehmenden Ausbau von Wärmepumpen, Ladeinfrastruktur und Batteriespeichern wächst auch die Bedeutung standardisierter Kommunikationsschnittstellen im Niederspannungsnetz.
Die Praxis zeigt jedoch: Ein Standard allein löst noch keine Interoperabilitätsprobleme. Unterschiedliche Geräte, Rollenmodelle und Interpretationen der Spezifikation führen häufig dazu, dass die eigentlichen Herausforderungen erst beim ersten realen Verbindungsaufbau sichtbar werden.
Abb. 1: EEBUS SDK integriert in einem Agent-first-HEMS (GitHub: https://github.com/ULudo/helios-home)
Im Rahmen einer Agent-first-HEMS-Idee sollte untersucht werden, wie sich EEBUS-Geräte in ein modernes Home Energy Management System integrieren lassen.
Die Grundidee dabei: Ein HEMS nicht nur als klassische Regelungssoftware zu betrachten, sondern als System, in dem ein KI-Agent Geräte erkennt, deren Fähigkeiten interpretiert, technische Einschränkungen versteht und diese Informationen an nachgelagerte Optimierungs- und Steuerungsverfahren weitergibt.
Dafür wurde im CoSES HEMS-Testlabor ein erster Versuch mit einem Coding-Agenten durchgeführt. Der Agent erhielt die Aufgabe, einen EEBUS-Stack in Python aufzubauen. Bereits nach etwa 45 Minuten konnte der erste Prototyp EEBUS-Geräte im lokalen Netzwerk entdecken und unter anderem ein PPC Smart Meter Gateway identifizieren.
Eine stabile Verbindung zum PPC-SMGW kam zunächst jedoch nicht zustande.
Genau an dieser Stelle zeigte sich die eigentliche Schwierigkeit: Der Verbindungsaufbau wurde zwar abgelehnt beziehungsweise nicht vollständig fortgeführt, aussagekräftige Logs auf der Gegenseite standen jedoch zunächst nicht zur Verfügung. Dadurch blieb unklar, ob das Problem im SHIP-Handshake, in SPINE, im Trust-Handling, in der Geräteidentität oder in der konkreten Nachrichtensemantik lag.
Für das weitere Debugging wurde zusätzlich eine MENNEKES-Wallbox mit EEBUS-Unterstützung in den Testaufbau integriert. Im Unterschied zum PPC-SMGW standen hier Logs der Gegenseite zur Verfügung. Dadurch konnte nachvollzogen werden, an welcher Stelle die Kommunikation scheiterte.
Der Coding-Agent konnte die Implementierung daraufhin gezielt anpassen, sodass eine Verbindung zur Wallbox erfolgreich hergestellt werden konnte.
Damit war klar: Der grundsätzliche Python-Ansatz funktionierte. Das verbleibende Problem lag spezifisch im Zusammenspiel mit dem PPC-SMGW.
Um die Ursache weiter einzugrenzen, wurde anschließend die bestehende Go-Implementierung eebus-go als Referenz herangezogen. Die Bibliothek stellt eine Grundlage für EEBUS-Use-Cases in Go bereit und unterstützt unter anderem SHIP 1.0.1, SPINE 1.3.0, Zertifikats-Handling, mDNS, WebSocket-Verbindungen und Pairing.
Der Coding-Agent lud den Go-Stack herunter, setzte ihn gegen das PPC-SMGW auf und verglich anschließend das Verhalten der funktionierenden Go-Implementierung mit dem Python-Prototyp.
Dieser Vergleich führte schließlich zum entscheidenden Unterschied.
Der eigentliche Blocker lag nicht im Discovery-Mechanismus oder im SHIP-Verbindungsaufbau, sondern in der SPINE-Nachrichtensemantik bei Read-Requests.
Die Python-Implementierung antwortete zunächst auf bestimmte Reads mit einer Kombination aus resultData und anschließendem reply:
PPC -> HEMS: read loadControlLimitDescriptionListDataHEMS -> PPC: resultData errorNumber 0HEMS -> PPC: reply loadControlLimitDescriptionListData
Die funktionierende Go-Implementierung antwortete dagegen direkt mit dem eigentlichen reply:
PPC -> HEMS: read loadControlLimitDescriptionListDataHEMS -> PPC: reply loadControlLimitDescriptionListData
Der entscheidende Unterschied war also: Für diese Reads wurde kein separates resultData vor dem eigentlichen reply gesendet.
Das PPC-SMGW tolerierte die Kombination aus resultData und reply offenbar bei einigen Management-Reads, bei LoadControl jedoch nicht mehr zuverlässig. Konkret wurde loadControlLimitDescriptionListData noch gelesen, anschließend aber loadControlLimitListData nicht mehr sauber abgefragt.
In der Folge wurden lediglich mgcp/mpc, jedoch nicht die für Leistungsbegrenzungen relevanten Rollen beziehungsweise Use-Cases lpc/lpp sichtbar.
Aus dem ursprünglichen Prototyp entstand schließlich ein Open-Source-SDK für EEBUS in Python.
Das Projekt versteht sich als Python-SDK und CLI für EEBUS-SHIP/SPINE-HEMS-Integrationen, SMGW-Interoperabilität sowie LPC/LPP-Load- und Power-Control-Workflows.
Das SDK umfasst unter anderem:
Im Prototyp können EEBUS-Geräte visualisiert, Leistungsbegrenzungen empfangen und als technische Restriktionen an Steuerungs- oder Planungsverfahren weitergegeben werden.
Der Versuch zeigt exemplarisch, warum Interoperabilität in der Praxis weit mehr bedeutet als das bloße Vorhandensein eines Standards.
EEBUS schafft eine wichtige Grundlage: ein gemeinsames Datenmodell sowie standardisierte Use-Cases für energierelevante Geräte. Ob ein System in der Praxis tatsächlich interoperabel ist, entscheidet sich jedoch häufig erst an Details der Implementierung, an Logs, Testgeräten, Rollenmodellen und realen Interoperabilitätstests.
Für HEMS-Anbieter bedeutet das: Eine robuste Integrationsschicht muss nicht nur Protokolle „sprechen“, sondern auch mit Gerätevarianten, unvollständigen Implementierungen, Abweichungen und Debugging-Situationen umgehen können.
Gerade bei netzdienlichen Use-Cases wie LPC und LPP reicht es nicht aus, eine Spezifikation formal umzusetzen. Entscheidend ist, ob ein System mit realen Steuerboxen, Smart Meter Gateways, Wallboxen, Wärmepumpen und PV-Komponenten zuverlässig zusammenarbeitet.
Der Einsatz von KI-gestützten Coding-Agenten kann solche Arbeiten deutlich beschleunigen. Besonders hilfreich werden sie dann, wenn sie Zugriff auf reale Geräte, Gegenstellen-Logs und funktionierende Referenzimplementierungen erhalten. In solchen Umgebungen können sie Implementierungsvarianten vergleichen, Protokollabweichungen eingrenzen und Debugging-Zyklen erheblich verkürzen.
Der Praxisversuch zeigt zwei Dinge zugleich.
Erstens: Standards wie EEBUS sind eine zentrale Voraussetzung für interoperable und skalierbare HEMS-Lösungen. Sie schaffen eine gemeinsame Sprache für Geräte, Energiemanagementsysteme sowie Netz- und Marktakteure.
Zweitens: Die eigentliche Integrationsarbeit bleibt anspruchsvoll. Gerade beim ersten realen Verbindungsaufbau entscheiden oft kleine semantische Details darüber, ob ein Use-Case funktioniert oder nicht.
KI-gestützte Coding-Agenten können diese Arbeit nicht magisch eliminieren. Sie können sie jedoch erheblich beschleunigen – vorausgesetzt, sie sind in eine Umgebung eingebettet, die echte Rückmeldungen liefert: reale Geräte, Logs, Tests, Referenzimplementierungen und klar definierte Use-Cases.
EEBUS-Python-Stack: https://github.com/ULudo/eebus-sdk
Ulrich Ludolfinger ist PhD-Student an der Technischen Universität München und wissenschaftlicher Mitarbeiter an der Hochschule Landshut. Er arbeitet in den Forschungsprojekten ReLLFloW (Projektkennzeichen: AZ-1585-23) und PhyLFlex (Förderkennzeichnung: 03El6134A). Seine Themen- und Forschungsbereiche sind Reinforcement Learning und Machine Learning for Energy Systems, insbesondere für Gebäude-Energiemanagement, Lastflexibilisierung und netzdienliche Steuerung. LinkedIn: https://www.linkedin.com/in/ulrich-ludolfinger-5105601b4/
