76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[grappa24]

vlt. kurz etwas zum Thema Akku-Verhalten:

Mein BYD HVS 7.7 kWh an einem SYMO GEN24 reduzierte letzte Woche (ohne SF) wiederholt ab 80% die Ladung auf unter 10 W, war aber dann doch recht schnell voll; BYD hat da wohl bereits eigene Schutzmechanismen eingebaut (neueste fw).

[DS_Starter]

Ja, jeder Hersteller wird seine Logiken eingebaut haben. Vermutlich ist das von mir dargestellte Verhalten nicht durch die Pylontech Batterien an sich, sondern durch die Victron Ladetechnik in Verbindung mit den Pylonen bedingt. Aber ich weiß es nicht und vergleiche mit anderen Usern Victron/Pylontech würde mehr Erkenntnis bringen.

[300P]

Heute war ein ausgezeichneter PV Tag. Da bietet sich eine Ergebnisbesprechung an. Eingestellt ist smartPower.
Im Prinzip ist alles erwartungsgemäß verlaufen. Ca. 8:00 klinkt sich die Regelung ein, davor war kein Überschuß vorhanden.
In der Zeit von 08:00 bis ca. 13:30 zeigen sich keine spektakulären Vorgänge. Das Leistungslimit wird leicht heruntergeregelt so wie das Ratio ansteigt.

Ab ca. 13:30 (senkrechte rote Linie) ist eine Besonderheit meiner Batterie zu erkennen. Für über eine Stunde verbleibt der SoC trotz sich weiter erhöhenden BatIn bei ca. 90% stehen. Ich kenne dieses Verhalten und ist nichts unübliches bei meinem Pylontech Batterien. (Kennt ihr das auch bei euren Batterien?)
Dadurch verschlechtert sich das Ratio steil und ebenso steil wird das Limit (und BatIn) nach oben geregelt, sogar bis zum Status "Ziel unerreichbar". Nach der Phase gleich bleibenden SoC's geht dieser auch wieder schnell nach oben und erreichte 99% (das rote Quadrat).

Heute waren 100% Zielerreichung avisiert und hatten auch locker erreicht werden können wenn es nicht diesen Verharrungsbereich gegeben hätte. So waren es "nur" 99%, aber dennoch eine Punktlandung.

Da drängt sich die Frage auf, ob ein Parameter Sinn macht, mit dem man den gewünschten Zeitpunkt einer Zielerreichung festlegen kann. In meinem Fall würde ich z.B. 2 h vor dem Sonnenuntergang die 100% als Meilenstein vorgeben um die verbleibende Zeit als Puffer für die Phase mit gleichbleibenden SoC zu haben.

LG,
Heiko

Zur Info - Nachfolgendes gilt nur für Victron:

Die verzögerte Ladung kurz vor 100 % bei Victron-Geräten ist normal und liegt am Übergang in die Absorptions-Ladephase.
Hierbei wird die Batteriespannung auf einen bestimmten Wert angehoben, um die Batterie zu sättigen, bevor die Ladung auf eine geringere Erhaltungsspannung (Float-Phase) reduziert wird, um Schäden wie Überladung oder Gasung zu vermeiden.

[Parallix]

...
Was ich damit sagen wollte, wenn ich 100% als Zielerreichung 2 h vor Ende der Zeit mit PV Überschuß definieren würde, käme mein Akku wegen der beschriebenen Eigenschaft (Verharrung auf SoC) auch dann nur auf ca. 90%, hat dann jedoch noch eine Pufferzeit um 100% zu erreichen.

Im Grund gibt es hierfür ja zwei Wege, die natürlich auch beide gleichzeitig gegangen werden können: a) Laden mit einer etwas höheren als prognostizierten optimalen Ladeleistung b) Anpassung der Randbedingungen für die Prognose durch Verschieben des Zielzeitpunkts nach vorne (Verkürzung der angesetzten Ladedauer).

Sowas ist u.U. aber nicht leicht zu machen, wenn man z.B. an Ost/West-Anlagen denkt die zweimal am Tag ein Maximum haben. Vermutlich muß ich generell mit Uhrzeiten oder Relativzeiten zum Sonnenuntergang arbeiten wenn ich eine solche Logik implementieren wollte.

