Hallo Community,
ich habe in den letzten Tagen mit TimeOfUseTariff und mit GridOptimizedCharge simuliert und bin über ein paar Beobachtungen verwundert, die ich mit Euch teilen möchte.
Ich habe folgendes Controller Setup.
Die Historie des heutigen Tages zeigt das der Speicher in den Morgenstunden nicht entladen wurde.
Das war auch mein Bestreben, soweit funktioniert es
Schaut man sich die TimeofUseHistorie an, so ist die Zuordnung nicht sofort erkennbar und durch die weiteren Controller schwierig zu interpretieren.
Die zugehörige GridOptimizedCharge Historie schaut so aus.
Die jetzige Prognose von heute Abend:
Die hätte ich etwas anders erwartet.
Habt Ihr vielleicht ein Idee warum da mitten im Tag die Beladung aus dem Netz freigegeben wird?
Ich habe den Time-Of-Use Tariff Awattar konfiguriert.
Danke!
Hallo Peter,
danke für die interessante Analyse. Tatsächlich ist das Zusammenspiel aus GridOptimizedCharge und Time-Of-Use noch nicht erprobt. Die beiden Controller “interagieren” nicht miteinander, d.h. sie wissen nichts voneinander. Das könnte dazu führen, dass deshalb der ToU-Controller eine Zwangsbeladung anstößt.
Eine detaillierte Analyse des Controllers kann man übrigens schön mit den Log-Ausgaben auf der Konsole machen. Die Daten können in das RunOptimizerFromLogApp-Programm eingespielt und so simuliert werden.
Durch deine Vorgabe, dass der Time-of-Use-Controller in der Priorität hinter dem GridOptimizedCharge-Controller liegt, dürfte das Verhalten im Endeffekt trotzdem passen, weil die Beladung des ToU-Controllers “ausgebremst” wird.
Gruß,
Stefan
Danke Stefan,
Ich habe den Log in der Console von Eclipse laufen und momentan kein File. Ich muss mir die Konfiguration, um Dateien zu generieren, erst anschauen.
Die Daten werden aber als Timedata RRD4J persistiert. Kann man die auch verwenden? Im Forum habe ich zwar einige Einträge dazu gefunden, aber ich bin nicht wirklich schlau daraus geworden.
In der UI kann man unter Historie die Viertelstundenwerte als Excel Datei herunterladen.
Bei der “Speicher Beladung” und “Speicher Entladung” gibt es zwar kWh Werte, aber keinen Viertelstundenwert in kW. Hast Du vielleicht eine Idee dazu warum das so ist?
Danke!
Mit besten Grüßen,
Peter
Bei mir läuft OpenEMS Edge als Systemd-Service. So lese ich die Logs dann via journalctl aus - z. B. journalctl -lu openems --since="20 minutes ago" | grep OPTIMIZER
Der Log sieht dann etwas so aus:
fems0 java[20605]: OPTIMIZER Params [numberOfPeriods=50, time=2024-01-31T11:30+01:00[Europe/Warsaw], essTotalEnergy=22000, essMinSocEnergy=1100, essMaxSocEnergy=19800, essInitialEnergy=1100, essMaxEnergyPerPeriod=2500, maxBuyFromGrid=5750, states=[BALANCING, DELAY_DISCHARGE, CHARGE], maxPrice=273.5]
fems0 java[20605]: OPTIMIZER Time Production Consumption EssInitial EssMaxCharge EssMaxDischarge State EssChargeDischarge Grid Price Cost
fems0 java[20605]: OPTIMIZER 11:30 316 665 1100 -2500 0 BALANCING 0 349 260.60 0.0909
fems0 java[20605]: OPTIMIZER 12:00 502 878 1100 -2500 0 BALANCING 0 376 258.00 0.0970
fems0 java[20605]: OPTIMIZER 12:15 571 790 1100 -2500 0 BALANCING 0 219 258.00 0.0565
fems0 java[20605]: OPTIMIZER 12:30 661 541 1100 -2500 0 BALANCING -120 0 258.00 0.0000
fems0 java[20605]: OPTIMIZER 12:45 774 252 1220 -2500 120 BALANCING -522 0 258.00 0.0000
fems0 java[20605]: OPTIMIZER 13:00 815 1142 1742 -2500 642 DELAY_DISCHARGE 0 327 249.40 0.0816
Aus der Params-Zeile ergeben sich die Eingangsvariablen ESS_CAPACITY, ESS_MIN_SOC, ESS_MAX_POWER, etc. → openems/io.openems.edge.controller.ess.timeofusetariff/test/io/openems/edge/controller/ess/timeofusetariff/optimizer/RunOptimizerFromLogApp.java at develop · OpenEMS/openems · GitHub
Der untere Teil kann dann in die LOG-Variable kopiert werden → openems/io.openems.edge.controller.ess.timeofusetariff/test/io/openems/edge/controller/ess/timeofusetariff/optimizer/RunOptimizerFromLogApp.java at develop · OpenEMS/openems · GitHub
So kann man die Simulation lokal in Eclipse testen und z. B. Breakpoints setzen.
Bei der “Speicher Beladung” und “Speicher Entladung” gibt es zwar kWh Werte, aber keinen Viertelstundenwert in kW. Hast Du vielleicht eine Idee dazu warum das so ist?
Das weiß ich auf Anhieb auch nicht. Scheint vielleicht ein Problem mit der RRD4j zu sein - hängt evtl. damit zusammen: Timedata Error (aggregated0 and influx0) - #9 by Sn0w3y. Ein Breakpoint hier könnte bei der Analyse helfen: openems/io.openems.common/src/io/openems/common/jsonrpc/response/QueryHistoricTimeseriesExportXlsxResponse.java at develop · OpenEMS/openems · GitHub
Gruß,
Stefan
1 Like
