Hallo zusammen,
ich habe ein komisches Verhalten bei oben genannter Konfiguration festgestellt. Ich habe:
Dazu einen ToU von Tibber. Wenn nun aber TibberController entscheidet, den Speicher nicht mehr zu entladen (Entladung verzögert), dann wird einer der Speicher entladen und der andere Beladen.
Power Solver steht auf Keep all Equal. Aber egal welches Setting ich da nutze, das Verhalten bleibt gleich.
Grüße !
Hallo Sn0w3y,
grundsätzlich funktioniert der Algorithmus auch bereits mit mehreren Speichern - wir beobachten das erfolgreich am “FENECON Commercial 92 Clustersystem” (https://fenecon.de/fenecon-commercial-92/).
Mit deiner Beschreibung ist es aber noch schwer nachzuvollziehen. Bitte dokumentiere mal das komplette Anlagenprofil - also welche Komponenten sind konfiguriert, und welche Controller wirken auf welche Komponenten (z. B. “ess0” ist ein Ess.Cluster; ToU-Controller ist auf “ess0” konfiguriert, usw.)
Außerdem wäre interessant zu sehen, was “DebugSetActivePower” der jeweiligen ESSs enthält.
Gruß,
Stefan
Hi Stefan,
danke für deine Antwort:
Komponenten:
Das Cluster(ess2) hat ess0 und ess1 als Parameter übergeben.
Der ToU Controller und GridOptimizer wurde auf ess2 eingestellt.
Übrigens passiert das auch beim Grid Optimizen.
Die DebugSetActivePower habe ich leider grade nicht, da er Eigenverbauch brav macht 
Übrigens passiert das auch beim Grid Optimizen.
Dann würde ich erstmal einen FixActivePower-Controller auf ess2 versuchen. Wenn das nicht klappt, kommst du an den DebugSetActivePower-Channels nicht vorbei.
Versuch wirklich mal einen FixActivePower-Controller auf ess2 und schau ob die Leistung gleichmäßig verteilt wird.
Wenn sie nicht gleichmäßig verteilt wird und Ess.Power die richtige Strategie konfiguriert hat, haben die einzelnen Speicher vermutlich einschränkende Constraints. Das könnte man am am Channel _power/SolveStrategy ablesen: dort sieht man dann, welche Strategy tatsächlich funktioniert hat (openems/io.openems.edge.ess.core/src/io/openems/edge/ess/core/power/EssPower.java at develop · OpenEMS/openems · GitHub)
Dann kannst du mal versuchen ob FixActivePower auf die einzelnen ESS zum richtigen Ergebnis führt - vermutlich klappt das nicht, führt dich aber schrittweise näher zum Ziel…
Egal was ich versuche, der Sax wird nicht beladen:
ess4[SoC:26 %|L:7 W|On-Grid|Allowed:-3680;3680 W]
dieser ist quasi nun auch teil der ess2 Cluster
Vermutlich ist der Channel MaxApparentPower nicht gesetzt.
Genau das war es Stefan.. Danke..
Nun versuche ich mal nochmal mit einem FixActivePower “darüber zu bügeln” und schaue was passiert.
Nun genau das Szenario, welches ich meinte:
Wieso entlädt er jetzt einen Speicher und die anderen werden BEladen ?
Das macht er immer so, wenn er 0kW setzt..
Grüße !
Wie oben gesagt: ohne die ganzen Detaildaten kann ich dazu nichts sagen. Ich kann nur sagen: wenn man alles richtig gemacht hat, wird OpenEMS es gleichmäßig richtig verteilen. 
modbus0)charger0 via modbus0)charger1 via modbus0)charger2 via modbus1)charger3 via modbus1)ess0 via modbus0)batteryInverter0 via modbus2)battery0 via modbus3) steht auf Autoess0 via modbus0)ess1 via battery0 und batteryInverter0)ess2 via modbus4)ess3 mit ess0 ess1 ess2)ess3)ess3)ess3)meter0 via modbus0)Ein kleiner Log-Auszug:
15.5.2025, 15:55:55
INFO
io.openems.edge.ess.core.power.Solver
- Channel [SetActivePowerEquals]+ess3P EQUALS 716
15.5.2025, 15:55:55
INFO
io.openems.edge.ess.core.power.Solver
Currently active EQUALS constraints
15.5.2025, 15:55:55
INFO
io.openems.edge.controller.debuglog.ControllerDebugLogImpl
[ctrlDebugLog0] _energy[ScheduledPeriods:129|SimulationCounter:946|PerQuarter:34]
_sum[State:Info Ess SoC:99 %|L:2032 W Grid:1131 W Production Total:3586 W,AC:320 W,DC:3266 W Consumption:3483 W]
battery0[Running|SoC:99 %|Actual:237 V;5 A|Charge:245 V;8 A|Discharge:210 V;40 A]
batteryInverter0[AllowedAC:-410;7411 W|State:INFO: Communication failure]
charger0[L:863 W]
charger1[L:917 W]
charger2[L:736 W]
charger3[L:750 W]
ctrlEssTimeOfUseTariff0[BALANCING]
ess0[SoC:100 %|L:1793 W|On-Grid|Allowed:0;11453 W]
ess1[Started|SoC:99 %|L:117 W|Battery:-1369 W|PV:1486|Allowed:-1896;10000]
ess2[SoC:92 %|L:122 W|SmartMeter:-16385 W|-3680 W|3680 W]
io1[1x 2- 3- 4- 5- 6- 7- 8-]
io2[69 W]
io4[x|1 W]
io6[100 W]
io7[122 W]
io9[x|9 W]
io10[29 W]
io11[1- 2- 3- 4-]
io12[-|0 W]
meter0[L:1131 W]
meter2[L:40 W]
temp1[74.9°C | 43.4°C | 20.4°C]
timeOfUseTariff0[Price:0.1727 EUR/kWh]
Es ist so komisch.. ich weiss nicht wieso das passiert..
@stefan.feilmeier ich hoffe die Daten reichen 
Sollte das nicht charger3 anstelle von charger1 heißen, damit die Komponenten eindeutige IDs haben? Oder war das nur ein Tippfehler?
Hat mit dem Kernproblem nichts zu tun, war aber ein Tippfehler..
Update heute früh:
Bei 0kW Beladegrenze des ctrlGridOptimizedCharge entlädt ein Speicher angeblich und der andere belädt. Den einen Speicher entlädt er so lange, bis er an der Notstromreserve ist, danach belädt er Ihn (weil er die Reserve unterschreitet) aus dem Netz.
ESS-Cluster ist nicht für Hybrid-Systeme optimiert. Kann sein, dass das bei dir zu Problemen führt.
Hmm, dann werde ich mich mal an ein Cluster machen, welches das kann 
Die Frage ist nur, woher bekommt denn das Cluster die Gesamtleistung zum verteilen? Aus _core/EssPower oder?
Also wenn ich das richtig sehe liegt das Problem darin, dass die ActivePowerSetpoints für ess0 und ess2 bei 0 liegen, da kein Controller eine Entladung anfragt.
Der ActivePowerSetpoint ist immer die gewünschte AC-Leistung des Wechselrichters. Bei einem Hybridsystem beinhaltet diese auch die PV-Leistung die in AC umgewandelt werden soll. Das heißt, wenn der Charger (PV-String) 1000W generiert und die Batterie nicht geladen werden soll, muss eine „Entladung“ von 1000W requested werden. Dazu wird der ActivePowerSetpoint auf 1000 gesetzt. Wird der ActivePowerSetpoint auf 0 gesetzt bzw keiner vorgegeben (was gleichbedeutend wie 0 ist), muss ja die gesamte PV-Leistung in die Batterie gehen um die Vorgabe von 0W AC umsetzen zu können.
Es gibt einen FeedSurplusToGrid Controller, versuch doch mal einen solchen für jedes ESS anzulegen, der sollte dann den Setpoint auf die jeweilige PV-Leistung setzen. Dieser müsste dann natürlich die niedrigste Prio haben, sodass der nur greift, wenn keine andere Lade-/Entladevorgabe für das ESS besteht.
Grüße
Das ist ja das komische, dass das sehr sehr sporadisch passiert, ich hab jetzt mal die Controller angelegt, aber bei ess2 bekomme ich aktuell noch:
_componentManager[Defective:ctrlEssSurplusFeedToGrid2[Unsatisfied reference for ess ((&(enabled=true)(!(service.pid=Controller.Ess.Hybrid.Surplus-Feed-To-Grid.bf58ee24-f3db-48c3-82a4-b40955ae8fe4))(|(id=ess2))))]|State:FAULT: A configured OpenEMS Component was not activated]
Ich weiss schön langsam selbst als “OpenEMS-Mittelklasse-Programmierer” nicht mehr weiter..
Egal wie es hier aussieht:
Es steht aktuell beispielsweise immer so:
Nach einem Neustart von ess Cluster:
Und anstatt jetzt alles überschüssige in den Sax zu schicken macht er zuerst “Yelon” voll und dann erst den Sax:
Das ist doch komisch…
Please try changing the solver strategy to one other than ‘keep near equals’ or ‘keep near equals too’,
for example use ‘OPTIMIZE_BY_MOVING_TOWARDS_TARGET’.
