76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Hadl]

Hat die Zelle mit der geringsten Spannung 3V oder sind's im Mittel 3V und Du hast ordentliche Spannungsdifferenzen zwischen den Zellen? Nutzt Du ein Logging- bzw. Anzeigetool für die Zellspannungen, z.B. das hier aus der FHEM-Community? Wenn ja, dann kannst Du ja mal einen Aufnahme der einzelnen Zellenspannungen bei SoC == 5% machen.

Die niedrigste Zelle hat die Spannung die ich genannt habe, in dem Fall habe ich meistens ne ganz schöne Spreizung zwischen min/max

Hier min und max Spannung nachdem der Akku leer wurde, und sogar eine erzwungene Nachladung.
Du darfst diesen Dateianhang nicht ansehen.
Hier die min Werte über alle Zellen, Zeitraum ist aber schon ein paar Wochen, allerdings wurde der Akku nur in den letzten drei Tagen leer.
Du darfst diesen Dateianhang nicht ansehen.

Dann würde ich aber lowSoC auf einen Wert 10%-20% setzen. Diese Grenze wird vom Modul aus auch nicht untersteuert.

Dann müsste ich es jedesmal wieder zurückstellen wenn die Vorausschau erwartet das ich die ganze Akku Kapazität brauche. So hab ich das letzen Winter direkt im Wechselrichter per Hand gemacht.
Wenn mehrere Tage schlechtes Wetter vorausgesagt wurden hab ich die untere Grenze auf 20% gestellt, wodurch der Akku meistens zwischen 20% und 80% blieb.
Sobald wieder Sonne vorausgesagt wurde hab ich die Grenze wieder runtergestellt.

Wäre super, wenn ich das automatisiert hinbekommen würde.
Kleiner Nebeneffekt wäre das ich die BMS Grenze (mit nachladen) bei 5% lassen kann, das Entladen aber schon deutlich höher aufhöre.

Ich glaube aber ich kann weniger Reserven lassen, da mein Akku im Vergleich zur PV Leistung deutlich kleiner ist als deiner.

Ich würde z.B. gerne den min SOC erhöhen wenn ich nicht erwarte das der Akku 80% des Target SOC bis Ende des nächsten Tages erreicht.

Viele Grüße

Hadl

[Wolle02]

Dann würde ich aber lowSoC auf einen Wert 10%-20% setzen. Diese Grenze wird vom Modul aus auch nicht untersteuert.

Dann müsste ich es jedesmal wieder zurückstellen wenn die Vorausschau erwartet das ich die ganze Akku Kapazität brauche. So hab ich das letzen Winter direkt im Wechselrichter per Hand gemacht.
Wenn mehrere Tage schlechtes Wetter vorausgesagt wurden hab ich die untere Grenze auf 20% gestellt, wodurch der Akku meistens zwischen 20% und 80% blieb.
Sobald wieder Sonne vorausgesagt wurde hab ich die Grenze wieder runtergestellt.

Wäre super, wenn ich das automatisiert hinbekommen würde.

Wahrscheinlich verstehe ich dich falsch, aber ich habe diesen Automatismus mit SF Bordmitteln realisiert. Einfach den OTP nehmen und per MSwitch, notify, doif den Reservewert der BYD Batterie per ModbusAttr anpassen. Dann entlädt er nicht mehr als den OTP-Wert und das ganze geht automatisch. In der Batteriesteuerung in meinem Fronius habe ich den unteren SoC Wert auf 7% belassen. Das stört überhaupt nicht.

[DS_Starter]

Wäre super, wenn ich das automatisiert hinbekommen würde.

Ja, natürlich. Das ist ja unser Ziel, sonst braucht man das alles nicht zu machen.
Ich wollte nur damit sagen, ich persönlich würde eine untere Grenze einstellen mit der ich mich auch dann noch wohlfühle wenn sie mal angefahren wird. Bei deiner PV Leistung wird die Bat nicht lange dort bleiben.

Meine Pylons können lt. Datenblatt auf 5% entladen werden. Diese Grenze ist auch in der Victron-Steuerung eingestellt.
Im Modul ist lowSoC=10 eingestellt. Ich bleibe also immer 5% drüber. Wenn die PV nicht mehr ausreicht, erhöht sich der Opt. SoC wie jetzt immer 5% am Tag. Er wird entsprechend in die Steuerung repliziert (das meint vermutlich auch Wolle02). In der absoluten Dunkelzeit geht die Vorgabe  eben auch mal bis 80-90%. Kommt dann mehr Energie, wird üblicherweise Platz geschaffen bis upSoC (50%) und pendelt dann bis max und zurück. Ist nochmehr Energie verfügbar, wird auch mehr als upSoC freigemacht.

