Hallo Community,
ich bin seit einigen Wochen dabei, mich mit OpenEMS zu beschäftigen und habe einige Nächte an Wochenenden investiert und rumprobiert, und bin auch irgendwie immer einen Schritt weiter gekommen.
Ich habe EDGE und UI auf einen Raspi mit der neuesten Version am Laufen und habe es auch geschafft, das Ganze lokal auf einen PC mit Eclipse zu kompilieren und das exportierte JAR File auf dem Raspi zum Laufen zu bringen. Da gab es 1 Mio Fallstricke, aber die bekomme ich glaube ich nicht mehr zusammen…
Beim Versuch, das ganze mit den Predefined CSV files und der Bedeutung der einzelnen Komponenten zu verstehen, hatte ich doch auch viele Anläufe gebraucht, glaube aber, mittlerweile die Grundidee verstanden zu haben.
Daher hab ich mir überlegt, genau die Grundlagen für das Grundverständnis, die wie ich fand, schon sehr stiefmütterlich und knapp dokumentiert waren, nochmal in Deutsch zusammenzufassen.
Vielleicht hilft es dem einen oder anderen…
openems.pdf (197.8 KB)
Ich fände es auch nett, wenn sich die erfahrenen Leute das auch mal ansehen könnten und mir Feedback geben würden, ob das so alles in allem passt, oder ob ich doch noch grundlegendes nicht verstanden habe.
Das könnte man meinen, denn wenn man eine Batterie (ess) hinzunimmt und einen Controller ESS Balancing, dann funktioniert NICHTS mehr…
Aber dazu später…
Schaut euch erstmal meinen ersten Entwurf an !
Gruß
ThommyTheKid
Hallo ThommyTheKid,
Ich habe mir deinen Entwurf mal angeschaut und habe folgende Anmerkungen:
- Die Interpretation der 3 Basiskomponenten stimmt. Ein “Simulator … Acting” bekommt eine Datasource und fährt diese einfach ab, und ein “Simulator … Reacting” bekommt die Werte von außen, also von anderen Komponenten. Also errechnet zum Beispiel der Simulator Grid Meter Reacting den Netzanschluss aus Erzeugung, Verbrauch und Batterie.
- Die Datasource H0_HOUSEHOLD_SUMMER_WEEKDAY_PV_PRODUCTION2 hat Werte von 2000 bis 4878, die sich immer um 2 erhöhen. Das heißt, wenn du damit eine PV simulierst, macht sie eine “Sägezahnkurve”, was nicht besonders realistisch ist. Aber für Testzwecke ist das vielleicht manchmal ganz gut.
- Jetzt das entscheidende, warum das alles nicht mehr funktioniert, wenn du eine simulierte ESS hinzunimmst: Du hast in deiner Simulation 2 Netzzähler, nämlich einen “Acting”, der also die Datasource bekommt, und einen “Reacting”, der also auf alles reagiert. Stattdessen würde ich empfehlen, statt des Grid Meters Acting einen “NRC Meter Acting” mit der selben Datasource zu aktivieren. Dieser simuliert den “sonstigen” Verbrauch, also alles, was nicht einzeln gemessen wird (Licht, Spülmaschine, …). Dann sollte der Grid Meter Reacting darauf reagieren und der Controller ESS Balancing den Netzanschluss auf 0 ausregeln.
Danke für deine Arbeit und viele Grüße,
Thomas
Hallo Thomas,
vielen Dank für dein Feedback ! Und Tatsache: wenn ich ein NRC Meter Acting statt des Grid Meter Acting nehme, klappt es ohne Speicher exakt genau so und wenn ich dann den Speicher Controller dazunehme, sieht es erstmal auch ganz gut aus !!
Noch eine Sache zum H0_HOUSEHOLD_SUMMER_WEEKDAY_PV_PRODUCTION2. Wieso heisst das CSV File anders ? Da fehlt HOUSEHOLD im Namen, im Build directory heisst es es
H0_SUMMER_WEEKDAY_PV_PRODUCTION2.csv und es wird auch für die Daten der Datasource verwendet, wenn man es ändert.
Ich baue das edge JAR file ja lokal und möchte sowohl den Verbrauch wie auch die PV Erzeugung mal so simulieren, dass ich
- bei Cycle Time 5000 ms die Werte der Anzeige nachvollziehen kann und mit den Werten
meines geänderten CSV files abgleichen kann.
- die Situation simulieren, wo im Verlauf mal PV höher ist als Verbrauch und mal umgekehrt.
Daher habe ich die beiden CSV Files mal nebeneinander gelegt und so geändert, dass
einmal ein paar KW Überschuss aus PV existieren (die dann in den Akku sollten später) und
einmal ein paar KW zu wenig aus PV kommen, für den Verbrauch, sodass der Akku den Rest
zusteuern sollte.
Nun zum Thema Ausregeln: Ich hab bei einen ersten Tests, die nicht total unplausibel waren wie meine Tests zuvor ohne NRC Meter Acting aber auch einige Situationen festgestellt, die ich komisch finde bzw. nicht verstehe:
- Hier ist die PV Produktion minimal höher als der Verbrauch. Trotzdem wird, statt 0,2 KW in den Akku zu schieben der Akku mit 1,1KW entladen und 1,3KW eingespeist !!
- Hier ist der Verbrauch 5,6 KW und die Erzeugung 3,5KW. Es sollten also 2,1 KW aus dem Akku dazu gegeben werden, es werden aber 3,4 KW entladen und dann 1,4 KW eingespeist.
- Wir haben Überschuss von 1,1KW. Jedoch wird nicht nur das in den Akku geladen sondern 1,5KW und hierfür wird dann 0,5KW vom Netz gezogen.
- Zu guter Letzt noch ein Beispiel mit PV Überschuss, bei dem zwar der Akku mit 1 KW beladen wird, aber noch 1,7 KW eingespeist werden, obwohl doch stattdessen 2,7 KW in den Akku gehen könnten
Woran liegt das ? Kann man irgendwelche Parameter einstellen, damit die Ausregelung besser klappt ?
Zu Guter Letzt ist mir noch eine Sache bei der Historie aufgefallen. Ich hab in den letzten Wochen nach langem Hängen und Würgen endlich geschafft, dass die Daten in die influxdb geschrieben und auch wieder rausgelesen und anhezeigt werden. Nun ist mir bei meiner laufenden Simulation was aufgefallen, nämlich die Grafik zu PC Erzeugung:
Man sieht im Grunde sehr schön, dass sich das Muster periodisch wiederholt, weil ja die Cycle Time 1sec ist und nur 1440 Werte im CSV file stehen. Dann beginnt er einfach wieder von vorne.
Soweit so gut, aber die Wertespanne bewegt sich in der Anzeigt nur von 3,6 KW bis 4,01 KW und das ist definitiv nicht das, was bei mir im CSV File steht und auch im Live View angezeigt wird. Die Werte im CSV file gehen von 1080W bis 6880 W.
Kann jemand das erklären ?
viele Grüße
ThommyTheKid
Hallo,
ich glaube ich kann mir die Fragen wohl mittlerweile selbst beantworten.
Es liegt wohl am Zeitmaßstab. Im CSV file hatte ich angenommen es hat
1440 Zeilen, und bildet damit 24*60 min des Tages ab. Allerdings war ja meine Cycletime auf 1000ms eingestellt, und das bedeutet, dass er alle 1sec den nächsten Wert aus dem CSV File genommen hat. Die Auflösung der Punkte in der Grafik war allerdings 5 min, also einen Punkt in der Grafik alle 5 min. Daher hat die Grafik das viel schnellere Auf und Ab der Werte aus den CSV files gar nicht mitbekommen. Ich denke dass das auch der Grund für die unzureichende Ausregelung war.
Kann jemand meine Theorie bestätigen ?
Gruß
ThommyTheKid
Hallo ThommyTheKid,
Was die Historie angeht stimmt, was du sagst. Da werden 5-Minuten-Mittelwerte verwendet, deshalb sieht man da immer nur ein “verschwommenes” Bild.
Was die Ausregelung angeht, ist der Grund aber ein anderer, denn das hat mit den historischen Daten nichts zu tun. Ich könnte mir vorstellen, dass das mit dem PID-Filter zusammenhängt. Versuch mal, in der Konfiguration der Komponente Ess.Power (mit Komponenten-ID _power) diesen zu deaktivieren (Enable PID-Filter auf false stellen).
Viele Grüße,
Thomas
