Ja genau, PV-Leistung wird nur zum Entladen berücksichtigt, wenn sie >= 100W ist.
Ich wollte hiermit vermeiden, dass ein Wechselrichter am Morgen bzw. Abend permanent aktiv/inaktiv wird. Denn wenn ein WR PV-Leistung generiert, wird er bevorzugt verwendet, auch wenn er ggf. lt. Gewichtung nicht verwendet werden würde. Dies kann dazu führen, dass in einem Cycle (PV-Leistung vorhanden) Wechselrichter A genutzt wird und im nächste Cycle (keine PV-Leistung vorhanden) Wechselrichter B und im nächsten Cycle dann wieder Wechselrichter A usw. Durch die Grenze von 100W sollte dass denke ich ganz gut vermieden werden.
Wenn zudem für ein paar Minuten <100W Leistung generiert wird, ist es m.E. nicht nachteilig diese Leistung in die Batterie zu bringen anstatt sie direkt abzurufen. Die Effizienzwerte von Wechselrichtern sind bei <100W ohnehin nicht wirklich gut. Meine Annahme ist, dass sich die PV-Anlage nicht lange in dem Bereich <100W bewegen sollte, oder ist dass bei dir anders?
In anderen Implementierungen werden übrigen ebenfalls Leistungen <100W ignoriert.
Das ist mit einem Screenshot alleine nicht nachzuvollziehen. Der Optimizer macht ja selbst keine Lade-/Entladevorgaben, er verteilt nur die Vorgaben unter Berücksichtigung der gesetzten Constrains auf die Speichersysteme. Sollte er nicht auflösen können, müsste ein Fehler im Log protokolliert werden.
Um den Grund herauszufinden, wieso hier nicht entladen wurde, wäre folgendes interessant:
Welche Speichersysteme und Controller sind aktiv? Gibt es evtl. Controller für LimitTotalDischarge oder SOC-Reserve?
Welche Lade/-Entladevorgaben waren aktiv?
Welche Werte für AllowedDischarge hatten die Speichersysteme zu der Zeit? Also war eine Entladung vom BMS freigegeben?
Der angezeigte Wert ist zudem ein Mittelwert. Bei mir wird der eine Speicher bis 7% entladen, der andere bis 10%, ergibt 8,5% minSoc über beide Speichersysteme.
Ohne weitere Informationen zur Konfiguration des Systems und weiteren Detailinformationen ist es schwierig Rückschlüsse auf dieses Verhalten zu schließen.
Ein Beispiel: Ich hatte auch bereits ein Verhalten welches für mich auf den ersten Blick merkwürdig aussah, bei genauerer Analyse, hat sich herausgestellt dass es genau richtig war. In meinem Fall wirkte ein Power-Constraint auf einen der beiden ESS, der eine Beladung erzwungen hatte (durch den LimitTotalDischarge Controller). Dadurch wurde ein ESS geladen, obwohl eigentlich gerade entladen werden sollte. Der andere ESS wurde entsprechend entladen.
Dann habe ich z.B. einen gridOptimizedCharge Controller aktiv, der ab einem gewissen Zeitpunkt die maximale Beladung begrenzt.
Um hier eine Idee zum Verhalten zu bekommen kannst du in der solvePower-Methode die Variable debug mal auf true setzen und dann im Debug Log nach dem Output schauen. Dort sollte der vom System vorgegebene PowerSetPoint (also die gewünschte Lade- bzw. Entladeleistung über alle ESSs) geloggt werden sowie Details dazu, wie diese Lade-/Entladeleistung auf die einzelnen ESSs verteilt wird. Schau mal ob der PowerSetPoint bei deinem letzten Screenshot wie folgt geloggt wird:
[ACTIVE] PowerSetPoint: -300.0, Direction: CHARGE
In diesem Fall wäre das Verhalten des Optimizers richtig und die Vorgabe liegt einfach bei -300W. Dann muss man weiter vorne schauen, welche Constrains gibt es und welcher Controller sollte welchen PowerSetPoint vorgeben. Dazu mal das Debug der PowerKlasse einschalten und im Log von meinem Optimizer mal nach den min und max Werten eines jeden ESS schauen, dort werden die jeweils möglichen min und max Werte angzeigt:
Setze bitte mal in der solvePower-Methode die Variable debug=true, dann sollte wesentlich mehr im Debug kommen. Daran erkennt man die Vorgabe (müsste DISCHARGE 5089 sein), die Grenzen der ESS (also min und max Grenzen der aktuell erlaubten Setpoints) und wie die Vorgabe auf die ESS verteilt wird.
Ich sehe gerade, dass die Variable beim Commit noch auf true stand. Wenn jetzt nichts im Debug kommt, ist entweder KEEP_ZERO aktiv oder der Optimizer gar nicht aktiv.
Wenn dann immer noch nichts kommt, bitte mal schauen ob der Optimizer auch ausgewählt ist. Falls ja mal neustarten und schauen was geloggt wird. Wechselt er ggf in einen Fallback-Optimizer, da die Vorgabe (aufgrund bestehender Constraints) nicht umsetzbar ist?
Was steht im DebugLog für den FeneconHome als „Allowed:“?
Also was ich sehe ist, dass der ess0 mit 739W entladen soll aber nicht entlädt. Kannst du nachvollziehen ob die 739W beim ess0 in der applyPower Methode ankommen und an den Speicher weitergegeben werden?
Was mir zudem nicht ganz klar ist, ob die REACTIVE Power genau wie die ACTIVE Power aufgelöst werden kann, sprich die Umsetzung für REACTIVE Power so passt. Bei meinen Speichersystemen wird mE ausschließlich mit der ACTIVE Power gearbeitet.
Macht für mich auch keinen Sinn. Führt der Fenecon evtl. eine Zwangsbeladung durch? Was sagt der DcOptimizer als Ergebnis und was zeigt er als min und max Wert für den Fenecon an?
Oder gibt es evtl ein ctrlLimitTotalDischarge der eine Zwangsbeladung durchführt oder im BlockDischarge (minSoc) State ist? Der Controller setzt seinen Target auf AC, d.h. wenn minSoc erreicht ist, wird der AC PowerSetPoint auf 0 gehalten. AC 0 bedeutet, dass jegliche PV (DC) Leistung in die Batterie geladen wird.
So sieht es bei mir aus (mit 2 HybridEss) und einen erweiterten ctrlLimitTotalDischarge Controller mit Target DC.
Oct 29 08:08:31 sems200 java[2403]: [ACTIVE] ess1: PVProduction: 0.0, min: -3033.0, max: 1996.0 → ess1 EQUALS 0.0
Oct 29 08:08:31 sems200 java[2403]: [ACTIVE] Solved Solution for ess1: EQUALS 0.0 (should be equal to added constraints!!)
Oct 29 08:08:31 sems200 java[2403]: Solution → ess1 ACTIVE 0.0 | 0.0
Nein, den gibt es auch nicht. Ich habe einen ctrlEmergencyCapacityReserve auf dem ess1 und dem ess4 (die 2 DC Speicher) aber beim ess1 (Fenecon) ist dieser deaktiviert.
