SetActivePowerLessOrEquals wird per REST alle 30 Sekunden auf 0 gesetzt
API-Timeout ist auf 60 Sekunden gesetzt
ctrlApiRest0 ist relativ weit oben im Scheduler - Nur ctrlLimitActivePower0, ctrlLimitTotalDischarge0 und ctrlEmergencyCapacityReserve0 sind noch darüber
PV-Erzeugungsleistung ist vorhanden
Speicher ist auf ca 56% geladen
Erwartung: SetActivePowerLessOrEquals=0 sorgt dafür, dass der Speicher nicht mehr enladen wird. Eine Beladung erfolgt weiterhin, sofern Überschuss vorhanden.
Ergebnis: openEMS schickt die komplette PV-Erzeugungsleistung beladend in den Speicher. Sämtliche Hausenergie wird aus dem Netz genommen.
Hat jemand eine Idee, wieso das so ist? Die Thematik kommt aus dem EVCC-Bereich (https://evcc.io/). Dort haben aber mehrere das Problem. Die Thematik lässt sich aber schwer eingrenzen, da es manche openEMS/FEMS User gibt, bei denen es wie erwartet funktioniert und andere (wie mich), bei denen obiges Ergebnis dabei herauskommt.
EVCC ist als Ursache ausgeschlossen, da man das ganze auch mittels eigener REST-Calls bzw. auch direkt in der UI mittels setzen des Channels nachstellen kann.
Aus der Doku zu den Werten werden ich leider nicht so ganz schlau. Mir scheint SetActivePowerLessOrEquals sollte hier schon das richtige sein.
SetActivePowerEquals
Wirkleistungsvorgabe eines Fixwerts in [W]. Negativer Wert für Beladung, positiver Wert für Entladung.
SetActivePowerLessOrEquals
Wirkleistungsvorgabe eines Maximalwerts in [W], z. B. um eine maximale Entladung oder eine Zwangsbeladung (negativer Wert) vorzugeben.
SetActivePowerGreaterOrEquals
Wirkleistungsvorgabe eines Minimalwerts in [W], z. B. um eine maximale Beladung (negativer Wert) oder eine Zwangsentladung (positiver Wert) vorzugeben.
Balancing setzt: Power = calculatedPower (z.B. -5000W für volle Beladung)
Beide Constraints werden gleichzeitig an den Solver übergeben!
Der Solver sieht:
Power <= 0 ✓
Power = -5000 ✓ (erfüllt auch <= 0)
→ Lösung: Power = -5000 (volle Beladung)
Warum es bei anderen funktioniert
Bei Nutzern, wo es funktioniert, ist wahrscheinlich der CtrlEssBalancing deaktiviert (nicht nur targetGridSetpoint=0, sondern enabled=false).
Mit enabled=true und targetGridSetpoint=0 berechnet der Balancing Controller aktiv einen Zielwert und überschreibt Ihre Intention mit einer EQUALS-Constraint.
Lösung
Option 1: CtrlEssBalancing komplett deaktivieren (enabled=false) wenn Sie via REST steuern
Option 2: Scheduler-Reihenfolge ändern - CtrlEssBalancing VOR ctrlApiRest0 setzen, damit die REST-Constraint Vorrang hat
Option 3: Statt SetActivePowerLessOrEquals=0 den Balancing Controller via REST steuern:
Channel ctrlEssBalancing0/SetGridActivePower auf den gewünschten Grid-Setpoint setzen
Der CtrlEssBalancing hat dafür extra einen Channel (Zeile 91-92 in ControllerEssBalancingImpl.java):
int targetGridSetpointValue = this.getSetGridActivePowerNextWriteValue()
.orElse(this.config.targetGridSetpoint());
Das würde EVCC erlauben, den Grid-Setpoint dynamisch zu ändern, anstatt direkt die ESS-Leistung zu steuern.
Die Entladungssperre zieht also nicht mehr. Scheinbar möchte der, nun höher priorisierte, balancing-controller entladen und der REST-controller darf das nicht überschreiben.
Im Log findet sich dann das hier: [Channel [SetActivePowerLessOrEquals]] increasing requested [0 W] to minimum power [7084 W] for [ess0P]
Option 1 funktioniert ebenfalls nicht (“Is Enbaled?” im UI auf false gesetzt). Das Ergebnis ist das gleiche as wenn der balancing Controller unterhalb des REST controllers ist: Sämtliche PV-Erzeugung wird komplett in the PV geladen:
Option 3: Wie Option 3 mittels evcc funktionieren soll, kann ich leider nicht nachvollziehen. Dann müsste evcc ja berechnen, ob das EMS Strom einspeisen oder beziehen soll und dann noch den korrekten Wert dazu. Mit einem Update-Intervall von 10-30 Sekunden macht das nicht viel Sinn.
Hast du einen Hybridwechselrichter? Dann achte darauf, dass du die AC-Wirkleistung vorgibst, und nicht die Batterieleistung. Sprich, mit einer SetActivePowerLessOrEquals 0 gibst du vor, dass AC-seitig nichts ausgespeist wird, was erklärt, warum die ganze PV-Leistung in die Batterie geladen wird. Wenn die Batterie voll ist, würdest du so sogar die PV abregeln.
Deshalb funktioniert der Tiefenentladeschutz auch nicht für Hybrid-Systeme, siehe mein Kommentar hier: Wechselrichter "schaltet sich ab"
Das heißt konkret den REST Controller höher priorisiert lassen als den balancing controller (entgegen der Aussage von @Sn0w3y ) und bei zB 1kW Erzeung SetActivePowerLessOrEquals auf 1000 setzen?
Mal unabhängig davon ob das funktioniert oder nicht: Warum sollte man das als API-User unterscheiden müssen, anhand der verwendeten Hardware? Das müsste doch innerhalb von openEMS gehandhabt werden. Ansonsten verhält sich das System doch komplett anders, je nachdem ob man einen Hybridwechselrichter hat oder nicht.
EDIT: Der Vollständigkeit halber - Ja, ich habe einen Hybridwechselrichter.
Das heißt konkret den REST Controller höher priorisiert lassen als den balancing controller (entgegen der Aussage von @Sn0w3y ) und bei zB 1kW Erzeung SetActivePowerLessOrEquals auf 1000 setzen?
Ja, das sollte gehen. Die PV-Leistung bekommst du dann heraus als Differenz zwischen Active Power und DC Discharge Power.
Mal unabhängig davon ob das funktioniert oder nicht: Warum sollte man das als API-User unterscheiden müssen, anhand der verwendeten Hardware? Das müsste doch innerhalb von openEMS gehandhabt werden. Ansonsten verhält sich das System doch komplett anders, je nachdem ob man einen Hybridwechselrichter hat oder nicht.
Man muss nicht unterscheiden, denn auch im nicht-hybriden Fall steuert man ja die AC-Leistung des Wechselrichters, nur dass die (bis auf Verluste bei der Umwandlung) gleich der DC-Leistung der Batterie ist. Es ist vielleicht nicht so intuitiv bei Hybrid-Systemen, und leider funktionieren auch nicht alle Controller mit Hybrid-ESSs, aber konsistent ist es schon.
Jetzt nochmal für mich als Laie: Bei einem Hybridwechselrichter muss ich mit SetActivePowerLessOrEquals dafür sorgen, dass genau so viel Energie AC-seitig aus dem Akku genommen wird, wie PV-seitig generiert wird, außer die PV-Erzeugung ist größer, als das was Lastseitig benötigt wird? Damit erreiche ich dann eine Entladesperre, ohne das die komplette DC-Leistung stupide in den Akku geht obwohl Haus-seitig Last angefragt wird.
Wenn das so stimmt, wieso funktioniert es dann wie erwartet (SetActivePowerLessOrEquals=0 sorgt nicht für stupide DC-Beladung) bei einigen Leuten mit openEMS und Hybridwechselrichtern?
Das System verhält sich zwar innerhalb der Vorgaben, aber es braucht einen Weg die Entladungsleistung eines ESS sinngemäß zu regulieren, ohne die PV Leistung extern zu berücksichtigen.
Es gibt mehrere FEMS User, die das gleiche Problem des TE berichtet haben. Eine Lösung gab es bisher nicht. Das Setzen des EQUALS anstelle LessOrEquals auf Null funktioniert bei einigen (etwas unsicher in der “Behauptung” - aus dem Gedächtnis von vor Wochen) - leider nicht hier.
Die Intention ist hier nicht einen Wechselrichter zu steuern, sondern das Verhalten eines Batteriesystems zu regulieren, um eine nicht sinnvolle Batterieentladung zu verhindern und
eine Beladung mit möglichem Überschuss zu erlauben.
Ich habe einen Kostal WR, der sich als hybrider WR steuern lässt. Durch die Rest Vorgabe wird die Entladungsleistung der Batterie geregelt, die PV Leistung wird trotzdem ins Netz eingespeist, bzw. gleicht anteilig den Hausverbrauch aus.
Lade ich schnell (erzwungen, 7.2kW) wird die benötige zusätzliche Energie aus dem Netz gezogen, eventuelle PV reduziert den Netzbezug und die Ladung der Batterie ausgesetzt.
Der Rest-Controller ist bei mir aktiv ganz oben einsortiert; Balancing läuft unsortiert ausserhalb des all alphabetic Schedulers.
Ich möchte die Diskussion mit Bezug zum KACO WR nicht kapern. Der gemeinsame Bezug besteht wegen der externen Steuerung durch den Rest-API Controller und der Nutzung von evcc - ich habe dort versucht zu unterstützen.
Bei Bedarf stelle ich dafür auch gern eine eigene Diskussion ein.
Ja genau (vorausgesetzt du meinst mit “AC-seitig aus dem Akku genommen” soviel wie “von DC in AC umgewandelt wird” oder “vom ESS mittels ActivePowerSetpoint angefordert wird”). Wie @tsicking weiter oben geschrieben hat, wird gemäß OpenEMS Grundlagen mit dem ActivePowerSetpoint immer die gewünschte AC-Leistung des Wechselrichters vorgegeben.
Wenn es nun Nutzer mit Hybrid-Wechselrichter gibt, bei denen mit einem ActivePowerSetpoint <= 0 die gesamte PV-Leistung in AC gewandelt wird (und somit ActivePowerSetpoint = PV-Leistung ist), kann dies mE 2 Gründe haben:
Die Batterie kann nicht geladen werden (zB da voll) und der Wechselrichter limitiert die PV-Leistung nicht sondern speist den Überschuss ins Netz ein (und ignoriert somit die Vorgabe <= 0, zB da die Implementierung keine PV-Limitierung zulässt oder unterstützt)
Der Hybrid-Wechselrichter ist nach OpenEMS-Grundlagen „falsch“ implementiert. Mir ist min. eine Implementierung bekannt, bei der der ActivePowerSetpoint nicht die AC-Leistung sondern die DC-Batterieleistung steuert. Das ist sicherlich bei einigen Hybrid-Wechselrichtern einfacher zu implementieren, aber entspricht nicht den OpenEMS Grundlagen. (Die mir bekannte Implementierung ist aber nur in einem Fork bereitgestellt und nicht im offiziellen OpenEMS repo)
Ansonsten sollte aber der Controller ctrlFixActivePower für das gewünschte Verhalten genutzt werden können, mit den folgenden Einstellungen (und natürlich entsprechender Priorisierung im Scheduler):
Mode: Manual On
Hybrid-ESS Mode: Target Dc
Charge/Discharge power [W]: 0
Power Relationship: Less Or Equals
Damit wird eine DC-Batterieleistung von <= 0 Watt vorgegeben.
Jetzt habe ich mich mit der Rest-API noch nicht beschäftigt, aber wen man mit diesem den Mode zwischen “Manual On” und “Manual Off” beschreiben kann, dann sollte man darüber das gewünschte Verhalten erreichen. Andernfalls müsste man einen eigenen Controller dafür implementieren, die Logik kann man dem genannten Controller entnehmen. Dieser berechnet bei jedem Cycle den gewünschten ActivePowerSetpoint und setzt entsprechend den korrekten Constraint dazu.