[DS_Starter]

Contrib ist upgedated.

[Hadl]

Wahrscheinlich verstehe ich dich falsch, aber ich habe diesen Automatismus mit SF Bordmitteln realisiert. Einfach den OTP nehmen und per MSwitch, notify, doif den Reservewert der BYD Batterie per ModbusAttr anpassen. Dann entlädt er nicht mehr als den OTP-Wert und das ganze geht automatisch. In der Batteriesteuerung in meinem Fronius habe ich den unteren SoC Wert auf 7% belassen. Das stört überhaupt nicht.

Danke, ja so hab ich mir das auch vorgestellt. Macht er dabei eine Notladung wenn der Reservewert unterschritten wird?
Alternativ habe ich mir überlegt den BatteryDischarge auf 0W zu stellen wenn der SOC unterschritten wird. Dann kann der Akku sich weiter selbst entladen ohne das ne Notladung gemacht wird.

Bei deiner PV Leistung wird die Bat nicht lange dort bleiben.

Ja, das könnte man denken. Aber vorgestern hab ich z.B. um 15:00 Uhr den Akku leer gemacht (hoher verbrauch, geringe PV Leistung). Dann blieb er für 17 Stunden auf ~5%

Generell brauche ich meine Akku Kapazität und will nicht etwas am unteren Ende verschenken. Die 5%-100% nutze ich um diese Jahreszeit auch immer mal wieder innerhalb eines Tages aus.

Aber wenn wir mehrere schlechte Tage am Stück haben, möchte ich gerne statt immer zwischen 5% und 40% zu sein, lieber zwischen 30% und 65% bleiben.
Das schont den Akku und gibt mir Notstrom Sicherheit. Das aber ohne Nutzen zu verlieren.

[Parallix]

...

Möglicherweise wird immer noch nicht richtig unterschieden zwischen

• Notladung, die seitens des BMS angefordert wird
• Erhaltungsladung, die seitens des (Hybrid-)Wechselrichters erfolgt

Da Deinerseits immer die Rede von einem SoC von 5% ist, vermute ich, dass Du letztere meinst. Die seitens des BMS ausgelöste erfolgt - nach meinen bisherigen Erfahrungen - bei einem HVS-System von BYD nämlich unterhalb eines SoC von 4%.

Edit: Die Erhaltungsladung, die seitens des Wechselrichters erfolgt, kannst o,B.d.A. unter die Schwelle gesetzt werden, bei der das BMS eine Notladung anfordert. Limitieren kannst und solltest Du bei geringen SoC-Werten den Ladestrom, aber keinesfalls auf einen Wert von 0 A. Ein sinnvoller Wert wäre z.B. pinreduced (sofern > 0 A) zu setzen, wenn der SoC unter 5% sinkt. Und das geht natürlich mit FHEM-Boardmitteln.

PS: Die in Deinen weiter oben stehenden Bildern ablesbare Spannungsdifferenz von 60 mV bei einer minimalen Zellenspannung von 3 V ist nicht untypisch und sollte unproblematisch sein.

[grappa24]

Info (1.60.4 - Contrib vom 11.11.):

Code Auswählen Erweitern

2025.11.11 08:44:29 1: PERL WARNING: Use of uninitialized value $max_cap in sprintf at ./FHEM/76_SolarForecast.pm line 12729.

[Wolle02]

Danke, ja so hab ich mir das auch vorgestellt. Macht er dabei eine Notladung wenn der Reservewert unterschritten wird?
Alternativ habe ich mir überlegt den BatteryDischarge auf 0W zu stellen wenn der SOC unterschritten wird. Dann kann der Akku sich weiter selbst entladen ohne das ne Notladung gemacht wird.

Wenn der eingestellte Reserve-SOC erreicht ist beendet er die Entladung. Allerdings wird die Batterie durch Eigenverbrauch geringfügig weiter entladen. Sobald der SOC ein Delta von 2% zum eingestellten Reserve-SOC aufweist erfolgt eine Nachladung. Ich denke mal auch, dass hier der Begriff Erhaltungsladung richtiger ist als Notladung.
Deine Alternative könnte man auch mal ausprobieren. Ich vermute mal, dass hierbei dann keine Erhaltungsladung durchgeführt wird und der SOC sich durch den Eigenverbrauch weiter verringert.

