76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Begonnen von DS_Starter, 11 Februar 2024, 14:11:00

Vorheriges Thema - Nächstes Thema

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).
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

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.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

300P

Zitat von: DS_Starter am 06 November 2025, 19:08:22Heute 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.

Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast|DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP|ESP32-Digitizer-AI_on_the_Edge|ESP32CAM usw.

Parallix

#4458
Zitat von: DS_Starter am 07 November 2025, 08:00:44...
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).

Zitat von: DS_Starter am 07 November 2025, 08:00:44Sowas 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?

Zitat von: DS_Starter am 07 November 2025, 08:00:44Edit: 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. :o 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.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

DS_Starter

ZitatMeine 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.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Die aktuelle V 1.60.3 ist morgen früh im Update verfügbar.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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

ZitatDiese 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.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter