Nature / API für EZA-Regler

Deutsches Forum
21

Danke für das Feedback. Zu den zwei Fragen im Post erlaube ich mir die unten aufgeführten Folgefragen zu stellen, da mir noch nicht alle Implementierungsdetails der OpenEMS Edge klar sind.

  1. Ist bei der Implementierung der Limits immer eine Übersetzung in Prozent nötig oder kommen je nach Netzbetreiber auch mal Limits in kWh an?
  2. Reicht ein Satz von Limits in der Meta Komponente, um die benötigten Use-Cases abzubilden? Was ist mit dezentralen Anlagen, bei denen der Batteriespeicher getrennt vom PV-Feld steht? Da gibt es dann doch sicher mehrere Netzanschlusspunkte oder? (Anm.: Das würde das Konzept mit der Meta Komponente konterkarieren.)
  3. Soweit ich weiß gibt es ja tausende große und kleine Netzbetreiber, die alle ihre eigenen Vorschriften haben und Gesetze, sowie Handlungsempfehlungen dazu sehr unterschiedlich auslegen. Haben die Limits an den Netzanschlusspunkten die höchste Prio oder gibt es Limits mit höherer Prio?

Ein paar Ideen meinerseits zur Implementierung:

  • Wenn das Modul io.openems.edge.common der von allen anderen OpenEMS Edge Modulen zentral erreichbare Punkt ist, gehört die Implementierung der Umrechnung in Prozent m.E. auch dort hinein.
  • Je nachdem, wie ein Netzbetreiber die Limits vorgibt, könnte es sinnvoll sein, das Decorator Pattern für die Meta-Komponente zu nutzen. (Anm.: Ob das mit der Implementierung wirklich funktioniert wäre noch zu prüfen.)
  • Aufgrund der Vielzahl der Netzbetreiber und deren recht unterschiedlichen Policies kann es Sinn machen, die Priorisierung mittels konfigurierbaren Policies zu regeln.

Das nur so als lose Ideen. Wie seht ihr das?

22

Ist bei der Implementierung der Limits immer eine Übersetzung in Prozent nötig oder kommen je nach Netzbetreiber auch mal Limits in kWh an?

Ich hätte gehofft, dass du da mehr Informationen hast :slight_smile: . Die Limitierung über den Funkrundsteuerempfänger kommt immer in Prozentstufen über die digitalen Eingänge. Ansonsten dürfte die Limitierung in [W] in Zukunft die Regel sein.

Reicht ein Satz von Limits in der Meta Komponente, um die benötigten Use-Cases abzubilden? Was ist mit dezentralen Anlagen, bei denen der Batteriespeicher getrennt vom PV-Feld steht? Da gibt es dann doch sicher mehrere Netzanschlusspunkte oder? (Anm.: Das würde das Konzept mit der Meta Komponente konterkarieren.)

Ja, das ist ein Problem. Wir hatten auch ein Konzept diskutiert, bei dem wir zu jedem ElectricityMeter eine “Companion-Komponente” dazu konfigurieren könnten, um auf dieser Ebene eindeutig die Limits festzulegen. Vermutlich brauchen wir das in Zukunft ohnehin noch - z. B. für den Anwendungsfall eines Ladeparks, der an einer Unterverteilung hängt. Für 99 % der OpenEMS-Konfigurationen wäre das aber leider vollkommen over-engineered und auch der Leistungsverteilungs-Algorithmus wird sehr kompliziert.

Ich würde vermuten, dass man in den meisten sehr komplexen Szenarien einfach mit mehreren OpenEMS Edge-Instanzen - eine je Netzanschlusspunkt - am besten fährt.

Soweit ich weiß gibt es ja tausende große und kleine Netzbetreiber, die alle ihre eigenen Vorschriften haben und Gesetze, sowie Handlungsempfehlungen dazu sehr unterschiedlich auslegen. Haben die Limits an den Netzanschlusspunkten die höchste Prio oder gibt es Limits mit höherer Prio?

Es gibt sehr unterschiedliche Leistungs-/Limitierungsvorgaben, die sich auch nicht alle auf den Netzanschlusspunkt beziehen - z. B. kann sich die Limitierung des Rundsteuerempfängers auch auf den AC-Ausgang der PV-Wechselrichter beziehen. Oder §14a EnWG “Dimmung” bezieht sich auf die kumulierte Bezugsleistung der steuerbaren Verbrauchseinrichtungen (“SteuVE”).

Priorisierung

Wir werden wohl im ersten Schritt ein Modbus-Register direkt in Meta einführen, mit dem diese Werte gesetzt werden können.

  • Vorteil: Meta ist standardmäßig in der Modbus/TCP-Schreibzugriff API enthalten
  • Nachteil: Es ist nicht unterscheidbar, wer gerade ein Limit setzt (z. B. Direktvermarkter oder EZA-Regler)

Wenn wir im Endeffekt “Controller” bekommen, die “PowerControlUnit” implementieren, wäre es naheliegend, diese über den Scheduler zu priorisieren.

23

Ich wollte es nur mal grundsätzlich hinterfragen, da unser Leitmotte by Slashwhy das “Why / How /What” ist. Im letzten OpenEMS Projekt was immer die Rede davon, dass der Grid-Op auf ein bestimmtes Level in [W] oder [kW] drosselt. In sofern deckt sich das mit meiner Wahrnehmung.

Wir hatten beim Hackathon Q1/2026 bewusst ein Interface gebaut, da es laut Voltfang für Grid-Ops mehrere Möglichkeiten gibt, die Leistungsaufnahme und -abgabe zu drosseln. Mit dem geschilderten Vorgehen haben wir dann ausschließlich die Anbindung per Modbus im Core. Wäre es nicht besser, EZA über Modbus das Interface implementieren zu lassen und die bei der Implementierung aufschlagenden Daten über die Meta Komponente bereitzustellen? Macht das Ganze für weitere Arten der EZA Regulierung besser erweiterbar. Es sei denn es soll nur der Modbus Case angeboten werden. Dann macht das aus sicht des Architektur-Patterns “You ain’t gonna need it” keinen Sinn.