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.
Wir geben über den Modbus-API Controller die Channels z. B. für SetActivePowerEquals frei; damit gibt der EZA-Regler dann Set-Points für den einzelnen Speicher bzw. den Speicher-Cluster vor (siehe FEMS App Modbus/TCP schreibend :: FENECON Dokumente)
Es gibt derzeit noch keinen Mechanismus, um ein Limit vorzugeben, das OpenEMS dann selbst auf Speicher, Ladesäulen etc. verteilt.
Ja, weil es verschiedene Use-Cases bzw. Systemkonfigurationen gibt. Der SetActivePowerEquals bezieht sich eben nur auf Speicher; für komplexere Anwendungen evaluiere ich intern gerade, das vielleicht in _meta abzubilden - so dass dann eine interne Logik die Verteilung auf Speicher, Ladesäulen etc. übernehmen kann. Eine andere Überlegung ist, zu jedem “ElectricityMeter” einen “Companion-Service” zu haben, mit dem dann modelliert werden kann, welche Limits an der entsprechenden physischen oder virtuellen Messstelle eingehalten werden müssen. (z. B. für einen Ladepark an einer Unterverteilung)
Schwierig ist, dass die Use-Cases sehr unterschiedlich sein können und es auch nicht over-engineered sein soll.
Hi @stefan.feilmeier ,
sehe ich das richtig, dass die Werte für SetActivePower… und SetReactivePower… ab Modbus Register 0x0706 auf den Bus zum “Slave” des Modbus API Controllers gegeben werden müssen, damit der die Werte weiter ans ESS0 kommuniziert?
Muss ich zum Testen innerhalb der IDE einen Modbus-Server aufsetzen oder zieht die Modbus-Bridge einen Bus hoch, an dem sowohl der neue “Master” (= PLCnext EZA Regler) und der “Slave” (= ControllerModbusApiTcpReadWrite) hängen?
Zur kurzen Begriffsklärung, weil ich selbst immer durcheinander komme.
The device requesting the information is called the Modbus Master and the devices supplying information are Modbus Slaves. In a standard Modbus network, there is one Master and up to 247 Slaves, each with a unique Slave Address from 1 to 247. The Master can also write information to the Slaves.
Antwort auf die offene Frage: Generiert ist davon gar nichts, alles von Hand gecodet mit dem Wissen eines Entwicklers, der sein erstes OpenEMS Modul schreibt.
Hab dem PR heute morgen ein Update verpasst. Die Anmerkung das die Kommunikation mit dem Device asynchron laufen muss um den Cycle nicht zu sprengen, war bislang nicht umgesetzt. Mit dem Update ist das jetzt bis in die Komponenten durchgezogen. Beim Erstellen der Komponenten und der zugehörigen Klassen hab ich es mir erstmal etwas einfacher gemacht.
Die Treiber können gern in den Review-Prozess der Community einbezogen werden. Wenn Dinge geändert werden müssen, die in OpenEMS anders gemacht werden, müssen wir das entsprechend anpassen. Ansonsten wird an den Treibern selbst nicht mehr großartig gearbeitet.
Wie gesagt, was OpenEMS angeht hab ich aktuell nur Halbwissen. Daher sehe ich es als völlig normal an, dass da Änderungswünsche formuliert und Korrekturen gemacht werden.
Sollten wir noch ein paar Steps in Richtung der Business-Logik mit den Controllern schaffen, würde ich dafür einen separaten PR stellen wollen. Den Review-Prozess der Community habe ich so verstanden, dass PRs möglichst modulweise gestellt werden sollen. Korrekt?
Antwort auf die offene Frage: Generiert ist davon gar nichts, alles von Hand gecodet mit dem Wissen eines Entwicklers, der sein erstes OpenEMS Modul schreibt.
Ok - no offense! Wir merken sehr stark, dass viele Module mittlerweile durch KI erzeugt werden und die Qualität ist oft schlecht bzw. uneinheitlich.
Die Treiber können gern in den Review-Prozess der Community einbezogen werden. Wenn Dinge geändert werden müssen, die in OpenEMS anders gemacht werden, müssen wir das entsprechend anpassen. Ansonsten wird an den Treibern selbst nicht mehr großartig gearbeitet.
FENECON-intern reviewen wir natürlich deutlich intensiver - der Ressourcenaufwand lässt sich für externe OpenEMS-Contributions aktuell nicht darstellen. Deshalb ist hier nur wichtig, dass die Coding Guidelines eingehalten werden, es eine möglichst große Testabdeckung gibt und es in der Praxis funktioniert.
Sollten wir noch ein paar Steps in Richtung der Business-Logik mit den Controllern schaffen, würde ich dafür einen separaten PR stellen wollen. Den Review-Prozess der Community habe ich so verstanden, dass PRs möglichst modulweise gestellt werden sollen. Korrekt?
Ja, korrekt. Ich denke wir können im ersten Schritt diesen einen großen PR mergen. Weitere Verbesserungen sollten dann modulweise sein.