Meine Anlage ist (fast) eine Ost/Süd/West-Anlage. Da für die Leistungsprognose ja die Strahlungswerte für jede Orientierung einzeln herangezogen werden, sollten derartige Anlagen eigentlich kein Problem darstellen. Wo siehst Du das Problem?

Edit: Wolltest du nicht das Wiki ohnehin noch weiter ergänzen?

Ja, ich hatte auch schon mal begonnen, einige schöne Grafiken zu erstellen, bin dann aber nicht mehr wirklich weiter gekommen. Wahrscheinlich alles ein Problem der Zeitumstellung 

Edit: Heute habe ich tagsüber mal nicht auf meine Daten geblickt und sehe jetzt trotz einer safetyMargin == 0, dass der Speicher bereits um 12:00 MEZ, also viel zu früh, vollgeworden ist. Die Ursache war ein Stau, sodass ich mein EV nicht wie sonst um 14:00 MEZ ein wenig nachladen konnte, SF davon logischerweise aber a priori nichts wusste.  Heute hätte ich mir für meine Speicher die weiter oben beschriebene Ladebremse bei 99% gewünscht.

[DS_Starter]

Meine Anlage ist (fast) eine Ost/Süd/West-Anlage. Da für die Leistungsprognose ja die Strahlungswerte für jede Orientierung einzeln herangezogen werden, sollten derartige Anlagen eigentlich kein Problem darstellen. Wo siehst Du das Problem?

Die Iteration der Ladeleistung vollzieht sich von den Stunden mit den geringsten Überschüssen aufsteigend hin zu den Stunden des Tages mit den meisten Überschüssen. Wenn ich den Überschuß als Maßgabe für einen Meilenstein heranziehen würde, gibt es bei den O/W-Anlagen zweimal ein Maximum. Deswegen ist eine absolute oder relative Uhrzeit zum Sunset besser geeignet und eindeutig.

[DS_Starter]

Die aktuelle V 1.60.3 ist morgen früh im Update verfügbar.

[DS_Starter]

Ein allgemeine Info. Wen es interessiert ... openMeteo hat eine neue saisonale Vorhersage API online gestellt:

https://open-meteo.com/en/docs/seasonal-forecast-api#location_and_time

Diese API liefert saisonale ECMWF SEAS5- und sub-saisonale ECMWF EC46-Prognosen mit einer Auflösung von 36 km und 51 Ensemble-Mitgliedern. Die Daten sind nicht bias-korrigiert und spiegeln möglicherweise nicht genau die lokalen Bedingungen wider. Sie sollten als Gebietsprognosen interpretiert werden, die einen Hinweis darauf geben, ob die kommenden Monate voraussichtlich wärmer, kälter, feuchter oder trockener als der Durchschnitt ausfallen werden.

Für uns ist es vermutlich kein brauchbares Hilfsmittel, aber als Langzeitvorhersage für z.B. Gartenbau / Feldwirtschaft usw. ist es vllt. ganz hilfreich um sich auf bestimmte Dinge vorbereiten zu können.

[Parallix]

Meine Anlage ist (fast) eine Ost/Süd/West-Anlage. Da für die Leistungsprognose ja die Strahlungswerte für jede Orientierung einzeln herangezogen werden, sollten derartige Anlagen eigentlich kein Problem darstellen. Wo siehst Du das Problem?

Die Iteration der Ladeleistung vollzieht sich von den Stunden mit den geringsten Überschüssen aufsteigend hin zu den Stunden des Tages mit den meisten Überschüssen. Wenn ich den Überschuß als Maßgabe für einen Meilenstein heranziehen würde, gibt es bei den O/W-Anlagen zweimal ein Maximum.

Verstehe nicht, was Du damit sagen willst. Du hattest doch geschrieben, dass Ost/West-Anlagen ein Problem verursachen. Das sah für mich so aus, als würdest Du nur hier ein Problem mit dem aktuellen Algorithmus identifizieren. Ein Problem kann aber auch auch durch viele andere Ursachen entstehen. So können zeitlich auseinander liegende Maxima auch bei reinen Südanlagen auftauchen, wenn z.B. dann, wenn die Sonneneinstrahlung um die Mittagszeit herum durch eine vorbeiziehende Wolkenformation für eine Zeit vermindert wird.

Deswegen ist eine absolute oder relative Uhrzeit zum Sunset besser geeignet und eindeutig.

Besser als was?

[DS_Starter]

