76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Contrib ist upgedated.

[Parallix]

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

War ja auch nur eine Frage. Sorry, wenn ich Dich auf dem falschen Fuß erwischt habe!

[DS_Starter]

Kein Problem. Dieses Thema gab es in der Vergangenheit öfter und wurde so oft diskutiert dass ich darauf mittlerweile allergisch reagiere. Das kann natürlich nicht jeder wissen wenn er die Historie nicht so kennt.

[Parallix]

Möglicherweise wird immer noch nicht richtig unterschieden zwischen

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

Das kann gut sein, ich weis auch nicht, wie ich das unterscheiden kann. Ich sehe nur wann eine Ladung erfolgt, aber nicht warum. Aber im Endeffekt muss sie ja immer der Wechselrichter vornehmen.
...

Den SoC unterhalb dem eine Erhaltungsladung erfolgen soll, kannst Du in aller Regel am WR einstellen und sollte dann, wenn Dein WR ersatz- oder notstromfähig ist, so hoch eingestellt werden, dass damit eine hinreichende Zeit ohne Netzversorgung überbrückt werden kann. Ist die Erhaltungsladung deaktiviert, so droht kein Schaden am Batteriesystem.

Bei der Notladung sieht das anders aus. Hier gibt das BMS selber vor, wann diese erfolgen muss, damit das Speichersystem keinen Schaden nimmt. Der SoC ab dem eine Notladung erfolgt ist userseitig in aller Regel nicht konfigurierbar. Seitens des WRs kannst Du diese Notladung nur dadurch verhindern, dass Du den Ladestrom auf Null setzt, was aber absolut nicht empfehlenswert ist, da damit die die Schutzfunktion des Speichersystems ausgehebelt wird und der Speicher - auch im Standby, also ohne aktive Speichernutzung - in Richtung kritisch niedriger Zellenspannungen (deutlich unter 3 V)  laufen kann.

[DS_Starter]

Ich habe nochmal etwas überarbeitet und schaut auch das Log schlüssig aus:

2025.11.12 11:45:35.271 1: SolCast DEBUG> ChargeMgmt Bat 01 - Target load and target time: 80 % / 22733 Wh / -
2025.11.12 11:45:35.271 1: SolCast DEBUG> ChargeMgmt Bat 01 - Percentage of the total amount of charging energy required: 100.0 %
2025.11.12 11:45:35.272 1: SolCast DEBUG> ChargeMgmt Bat 01 - The PV generation, consumption and surplus listed below are based on the battery's share of the total amount of charging energy required!
2025.11.12 11:45:35.279 1: SolCast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
2025.11.12 11:45:35.279 1: SolCast DEBUG> ChargeOTP Bat 01 - charging target: 22733 Wh, E requirement incl. efficiency: 10170 Wh -> target likely achievable? no
2025.11.12 11:45:35.280 1: SolCast DEBUG> ChargeOTP Bat 01 - Ratio of remaining surplus 6698 Wh / energy requirement to achieve the load target: 65.86 %
2025.11.12 11:45:35.280 1: SolCast DEBUG> ChargeOTP Bat 01 12/11 - hod:12/00, lr/lc:1/1, SocS/E:13071/14268 Wh, SurpH/D:4582/6698 Wh, OTP:5040/3377 W
2025.11.12 11:45:35.280 1: SolCast DEBUG> ChargeOTP Bat 01 12/12 - hod:13/01, lr/lc:1/1, SocS/E:14268/14588 Wh, SurpH/D:337/5552 Wh, OTP:5040/3377 W
2025.11.12 11:45:35.281 1: SolCast DEBUG> ChargeOTP Bat 01 12/13 - hod:14/02, lr/lc:1/1, SocS/E:14588/17796 Wh, SurpH/D:3377/5215 Wh, OTP:5040/3377 W
2025.11.12 11:45:35.281 1: SolCast DEBUG> ChargeOTP Bat 01 12/14 - hod:15/03, lr/lc:1/1, SocS/E:17796/19364 Wh, SurpH/D:1651/1838 Wh, OTP:5040/1651 W
2025.11.12 11:45:35.281 1: SolCast DEBUG> ChargeOTP Bat 01 12/15 - hod:16/04, lr/lc:1/1, SocS/E:19364/19542 Wh, SurpH/D:187/187 Wh, OTP:5040/187 W
2025.11.12 11:45:35.282 1: SolCast DEBUG> ChargeOTP Bat 01 12/16 - hod:17/05, lr/lc:1/1, SocS/E:19542/18922 Wh, SurpH/D:0/0 Wh, OTP:5040/- W

