Guten Tag zusammen,
ich bin relativ neu im Umgang mit OpenEMS, durfte jedoch feststellen, dass die Möglichkeiten, die OpenEMS bietet, sehr umfangreich sind.
Ziel meines Vorhabens ist die Untersuchung der Wirtschaftlichkeit von Batteriespeichern im Rahmen einer Abschlussarbeit. Um eben diese wirtschaftlich zu betreiben zu können, sollen die Energieflüsse durch OpenEMS geregelt werden.
Zur Zeit beschäftige ich mich mit der Simulation von historischen Daten, dazu habe ich eigene CSV-Dateien eingebunden, die ich über “Simulator DataSource: CSV Predefined” abrufen kann.
Dazu habe ich folgende Konfigurationen vorgenommen:
- Controller Api Websocket
- Controller Debug Log
- Controller Ess Limit Total Discharge (ess0; 20 ;-1 ;0)
- Controller Peak-Shaving Symmetric (ess0; meter2; 8800, 0)
- Scheduler all Alphabetically
- Simulator Datasource: CSV Predefined (datasource0) (Lastgang)
- Simulator Datasource: CSV Predefined (datasource1) (PV-Produktion)
- Simulator EssSymmetric Reacting (ess0; 10000; 30000; 0; ON_GRID)
- Simulator Grid Meter Reacting (meter2)
- Simulator NRCMeter Acting (meter0; datasource0)
- Simulator ProductionMeter Acting (meter1; datasource1)
- Timedata RRD4J
Um den Batteriespeicher (30000 Wh) über einen Zeitraum von 11,25 Stunden vollständig zu entladen, habe ich in einer separaten Datei berechnet, um wie viel kWh der Speicher pro Stunde entladen werden muss. Diesen Wert habe ich dann vom durchschnittlichen Verbrauch der 11,25 Stunden subtrahiert und 8800 erhalten (deswegen auch das PeakShaving auf 8800). Entgegen meiner Erwartungen hat sich der Batteriespeicher in den 11,25 Stunden jedoch nur von 94 % auf 73 % entladen (Siehe Markierung in angehängten Screenshots). Über jede Hilfe zu diesem Fehler, ob meinerseits oder seitens OpenEMS wäre ich sehr erfreut.
Außerdem möchte ich im nächsten Schritt eine InfluxDB einbinden, in die die Daten geschrieben werden. Damit ich die Daten extern abrufen kann, würde ich diese gern in InfluxDB Cloud schreiben lassen, gibt es dort Erfahrungsberichte aus der Community?
Hallo HannesKI,
ich kann bestätigen, dass es noch einen bug in der SOC Bestimmung gibt. In der angestellten Abbildung sieht man, dass ich den speicher (136 kWh) mit durchschnittlich 75 kW lade (ess0/ActivePower) und der Speicher trotzdem fast einen Monat braucht um auf 100% SOC zu kommen. Ich vermute, dass für die SOC bestimmung der falsche Zeitstempel verwendet wird, nämlich die Cycle time des Simulators und nicht diejenige des System-Cycle. Leider habe ich aktuell nicht genug Zeit mich in die Thematik einzuarbeiten würde mich aber auch sehr über einen Bugfix freuen.
Zur InfluxDB lässt sich sagen, dass man hier auch sehr schnell in das Zeitstempel Problem reinrennt. So wie ich es verstehe erzeugt die Influxdb erstmal einen eigenen Zeitstempel, der aber dann nichts mit deiner Simulationszeit zu tun hat. Ich stoße meine Simulationen deshalb mit einem Python script über die REST API an, ziehe mir die Ergebnisse und verarbeite sie dann über Python. Hat den Vorteil, dass ich so verschiedene Inputparameter variieren kann.
Leider ist die Simulation vergleichsweise langsam. Wenn jemand weiß, wie man den Simulations-Cycle etwas beschleunigen kann, freue ich mich sehr über die Info.
LG,
Nils
Zum Thema InfluxDB Cloud kann ich was sagen. Zur Zeit unterstützt OpenEMS ausschliesslich die Persistierung in Influx DB v1 Datenbanken. InfluxDB Cloud basiert jedoch auf der neuen Version 2 der Datenbank mit neuer API.
Ich schreibe aktuell die Daten über einen Umweg in die InfluxDB Cloud: ich habe lokal eine Telegraf Instanz aufgesetzt, die einen InfluxDB v1 Listener bereitstellt. Dorthinein schreibt OpenEMS. Telegraf schreibt die Daten dann in die InfluxDB Cloud. Es ist zu beachten, dass die kostenfreie Variante der InfluxDB Cloud die Daten nach 30 Tagen löscht. Deswegen habe ich eine zweite Kopie der Datenbank auf einem lokalen System mit längerer Speicherzeit.
Dear @HannesKl,
I have fixed it in my latest implementation, you can find it here #1487
I was working with a simulated 9 kWh capacity battery to charge the battery with 4054941 W*s(Joules) or 1,1263725 kWh in 900 seconds. This suggests that in terms of energy the SoC should be increased by (1,1263725 kWh/9kWh)=12.5% and reach 27.5%.
Before, it estimates only 23%, at the end of the simulation
With my implementation, It now correctly estimates 27.5. Note the end result is again rounded off to the closest integer, so instead of 27.57, you see 28.
The rounding off of the energy value, which is in watt-hours, causes the State of Charge (SoC) estimation mistake (Wh). It’s calculated by converting the amount of power to be charged or discharged into watthours (Wh), estimating the SoC based on it, and then adding it to the current SoC.
I fixed that by doing a few of things:
- estimating the energy from the power in Watt milliseconds (Wmsec) rather than Watt-Hours (Wh).
- Instead of using the float data type, use the double data type.
- Adding the Initial energy variable to estimate the battery’s energy based on the initial SoC. Later every run, SoC is then calculated by adding the new energy values to the starting energy variable.