Habe nur darüber sinniert ... eine Uhrzeit für die Angabe eines Meilensteins ist besser/einfacher als eine Verwendung eines Überschußmaximums bzw. Überschußunterschreitung wenn es ein Maximum/Schwellenwertunterschreitung theoretisch am Vormittag oder Nachmittag bei der Anlage geben kann bei O/W-Anlagen. Deswegen nicht so fest determiniert als bei Anlagen mit nur einer Ausrichtung.

Und ja, auch andere Situationen verändern die Verhältnisse. Auch deswegen -> Uhrzeit.

Ist jetzt kein besonderes Thema. 

[Parallix]

Habe nur darüber sinniert ...

Du meinst wahrscheinlich, das tagsüber Zeiten für SoC-Targets gesetzt werden können, wie z.B.

Code Auswählen Erweitern

12:00 MEZ: SoC 60%

Das ist sicher besser, als diese Zwischenzielerreichung vom Zweitpunkt eines erwarteten Ertragsmaximums abhängig zu machen, das ja auch nicht gesichert eintreten muss. Bin also ganz bei Dir!

[Hadl]

Und wenn ich darüber nachdenke ist auch dies nicht ganz richtig und müßte so aussehen:

Ich hab auch nochmal drübergeschaut, ich glaube wir brauchen die Efficiency garnicht in der Funktion ___batFindMinPhWh, da wir $runwhneed schon um die Efficiency erhöht haben, brauchen wir die Lade-Energie nicht nochmal um die Efficiency erniedrigen, sonst haben wir's doppelt.
Somit kann "$cap     *= $befficiency;" meiner Meinung nach raus.

Kennt ihr das auch bei euren Batterien?

Ja, das kenne ich auch. Das BMS schätzt ja den SOC nur. Vor allem im Mittelfeld zwischen 20% und 80% SOC hat es nur die (ungenaue) Strommessung, da die Batteriespannung sich fast nicht verändert. Unter 20% erwartet er dann einen Spannungsabfall, über 80% dann einen Spannungsanstieg. Zum Ende hin dann sogar sehr deutlich.
Wenn er bei 90% verharrt wartet er sicherlich nur, das nun der Spannungsanstieg kommt, und läd solange weiter. Je länger er verharrt, desto mehr hatte er sich bei der SOC Berechnung verschätzt und korrigiert das damit.
Mein BYD macht das auch gelegentlich, aber deutlich häufiger verschätzt er sich in die andere Richtung und geht dann in einer Rampe von ~90% auf 100% ohne noch Energie aufzunehmen. Dann hat er bei 90% schon eine hohe Zellspannung gesehen und "simuliert" dann ein schnelles vollwerden, obwohl er nichtsmehr läd.

Was ich damit sagen wollte, wenn ich 100% als Zielerreichung 2 h vor Ende der Zeit mit PV Überschuß definieren würde, käme mein Akku wegen der beschriebenen Eigenschaft (Verharrung auf SoC) auch dann nur auf ca. 90%, hat dann jedoch noch eine Pufferzeit um 100% zu erreichen.

Ich glaube es wäre besser wenn wir diesen Wert nicht als Zeitkonstante, sondern als kWh oder Prozent der Akku Kapazität angeben würden. Dann würde er nen schönen Abend an nem bewölkten Tag trotzdem nutzen, aber noch mehr Reserve lassen. Wir könnten den Wert dann z.B. auf runwhneed addieren.

Ost/West-Anlagen denkt die zweimal am Tag ein Maximum haben

Ich habe auch Ost/West, da gibts aber auch nur ein Maximum in Summe wenn die Sonne von Süden kommt. Wenn im Süden evtl. ein Baum steht könnte es aber schon zwei Maximas geben.
Dafür sollte doch die aktuelle Suche der Ladeleistung auch ideal sein. Ich denke es reicht wenn wir einfach auf den Bedarf etwas addieren.

eine Uhrzeit für die Angabe eines Meilensteins ist besser/einfacher als eine Verwendung eines Überschußmaximums

Ja, das wäre eine Idee. Aktuell haben wir ja nur den Meilenstein das wir zum letzten Zeitpunkt an dem wir am Tag Überschuss erwarten das Ladeziel erreicht haben.
Mit dem SOC Barrier haben wir dann auch noch ein Ziel für ne Reserve zum Mittagessen kochen oder Notstromfähigkeit so früh wie möglich am Tag. Weitere Ziele fallen mir gerade nicht ein, könnten aber sicherlich bei einigen Anwendungen auftreten.
Also z.B. 13:00 kleiner Akku und Trocknerlauf erwartet dadurch SOC > 70% nötig.