-> Surplus: 6698 / E mit Efficiency: 10170 = 0,6586 -> Ratio: 65.86 %  , achievable = no

Mit herabgesetzen Ziel und demzufolge Erreichbarkeit passt es ebenfalls:

Code Auswählen Erweitern

2025.11.12 11:52:43.184 1: SolCast DEBUG> ChargeMgmt Bat 01 - Target load and target time: 65 % / 18470 Wh / -
2025.11.12 11:52:43.185 1: SolCast DEBUG> ChargeMgmt Bat 01 - Percentage of the total amount of charging energy required: 100.0 %
2025.11.12 11:52:43.185 1: SolCast DEBUG> ChargeMgmt Bat 01 - The PV generation, consumption and surplus listed below are based on the battery's share of the total amount of charging energy required!
2025.11.12 11:52:43.190 1: SolCast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
2025.11.12 11:52:43.191 1: SolCast DEBUG> ChargeOTP Bat 01 - charging target: 18470 Wh, E requirement incl. efficiency: 5384 Wh -> target likely achievable? yes
2025.11.12 11:52:43.191 1: SolCast DEBUG> ChargeOTP Bat 01 - Ratio of remaining surplus 6163 Wh / energy requirement to achieve the load target: 114.48 %
2025.11.12 11:52:43.191 1: SolCast DEBUG> ChargeOTP Bat 01 12/11 - hod:12/00, lr/lc:1/1, SocS/E:13356/13791 Wh, SurpH/D:4582/6163 Wh, OTP:3440/2592 W
2025.11.12 11:52:43.192 1: SolCast DEBUG> ChargeOTP Bat 01 12/12 - hod:13/01, lr/lc:1/1, SocS/E:13791/14111 Wh, SurpH/D:337/5552 Wh, OTP:3605/2502 W
2025.11.12 11:52:43.192 1: SolCast DEBUG> ChargeOTP Bat 01 12/13 - hod:14/02, lr/lc:1/1, SocS/E:14111/17319 Wh, SurpH/D:3377/5215 Wh, OTP:3493/2519 W
2025.11.12 11:52:43.192 1: SolCast DEBUG> ChargeOTP Bat 01 12/14 - hod:15/03, lr/lc:1/1, SocS/E:17319/18282 Wh, SurpH/D:1651/1838 Wh, OTP:1014/963 W
2025.11.12 11:52:43.193 1: SolCast DEBUG> ChargeOTP Bat 01 12/15 - hod:16/04, lr/lc:1/1, SocS/E:18282/18460 Wh, SurpH/D:187/187 Wh, OTP:5040/187 W
2025.11.12 11:52:43.193 1: SolCast DEBUG> ChargeOTP Bat 01 12/16 - hod:17/05, lr/lc:1/1, SocS/E:18460/17840 Wh, SurpH/D:0/0 Wh, OTP:5040/- W

Contrib ist upgedated.

LG,
Heiko

[DS_Starter]

Hallo zusammen,

nach meinen letzten Beobachtungen sollte es bzgl. der smartPower Bat-Steuerung keine Beanstandungen mehr geben. Ich hoffe das ihr bzw. Hadl/Parallix das bestätigen könnt.

Eine Sache geht mir im Kopf herum, die ich gern andiskutieren möchte. Soviel ich weiß, sollte eine LifePo4 Batterie nicht ständig auf 100% geladen werden, sondern eher regelmäßig zwischen 20 - 80% und in Abständen bis 100%. (Das kommt im Winter eher selten vor) Habt ihr einen anderen Kenntnisstand oder trifft das i.A. so zu für eine lange Lebensdauer?

