bin aktuell auf der Suche nach der Handhabung eines EZA-Reglers in OpenEMS. In einem der Edge Commons Pakete bin auch auf eine textliche Übersetzung der Bezeichnung dazu gestoßen, habe bislang jedoch keine Nature / ein API Modul dazu finden können. Sind EZA-Regler als Komponenten schon bzw. noch in der Entwicklungsphase?
HIntergrund: In unserem Projekt wollen wir eine Meter und eine EZA-Regler Komponente in einen Controller “einstecken”, der dann wiederum einen PV-Inverter und ein ESS steuert.
Meiner Ansicht nach muss ich dazu eine Schnittstelle/API für den EZA-Regler (engl. Power-Plant-Controller) bereitstellen, da wir sonst keine einheitlichen Channels definieren können. Habe ich die Doku und die Implementierung von OpenEMS an der Stelle so richtig verstanden?
Grundsätzlich haben wir damit folgendes vor (siehe beigefügter Screenshot). Es soll ein Controller gebaut werden, der Daten aus einer PLCnext Steuerung bekommt. Die Komponenten auf der PLCnext Steuerung sind ein Meter und ein EZA-Regler. Beide PLCnext Komponenten haben einen Zwilling im OpenEMS. Neben den beiden Komponenten sollen in den Controller ein ESS und ein PV-Inverter eingeklinkt werden, die mit den Daten der Channels aus Meter und EZA-Regler Komponenten gesteuert werden.
Ich habe mir mal erlaubt folgenden PR für eine EZA-Regler API als Proposal bereitzustellen. Die API ist noch nicht in Stein gemeißelt, über Feedback dazu freuen wir uns.
Gleichzeitig überlegen wir, wie man einen EZA-Regler im OpenEMS UI visualisiert. Sehe den im Widget “Netz”. Was meint ihr dazu?
wir nutzen aktuell für die Einbindung von EZA-Reglern den Modbus-API-Controller, d.h. die Set-Points werden aktiv an FEMS/OpenEMS Edge gesendet - z. B. als SetActivePowerEquals, SetActivePowerLessOrEquals oder SetActivePowerGreaterOrEquals.
In deiner Variante soll stattdessen direkt das Limit am Netzanschlusspunkt an OpenEMS gesendet werden, oder? Soll der Power-Plant-Controller die Daten von PLCnext abholen (“polling”) oder diese bekommen (“push”)? Ich hatte mit PLCnext bisher keine Berührungspunkte.
Falls es im Endeffekt ein einzelner neuer Controller werden soll, braucht es dazu keine neue API/Nature.
danke für Dein Feedback. Wir benutzen aktuell die PLCnext REST Schnittstelle, daher erfolgt das Füllen der Channels per “polling” während des Events “BEFORE_PROCESS_IMAGE”. Im Beispiel Szenario “OpenEMS + PV + BESS” sollen verschiedene Use-Cases abgedeckt werden. HIer ein paar Beispiele:
OpenEMS regelt am Einspeisepunkt ab, wenn Strompreis zu niedrig oder negativ ist.
OpenEMS fährt das Laden eines BESS durch ein PV Feld hoch, sobald das Feld mehr Strom produziert, als der Netzbetreiber abnehmen möchte.
OpenEMS regelt das Laden eines BESS automatisch ab, sobald dieses “voll” ist und regelt die PV Anlage auf die gedrosselte Abnahmemenge des Netzanbieters.
OpenEMS regelt das Laden eines BESS hoch, wenn der Strompreis niedrig oder negativ ist.
OpenEMS berücksichtigt beim Laden eines BESS die Vorgabe des jeweiligen Netzbetreibers.
Das Test-Szenario sieht vereinfacht aus wie im Bild unten. Sowohl vor dem BESS als auch PV-Inverter hängt jeweils ein EZA Regler, um die Anforderungen des Netzbetreibers im Real-Life Test zu erfüllen.
Bezüglich passender Controller Funktionalität schauen wir uns gerade an, was die bestehenden Controller so können und was noch fehlt, um die einzelnen Use-Cases abbilden zu können. Daher werden wir uns auch den Modbus-API-Controller mal anschauen.
Tipps zum Thema passende Controller nehmen wir gerne entgegen.
@stefan.feilmeier : Ein Aspekt, den ich in Deiner Antwort übersehen hatte und den ich quasi als PS noch beantworten möchte. Ja, in meinem aktuellen Szenario sollen die EZA Limits direkt vom EZA am Netzanschlusspunkt abgeholt werden können.
Ok, das heißt ihr möchtet (1.) die Daten aus PLCnext in OpenEMS Devices mappen - z. B. ein meter für den Netzzähler, ess für einen Speicher etc. und (2.) dann Regelungsalgorithmen darauf anwenden, die u.A. auch die EZA-Regler-Limits einhalten.
Das ist in etwa vergleichbar mit Edge-to-Edge in OpenEMS:
Damit werden auch verschiedene Devices von einem IoT-Gerät zum anderen “gemappt”. Die eigentlichen Implementierungen sind dabei ziemlich klein, weil die meiste Logik in der Edge-to-Edge-Bridge gesammelt ist.
Statt Websocket würdet ihr aber die HTTP Bridge verwenden.
Beim Ansatz "pollen während des Events BEFORE_PROCESS_IMAGE” wäre ich vorsichtig. Bei Netzwerkkommunikation kann es immer zu Latenzen oder Unterbrechungen kommen und man will ja nicht, dass der “main” Cycle unterbrochen wird. Mit der HTTP Bridge kann man das sehr gut nebenläufig aufbauen.
Die spezfischen PLCnext-EZA-Regler-Controller würden ebenfalls die PLCnext-Bridge verwenden, die Daten einlesen und die “ESS-Constraints” dann in ihrer run()-Methode anwenden.
Danke für die Ausführungen. Nein, zu abstrakt war das nicht. Für die HTTP Kommunikation setzen wir bereits die HTTP Bridge ein. Auch haben wir bereits digitale Zwillinge für ElectricityMeter, (Managed)SymmetricEss und den EZA-Regler am Netzanschlusspunkt gebaut, die ihre Daten von der PLCnext Steuerung erhalten bzw. im ESS Fall auch dorthin schreiben (Output Phase, Event EXECUTE_WRITE, HTTP Bridge). Vllt. macht es Sinn das heute mal als Feature Branch is offizielle Repo zu bringen, als Referenz für die Community. Wie kann ich da eigentlich ‘n Branch anlegen? Bisher kenne ich nur den Weg über Repository forken und ‘n PR erstellen.
Die Implementierung der Zwillings für den PV-Inverter, sowie der PLCnext-EZA-Regler-Controller steht noch aus. Für die PLCnext-EZA-Regler-Controller interessiert uns, wie der Controller-Modbus-API funktioniert, den ihr dafür verwendet. Wir würden gern die Werte des EZA-Reglers allen existierenden Controllern zur Verfügung stellen, um diese berücksichtigen zu können.
PS: Wenn ich mir den Code so anschaue, sehe ich mehrere Configs und Kanäle über die Limits des Netzbetreibers eingetütet werden könnten, z.B. über Edge Commons Meta.
