Neuimplementierung der prognosebedingten Ladeberechnung

wiggal / GEN24_Ladesteuerung

Ladesteuerung für Fronius Symo GEN24 Plus

GNU General Public License v3.0

26 stars 4 forks source link

Neuimplementierung der prognosebedingten Ladeberechnung #22

Closed wiggal closed 11 months ago

wiggal commented 1 year ago

Änderung in SymoGen24Controller2.py (noch im frühen Test): siehe auch: https://github.com/wiggal/GEN24_Ladesteuerung/discussions/23#discussioncomment-7130166

Neuimplementierung der prognosebedingten Ladeberechnung unter Berücksichtignung der Variablen "BatSparFaktor". Folgende Werte bewirken folgendes: 0: Die Berechnung erfolgt ohne zusätzliche Verschiebung in Richtung Mittag nur aufgrund der Prognose 0.01: Die Berechnung des Ladewertes mit folgender Formel. AktuelleBatteriekapazietät / Stunden_bis_BattVollUm 0.1: Die Batterieladung wird möglichst weit nach Mittag geschoben bis 9: Die Batterieladung wird immer weiter in den Vormittag geschoben.
Änderung in config.ini Da die Variable "BatSparFaktor" sehr großen Eenflus bekommt, wird die Variablen "BatWaitFaktor" und "BatWaitFaktor_Max" bei der nächsten Version wegfallen.

wiggal commented 12 months ago

OK so funktionierts nicht, ich werde die Anwendung des "BatSparFaktor" nochmal von Grund auf ändern. siehe auch: https://github.com/wiggal/GEN24_Ladesteuerung/discussions/23#discussioncomment-7130166

Neuimplementierung der prognosebedingten Ladeberechnung unter Berücksichtigung der Variablen "BatSparFaktor", um die Ladeverteilung auf den Tag besser steuern zu können.

Folgende Werte bewirken folgendes: bei 1: Keine Verschiebung, Verteilung rein nach Prognoseüberschuss von 1 bis 0.1: Die Batterieladung wird prognoseabhängig immer weiter zum Zeitunkt in "BattVollUm" verschoben. größer 1: Die Batterieladung wird prognoseabhängig immer gleichmäßiger über den Tag verteilt.

Änderung in config.ini Da die Variable "BatSparFaktor" größeren Einfluss bekommt, werden die Variablen "BatWaitFaktor" und "BatWaitFaktor_Max" nicht mehr benötigt und wurden entfernt

wiggal commented 11 months ago

Nun noch ein paar Tage testen und dann könnte es passen (evtl. kann es jemand mit testen und/oder kommentieren). Hier noch die Beispiele zur Ladeverteilung aus der Diskussion: grafik grafik

jaydee73 commented 11 months ago

Das sieht solide aus. Wobei für mich persönlich der Unterschied zwischen Faktor 3, 5 und 9 quasi nicht relevant wäre. Da ist ja die Startzeit im Wesentlichen der einzige Unterschied.

Für mich persönlich würden drei zur Verfügung stehende Faktoren reichen (z.B. 0.3 und 1 und 3).

wiggal commented 11 months ago

Das mit den Faktoren waren nur Beispiele, du kannst alle Zahlen von 0.1 bis unendlich nehmen, auch Kommazahlen (z.B. 1.5 oder 2.3). Die Kurven und der Startzeitpunkt hängen natülich auch von der Prognose ab. Der Unterschied wird bei Faktoren über 9 aber kaum noch messbar sein. Zahlen kleine 0.1 werden auf 0.1 gesetzt. In der mitgelieferten Tabelle "Ladewerte_Vergleichtabelle.ods" kann man die Auswirkugen testen.

wiggal commented 11 months ago

Hier zum Beispiel mit der Prognose von morgen und mit Faktor 2 statt 9: grafik

wiggal commented 11 months ago

Hi, habe heute noch eine Programmschwäche gefunden. Da durch die Begrenzung durch "WRSchreibGrenze_nachUnten" der Ladewert nachmittags normalerweise nicht mehr nach unten geht, wurde in meinem Fall mit 1600W weiter geladen und die Batterie war dadurch bereits um 14:15 anstelle um 16:00 voll. Diesen Effekt müsste ich noch irgendwie berücksichtigen, und dann müssten die Kurven ungefähr so aussehen: grafik

wiggal commented 11 months ago

Nun habe ich die Schreibgrenzen WRSchreibGrenze_nachOben und WRSchreibGrenze_nachUnten eingearbeitet.

Sieht jetzt ungefähr so aus: grafik

Und jetzt nochmal einige Tage testen. Schau ma mal ;-)