Das Modul unterstützt bereits einen solchen Zyklus, z.B. mit ctrlBatSocManagementXX->loadTarget=80, ctrlBatSocManagementXX->maxSoC=100 und ctrlBatSocManagementXX->careCycle=20.
Dann wird die Bat im Normalfall bis 80% geladen, außer der 20-Tage Zyklus erfordert eine höhere Ladung bis 100%.

Der untere Wert kann duch lowSoC festgelegt werden. Für dynamische Änderungen, z.B. für Einstellungen im Sommer- oder Winterhalbjahr, gibt es die Möglichkeit diese Werte mit "set ... attrKeyVal ..." programmgesteuert anzupassen.

Seht ihr Notwendigkeiten für weitere Bat-Steuerungsparameter / Prozesse oder sind diese Möglichkeiten mittlerweile als völlig ausreichend einzuschätzen?

LG,
Heiko 

[Parallix]

Hallo zusammen,

nach meinen letzten Beobachtungen sollte es bzgl. der smartPower Bat-Steuerung keine Beanstandungen mehr geben. Ich hoffe das ihr bzw. Hadl/Parallix das bestätigen könnt.

Ja! Das was bislang eingebaut ist, funktioniert!

Eine Sache geht mir im Kopf herum, die ich gern andiskutieren möchte. Soviel ich weiß, sollte eine LifePo4 Batterie nicht ständig auf 100% geladen werden, sondern eher regelmäßig zwischen 20 - 80% und in Abständen bis 100%. (Das kommt im Winter eher selten vor) Habt ihr einen anderen Kenntnisstand oder trifft das i.A. so zu für eine lange Lebensdauer?

Was die Lebensdauer angeht, so kann diese tatsächlich durch eine jahreszeitliche Anpassung des SoC-Fensers, in dem ein täglicher Zyklus erfolgt, gesteigert werden.

Das Modul unterstützt bereits einen solchen Zyklus, z.B. mit ctrlBatSocManagementXX->loadTarget=80, ctrlBatSocManagementXX->maxSoC=100 und ctrlBatSocManagementXX->careCycle=20.
Dann wird die Bat im Normalfall bis 80% geladen, außer der 20-Tage Zyklus erfordert eine höhere Ladung bis 100%.
...

In der Tat ist es absolut sinnvoll, wenn die sogenannte Wartung bei einem Ziel-SOC von 100%, die eigentlich besser SOC-Rekalibrierung heißen sollte, nicht vorfällig erfolgt.

Seht ihr Notwendigkeiten für weitere Bat-Steuerungsparameter / Prozesse oder sind diese Möglichkeiten mittlerweile als völlig ausreichend einzuschätzen?

Mir persönlich fehlt noch eine längerfristiger Planungshorizont in Bezug auf die Ladeprozesse, die bei einem EV zu tragen kommen.

[DS_Starter]

Mir persönlich fehlt noch eine längerfristiger Planungshorizont in Bezug auf die Ladeprozesse, die bei einem EV zu tragen kommen.

Hierzu fehlen mir die praktischen Erfahrungen der jeweiligen Erfordernisse und Zieldefinitionen. Wenn du in der Lage wärst ein Ablaufdiagramm oder einen Metacode für eine derartige Steuerung zu erstellen, könnte ich schauen ob/wie eine solche Lösung integriert werden könnte.
Alternativ käme auch eine Schnittstelle zum Andocken eines externen (FHEM)-Planungstools in Frage je nach Sachlage.

[Parallix]

Mir persönlich fehlt noch eine längerfristiger Planungshorizont in Bezug auf die Ladeprozesse, die bei einem EV zu tragen kommen.

Hierzu fehlen mir die praktischen Erfahrungen der jeweiligen Erfordernisse und Zieldefinitionen. Wenn du in der Lage wärst ein Ablaufdiagramm oder einen Metacode für eine derartige Steuerung zu erstellen, könnte ich schauen ob/wie eine solche Lösung integriert werden könnte.
Alternativ käme auch eine Schnittstelle zum Andocken eines externen (FHEM)-Planungstools in Frage je nach Sachlage.