[Parallix]

eine Uhrzeit für die Angabe eines Meilensteins ist besser/einfacher als eine Verwendung eines Überschußmaximums

Ja, das wäre eine Idee. Aktuell haben wir ja nur den Meilenstein das wir zum letzten Zeitpunkt an dem wir am Tag Überschuss erwarten das Ladeziel erreicht haben.
Mit dem SOC Barrier haben wir dann auch noch ein Ziel für ne Reserve zum Mittagessen kochen oder Notstromfähigkeit so früh wie möglich am Tag. Weitere Ziele fallen mir gerade nicht ein, könnten aber sicherlich bei einigen Anwendungen auftreten.
Also z.B. 13:00 kleiner Akku und Trocknerlauf erwartet dadurch SOC > 70% nötig.

Wobei derartige (fixe) Planungen natürlich auch über ein Schedule in SF berücksichtigt werden sollten.

Edit: Das Verharren auf einem SoC trotz vorhandener Ladeleistung ist in der Tat durch SoC-Korrekturen durch das BMS begründet.

[DS_Starter]

Somit kann "$cap     *= $befficiency;" meiner Meinung nach raus.

Nicht wirklich. Der Faktur ist für die Laufvariable charged innerhalb der Funktion, also dem erreichten prognostizierten Füllgrad, wichtig.
Dieser Wert wird mit dem, ebenfalls Effizienz gewichteten, Bedarfswert verglichen.

Ich glaube es wäre besser wenn wir diesen Wert nicht als Zeitkonstante, sondern als kWh oder Prozent der Akku Kapazität angeben würden. Dann würde er nen schönen Abend an nem bewölkten Tag trotzdem nutzen, aber noch mehr Reserve lassen. Wir könnten den Wert dann z.B. auf runwhneed addieren.

Kannst du das erläutern wie es gemeint ist?
Die Intention war z.B.  16:goal -> würde bedeuten um 16:00 soll das angegebene Ziel (Wh im Akku) erreicht sein. Bisher ist immer die letzte Stunde mit Überschuß das Zeitziel.


Danke euch für die Erläuterungen bzgl. der Verharrungszeit.

LG,
Heiko

[Hadl]

Dieser Wert wird mit dem, ebenfalls Effizienz gewichteten, Bedarfswert verglichen.

Ja, aber wir gewichten ja absichtlich um die Akku Verluste mit abdecken zu können. Dafür reicht einmalige Gewichtung.

Wenn wir 5kWh nominellen Ladungsbedarf haben, dann müssen wir ja 5kWh / 87% = 5,75kWh (runwhneed) laden um den Akku inkl. Verluste voll zu kriegen
Wir addieren dann die Ladungen bis wir runwhneed erreicht haben. Deshalb müssen wir die Ladungen die wir addieren nicht vorher nochmal mit 87% multiplizieren.

Die Intention war z.B.  16:goal -> würde bedeuten um 16:00 soll das angegebene Ziel (Wh im Akku) erreicht sein. Bisher ist immer die letzte Stunde mit Überschuß das Zeitziel.

Das war auch nur eine Überlegung ohne das ich direkt einen Anwendungsfall dafür habe.

Idee war das wir den Ladebedarf nach oben erhöhen. Nehmen wir an um 1kWh, weil wir erwarten das wir zum Mittagessen kochen den Akku sogar um 1kWh leeren. Also statt des angenommen nominellen 5kWh Ladebedarfs bis Sonnenuntergang wir 6kWh über den Tag laden müssen. Das 1kWh offset könnte man dann früh schon mit einplanen damit er läd als ob er 6kWh brauchen würde. Wenn nicht abgerufen ist das Ladeziel eher erreicht.
Alternativ könnte man auch statt 1kWh als Absolutwert, 15% der Akku-Kapazität angeben.
Das ganze würde auch relativ sanft als "Sicherheitsreserve für jeden Tag" funktionieren. Diese würde sich im Unterschied zur prozentualen "margin" nicht gegen Abend reduzieren.

Viele Grüße

Hadl