Ich persönlich präferiere aber trotzdem den Weg über den Reserve-SOC, da mir das auch die Ersatzstromsicherheit gibt, falls doch mal der Strom ausfällt.

[Parallix]

Ausrichtungsbezoge Prognose

Bei den durch die aktuelle Jahreszeit bedingten niedrigen Sonnenständen führt ein nachbarschaftlicher Baum früh-morgendlich zu einem signifikanten Schattenwurf auf einen meiner sich in der Ausrichtung unterscheidenden Modulsstränge und in Konsequenz zu einer fehlerhaften Prognose. Trotz des regelmäßigen Auftretens erfolgt aber keine adäquate Anpassung der (KI-losen) Prognose. Liegt dies möglicherweise daran, dass die Korrekturfaktoren nicht strang- bzw. ausrichtungsbezogen bestimmt werden? Wenn ja, so möchte ich im Sinne einer Weiterentwicklung von SF vorschlagen, dies Korrekturfaktoren künftig strang- bzw. ausrichtungsbezogen zu ermitteln, um so die Prognosequalität zu verbessern.
 

[DS_Starter]

Info (1.60.4 - Contrib vom 11.11.):
Code Auswählen
2025.11.11 08:44:29 1: PERL WARNING: Use of uninitialized value $max_cap in sprintf at ./FHEM/76_SolarForecast.pm line 12729.

Danke grappa24. Habe es gefixt und im Contrib upgedated.

@Parallix,

Liegt dies möglicherweise daran, dass die Korrekturfaktoren nicht strang- bzw. ausrichtungsbezogen bestimmt werden? Wenn ja, so möchte ich im Sinne einer Weiterentwicklung von SF vorschlagen, dies Korrekturfaktoren künftig strang- bzw. ausrichtungsbezogen zu ermitteln, um so die Prognosequalität zu verbessern.

Ja, es wird der Gesamtbetrag aller Stränge zusammen betrachtet. Eine diesbezügliche getrennte Datenhaltung einer unbestimmten Anzahl von Strängen führt einem unverhältnismäßigen Aufwand verbunden mit einer Komplexität die jede Pflegbarkeit torpediert. So etwas kann ich nicht einbauen.
Vorstellbar wäre ein Master/Slave-Konstrukt. In diesem Konstrukt würde man für jeden einzelnen String ein SF-Device erstellen mit allen nötigen Beziehungen, d.h. Strings, dazugehörige Inverter etc. Dann würde man ein Master-SF Device definieren, welches die Einzelinformationen der daran angeschlossenen Slaves zusammenführt. In diesem Device würde man solche Dinge wie Batteriesteuerung, Consumersteuerung realisieren. In jedem der Slaves kann man die Balkengrafiken und Flußgrafiken der Stränge visualisieren, im Master nur eine Balkengrafik der zusammengeführten Werte.

Bis dahin ist es aber noch ein weiter Weg.
Wenn ich die Batteriethematik endlich einmal zur Seite legen kann, will ich die schon lange angekündigte Implementierung einer "echten" KI bzw. einem neuronalen Netz für die Verbrauchprognose und ggf. PV-Prognose angehen. Dazu brauche ich eine längere Phase in der ich außer kleineren Patches nichts mehr am Modul ändere. Das würde ich gerne über das Winterhalbjahr vorantreiben.

 

[Parallix]

...
@Parallix,

Liegt dies möglicherweise daran, dass die Korrekturfaktoren nicht strang- bzw. ausrichtungsbezogen bestimmt werden? Wenn ja, so möchte ich im Sinne einer Weiterentwicklung von SF vorschlagen, dies Korrekturfaktoren künftig strang- bzw. ausrichtungsbezogen zu ermitteln, um so die Prognosequalität zu verbessern.

Ja, es wird der Gesamtbetrag aller Stränge zusammen betrachtet.
...

Danke für die schnelle Rückmeldung. Möglicherweise könnte man den Wartungsaufwand in weiter Zukunft (!) erheblich reduzieren, wenn die solare Prognose aus SF herausgezogen und in ein eigenes Modul verbracht werden würde. Hast Du mal darüber nachgedacht oder würdest Du diesen Weg von vornherein ausschließen?

[DS_Starter]

Schließe ich aus. Es ist ein integratives Modul. Wer etwas anderes möchte, soll es selbst tun.