Hier eine Beschreibung eines typischen Szenarios: EV wird mit einem SoC von z.B. 30% (kann auch anders sein) am Freitagnachmittag um 14:00 Uhr an die eigene Wallbox angeklemmt. Es wird am Tag danach um  16:30 Uhr für eine (Hin- und Rück-)Fahrt gebraucht, bei der sich der SoC um typischerweise 10% (kann also als fix angenommen werden) verringert. Im Anschluss steht das EV bis Montag 9:00 Uhr zur Ladung zur Verfügung und muss vor Fahrtantritt wieder einen SoC von 70% (ist als Wert anzusehen, der weder unter noch überschritten werden darf) besitzen, damit für den Rest der Woche keine Zwischenladungen außer Haus erfolgen müssen.

Randbedingen und sonstiges: Die Ladung an der Wallbox kann mit einer variablen Leistung, z.B. zwischen 4 kW und 11 kW erfolgen. Der Hausspeicher soll nicht zum energetisch unsinnigen Umladen (Solar -> Hausspeicher -> EV) verwendet werden, darf aber zur Pufferung kurzzeitiger (!) solarer Versorgungslücken (aufgrund einer kurzzeitig schwankenden solaren Produktion) herangezogen werden, sollte dann aber aus Backup-Gründen einen Mindest-SoC nicht unterschreiten. Die Prio das EV zu laden steigt über der Zeit, sodass das Ladeziel zur Zielzeit und Zieltag (im Beispiel Montag 9:00 Uhr) auch sicher erfüllt sein muss.

[DS_Starter]

Morgen früh ist die V 1.60.4 im Update enthalten.

LG

[Hadl]

Ja, Smartpower funktioniert jetzt echt super! Hoffentlich kommt noch oft viel PV Leistung so dass wir das genießen können!

Eine Sache geht mir im Kopf herum, die ich gern andiskutieren möchte. Soviel ich weiß, sollte eine LifePo4 Batterie nicht ständig auf 100% geladen werden, sondern eher regelmäßig zwischen 20 - 80% und in Abständen bis 100%. (Das kommt im Winter eher selten vor) Habt ihr einen anderen Kenntnisstand oder trifft das i.A. so zu für eine lange Lebensdauer?

Ich beobachte meinen Akku ziemlich genau und muss sagen dass sie SOC Schätzung wirklich sehr fehlerbehaftet ist.
Soweit ich weiß sind es vor allem sehr hohe und sehr niedrige Spannungen der Zellen über längere Zeit die den Akku Schaden.
Die Spannung steigt erst kurz vor 100% schnell an. Wenn das BMS das sieht definiert es dass dies wohl 100% sind. Auch wenn er kurz vorher noch 80% geschätzt hat.
Und das kommt bei mir selbst bei einem konfigurierten Maximum von 80% alle 3-6 Tage vor. Dann macht er balancing und schiebt etwas Ladung aus diesen Zellen in Niedrigere.
Und es muss oft balancen bis eine Zelle die Maximum war mal nichtmehr dabei ist.

Das gleiche passiert auch auf der anderen Seite bei leeren Akku.
Nur das da eben durch die Selbstentladung es über die Zeit eher noch weniger Ladung wird.

Ich denke am besten schützen wir den Akku wenn wir lange Zeiten auf ganz hohen und niedrigen SOC vermeiden und auch die Leistungen gering halten.

Im Winter also den Akku am besten nicht ganz leer werden lassen, oder vielleicht die Entladung bis zum Sonnenaufgang mit niedriger Leistung einteilen und parallel Strom einkaufen. Also das Gegenteil von OTP bei der Entladung.

VG

Hadl

[grappa24]

Mir persönlich fehlt noch eine längerfristiger Planungshorizont in Bezug auf die Ladeprozesse, die bei einem EV zu tragen kommen.

Hierzu fehlen mir die praktischen Erfahrungen der jeweiligen Erfordernisse und Zieldefinitionen. Wenn du in der Lage wärst ein Ablaufdiagramm oder einen Metacode für eine derartige Steuerung zu erstellen, könnte ich schauen ob/wie eine solche Lösung integriert werden könnte.
Alternativ käme auch eine Schnittstelle zum Andocken eines externen (FHEM)-Planungstools in Frage je nach Sachlage.

Ich nutze zur Steuerung meines PHEV (leider nur 11kWh Akku) das Tool EVCC (https://docs.evcc.io/docs/Home). Da EVCC auch die Hausbatterie mit einbezieht kommt es natürlich zu "konkurrierendem" Zugriff zwischen SF und EVCC  Damit kann ich aber ganz gut leben. Ich bin nicht sicher, ob es möglich ist / es sich lohnt die Funktionen von EVCC in SF abzubilden. Da könnte ich mir schon eher das Andocken von EVCC an SF vorstellen - um z.B. in konkurrierenden Situationen zu "vermitteln" 
Ich kann aber auch dich @Parallix verstehen, wenn du EVCC nicht einsetzen möchtest (ist je nach Modell mit Kosten verbunden) und lieber SF vorantreiben möchtest.
Mein Angebot: Wenn du Heiko dich entscheiden solltest, eine EV-Steuerung zu integrieren, bin ich natürlich bereit, meine Use-Cases im Zusammenspiel zwischen EVCC und SF darzustellen.

[DS_Starter]

Mein Angebot: Wenn du Heiko dich entscheiden solltest, eine EV-Steuerung zu integrieren, bin ich natürlich bereit, meine Use-Cases im Zusammenspiel zwischen EVCC und SF darzustellen.

Danke dir. Es ist in dem Umfeld mein Problem überhaupt keine eigenen Erfahrungen und Tests einbringen zu können und muß mich ausschließlich auf euren Input und Unterstützung verlassen. Das kann echt nervig sein. Viele Dinge entwickle und teste ich erst bei mir bevor ich sie quasi zur Verifikation herausgebe.

Ich bin mir tatsächlich unsicher inwiefern ich bei dem Ansinnen unterstützen kann. Vom Bauchgefühl her würde ich eine definierte Schnittstelle zwischen SF und dem externen Tool (EVCC / FHEM) anbieten / bevorzugen. Wie diese aussehen sollte, müßte auch noch definiert werden.

[Max_Meyer]

Wie diese aussehen sollte, müßte auch noch definiert werden.

Hallo Heiko, Hallo Grappa24, Hallo Parallix,

Die Schnittstelle gibst schon - ich betreibe EVCC seit einiger Zeit mit FHEM-Daten über MQTT (siehe screen) - auch Antworten/Entscheidungen aus EVCC lassen sich auf diese Weise einfach nutzen - selber hab ich (bisher) keinen Mehrwert aus der Verbindung erkennen können - und das auch nicht weiter verwendet - aber Darstellung und Grafik empfinde ich ansprechend.
Ich hab das BEV als Verbraucher in SF abgebildet (switchOn/off=Kabel angesteckt,  must vs.can ergibt sich aus dem SOC,Ladesoll [80%] im Auto,) - wieviel und wann der lädt regelt das DoIf - aber in der Heizsaison (also jetzt) lädt er fast vollständig nur nachts (Grund: während der Nacht ist die WP selten an damit lassen sich die BAT's drosseln so dass sie nur die Grundlast liefern. (das ist der derzeitige (Zwischen)-Stand bei mir)

Gruß Gerd

[Parallix]

Mein Angebot: Wenn du Heiko dich entscheiden solltest, eine EV-Steuerung zu integrieren, bin ich natürlich bereit, meine Use-Cases im Zusammenspiel zwischen EVCC und SF darzustellen.

Danke dir. Es ist in dem Umfeld mein Problem überhaupt keine eigenen Erfahrungen und Tests einbringen zu können und muß mich ausschließlich auf euren Input und Unterstützung verlassen. Das kann echt nervig sein. Viele Dinge entwickle und teste ich erst bei mir bevor ich sie quasi zur Verifikation herausgebe.

Meine Unterstützung sichere ich Dir gerne zu!

PS: Mein EV hat ca. 70 kWh. In dieser Größenordnung lässt sich durch eine gute prognosebasierte Planung - so wie es SF ja schon für die Hausspeicher exzellent macht - sehr viel erreichen.