76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Ich habe nochmal im Code geschaut. Mit dem Multibatterie Management (und dem obligatorischen cap) ist das "einfache" Ausschalten nicht mehr so simpel. 
Ich habe schon eine Idee es wieder einfach zu gestalten, aber erst Morgen. Heute ist es für diese Operation etwas zu spät geworden.
Melde mich morgen dazu nochmal.

[peterboeckmann]

Wenn Du da schon für mich ran gehst: Besteht evtl. auch die Möglichkeit, eine maximale Ladeleistung sowie min- und max-SoC an den einzelnen Batterien zu definieren und diese in der Prognose zu berücksichtigen?

Der SoC meiner Batterie schwankt (gesteuert durch Logik, die ich nicht beeinflussen kann) zwischen 3% und 100%. Die Ladeleistung liegt maximal bei 2580Watt.

Und wie immer: das ist weder eilig noch wichtig. Es soll ja in erster Linie Spaß machen, auch Dir als Entwickler.

Vielen Dank und viele Grüße,
Peter

[DS_Starter]

Wenn Du da schon für mich ran gehst: Besteht evtl. auch die Möglichkeit, eine maximale Ladeleistung sowie min- und max-SoC an den einzelnen Batterien zu definieren und diese in der Prognose zu berücksichtigen?

Da muß ich mal schauen. min- und max-SoC der einzelnen Batterien kannst du eigentlich schon im Attr ctrlBatSocManagementXX festlegen, ist aber fest und nicht dynamisch änderbar.
Möglicherweise lege ich das auf ein späteres Release. Den aktuellen Entwicklungsstand will ich erstmal finalisieren und für alle einchecken.

[peterboeckmann]

Hallo Heiko,

Da muß ich mal schauen. min- und max-SoC der einzelnen Batterien kannst du eigentlich schon im Attr ctrlBatSocManagementXX festlegen, ist aber fest und nicht dynamisch änderbar.

Dann warte ich dann erstmal Deine finalisierte Version ab, bevor ich das attr ctrlBatSocManagement01 wieder anlege.

Dynamische Änderung brauche ich (und ich kann da nur für mich sprechen) nicht. Ich könnte auch mit der SoC-Range 0-100 leben. Die SoC-Range 3-100, die mein Enphase-Gateway steuert, ist ja nicht so weit davon weg.

Wichtiger wäre mir, dass die Prognose des SoC realistischer für meine Rahmenbedingungen ist.
Klar lässt sich das nicht 1:1 nachbilden, ohne die genaue Logik zu kennen. Aber es soll ja auch "nur" eine Prognose sein. Das kann und muss auch nicht 100% stimmen.

Wenn Du was zu testen hast, stehe ich gerne bereit.

Viele Grüße,
Peter

[DS_Starter]

Guten Morgen,

in meinem contrib liegt ein Update. Jetzt klappt das Abschalten des Bat Lademanagements wieder so wie kommuniziert durch Löschen/nicht Setzen des Attr ctrlBatSocManagementXX.

Die Unterschiede sieht man in den angehängten Screens.
Im linken Screen ist ctrlBatSocManagementXX eingeschaltet und lt. Prognose wird die Bat erst 15:00 zu 100% geladen sein.

Im rechten Screen ist ctrlBatSocManagementXX nicht eingeschaltet und die Bat wird sofort mit dem PV Überschuß geladen, sodass sie bereits 11:00 volll sein wird. Der Überschuß wird ab dem Erzeugnisspeak ins Netz eingespeist was nicht netzdienlich ist, zumal eine Abregelung der PV Anlage die Folge sein kann.

@Peter, jetzt sollten deine Bat Prognose den Verlauf anzeigen wie du es dir wünscht. Deine anderen Punkte schaue ich mir später an.

[peterboeckmann]

in meinem contrib liegt ein Update

Wow! Das ging ja schnell. Ich ziehe das gleich mal.

[peterboeckmann]

Hallo Heiko,

das sieht für meine Umgebung schon sehr gut aus:

Code Auswählen Erweitern

2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 08 -> 1 (currsoc: 11 %, SoCfc: 8.1 %, soc: 566 Wh, pvfc: 500, confc: 684, Surp Day: 16496 Wh, Curr PV: 1696 W, Curr Consumption: 667 W, Limit: 10000 W)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 09 -> 1 (SoCfc: 21.8 %, soc: 1525 Wh, pvfc: 1892, confc: 826, Surp Day: 15430 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 10 -> 1 (SoCfc: 44.2 %, soc: 3095 Wh, pvfc: 2451, confc: 707, Surp Day: 13686 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 11 -> 1 (SoCfc: 74.5 %, soc: 5213 Wh, pvfc: 3026, confc: 673, Surp Day: 11333 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 12 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 3387, confc: 652, Surp Day: 8598 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 13 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 4456, confc: 870, Surp Day: 5012 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 14 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 3645, confc: 1504, Surp Day: 2871 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 15 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 3369, confc: 1422, Surp Day: 924 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 16 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 2253, confc: 711, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 17 -> 1 (SoCfc: 84.2 %, soc: 5897 Wh, pvfc: 211, confc: 1204, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 18 -> 1 (SoCfc: 73.6 %, soc: 5151 Wh, pvfc: 0, confc: 671, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 19 -> 1 (SoCfc: 63.1 %, soc: 4417 Wh, pvfc: 0, confc: 661, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 20 -> 1 (SoCfc: 52.4 %, soc: 3666 Wh, pvfc: 0, confc: 676, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 21 -> 1 (SoCfc: 43.4 %, soc: 3040 Wh, pvfc: 0, confc: 563, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 22 -> 1 (SoCfc: 35.4 %, soc: 2479 Wh, pvfc: 0, confc: 505, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 05 23 -> 1 (SoCfc: 26.5 %, soc: 1853 Wh, pvfc: 0, confc: 563, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 00 -> 1 (SoCfc: 17.6 %, soc: 1234 Wh, pvfc: 0, confc: 557, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 01 -> 1 (SoCfc: 9.9 %, soc: 695 Wh, pvfc: 0, confc: 485, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 02 -> 1 (SoCfc: 2.4 %, soc: 168 Wh, pvfc: 0, confc: 474, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 03 -> 1 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 0, confc: 503, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 04 -> 1 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 0, confc: 448, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 05 -> 1 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 0, confc: 481, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 06 -> 1 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 14, confc: 575, Surp Day: 14517 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 07 -> 1 (SoCfc: 0.0 %, soc: 0 Wh, pvfc: 356, confc: 686, Surp Day: 14847 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 08 -> 1 (SoCfc: 0.5 %, soc: 32 Wh, pvfc: 720, confc: 684, Surp Day: 14811 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 09 -> 1 (SoCfc: 14.1 %, soc: 990 Wh, pvfc: 1891, confc: 826, Surp Day: 13746 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 10 -> 1 (SoCfc: 59.9 %, soc: 4196 Wh, pvfc: 4269, confc: 707, Surp Day: 10184 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 11 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 5657, confc: 673, Surp Day: 5200 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 12 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 5144, confc: 652, Surp Day: 708 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 13 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 2106, confc: 870, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 14 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 3021, confc: 1504, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 15 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 4673, confc: 1422, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 16 -> 1 (SoCfc: 100.0 %, soc: 7000 Wh, pvfc: 1484, confc: 711, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 17 -> 1 (SoCfc: 86.5 %, soc: 6056 Wh, pvfc: 354, confc: 1204, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 18 -> 1 (SoCfc: 75.9 %, soc: 5310 Wh, pvfc: 0, confc: 671, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 19 -> 1 (SoCfc: 65.4 %, soc: 4576 Wh, pvfc: 0, confc: 661, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 20 -> 1 (SoCfc: 54.6 %, soc: 3825 Wh, pvfc: 0, confc: 676, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 21 -> 1 (SoCfc: 45.7 %, soc: 3199 Wh, pvfc: 0, confc: 563, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 22 -> 1 (SoCfc: 37.7 %, soc: 2638 Wh, pvfc: 0, confc: 505, Surp Day: 0 Wh)
2025.03.05 08:36:41 1: SolarForecast DEBUG> Bat 01 relLoad 06 23 -> 1 (SoCfc: 28.7 %, soc: 2012 Wh, pvfc: 0, confc: 563, Surp Day: 0 Wh)
Die kleinen Punkte für Deine zukünftige Entwicklung sind hier nochmal gut zu sehen:
1) Der SoC wird nie auf 0% runter gehen, wie hier zwischen 06 02 und 06 08 zu sehen. Bei mir geht es bis minimal 3% runter.
2) Mein Speicher wird nie mit mehr als 2580W ge- oder entladen. In der Prognose würde diese Einschränkung bei 06 09 bis 06 11 greifen.

Wie gesagt: Für mich passen die aktuellen Änderungen gut. Danke dafür!

Viele Grüße,
Peter

[DS_Starter]

Prima.

1) Der SoC wird nie auf 0% runter gehen, wie hier zwischen 06 02 und 06 08 zu sehen. Bei mir geht es bis minimal 3% runter.

Die SoC Begrenzungen sind Bestandteil der SoC Steuerung (ctrlBatSocManagementXX). Wenn man das Attr aus den genannten Gründen nicht setzt, greifen diese Einstellungen auch nicht. Damit muss man dann leben denke ich.
Das Verfahren muß einer gewissen Stringenz folgen.

2) Mein Speicher wird nie mit mehr als 2580W ge- oder entladen. In der Prognose würde diese Einschränkung bei 06 09 bis 06 11 greifen.

Das ist eine Eigenschaft des Speichers, den ich in einem Schlüssel im Attr setupBatteryDevXX abbilden könnte und dadurch in die Berechnung einfließen lassen kann.
Schaue ich mir mal in einer späteren Weiterentwicklung mit an.

LG,
Heiko

[DS_Starter]

Hallo zusammen,

wahrscheinlich am Freitag wird die Version 1.47.0 im Update ausgeliefert.
Es ist ein Major Release. Diese Version ist nicht rückwärts kompatibel, d.h. Sicherungen und Backupfiles von Versionen < 1.47.0 sind mit dieser Version nicht kompatibel.

Was ist alles entalten?

- die KI ist erweitert um einen einstellbaren Essemble Algorithmus (Random Forests mit Essemble Algorithmus)

- ein neues Attribut aiControl ersetzt die bisherigen Attr ctrlAIdataStorageDuration und ctrlAIshiftTrainStart mit entspr. Schlüsseln

- im Attribut aiControl gibt es den Schlüssel aiTreesPV mit dem die Größe des Ensembles (s.o.) eingestellt werden kann

- das Training der KI erfolgt immer in einem Nebenprozess um keinerlei Blockierungen im System zu verursachen

- im Batteriemanagement sind einige Verbesserungen bzgl. der SoC Prognose eingeflossen und die Abhängigkeit vom Attr ctrlBatSocManagementXX wiederhergestellt

- die Setter "set ... aiDecTree addInstances" und "train" sind entfallen und wurden durch einen kombinierten Setter "set ... addInstAndTrain" ersetzt

- die Diff-Balkenanzeige ist bzgl. der Nachkommastellen überarbeitet

- kleinere Bugfixes


Alle Änderungen an Attributen werden automatisch vorgenommen. Ihr braucht nichts tun außer das Log nach dem Update kontrollieren und "save config" drücken um die Attributänderungen zu speichern.

Im Log kommt der Hinweis:

Code Auswählen Erweitern

The attribute ctrlAIshiftTrainStart / ctrlAIdataStorageDuration is replaced by 'aiControl'. Please press 'save config' when restart is finished.
Solltet ihr nach dem Update von KI Fehlermeldungen erhalten, etwa "The trained object is not AI::DecisionTree", wartet ihr einfach bis zum nächsten automatischen KI Training oder führt "set ... aiDecTree addInstAndTrain" manuell aus.
 

Dann noch der Hinweis, dass ihr eure KI im Attribut aiControl, Schlüssel aiTreesPV bzgl. der Anzahl der trainierten Bäume einstellen könnt.
Standard ist 10. Bisher wurde nur ein Tree trainiert. Je mehr Trees ihr einstellt, desto robuster wird tendenziell die KI-Prognose und hat auch deutlich mehr Treffer.
Aber wo Licht ist, gibt es auch Schatten. Je mehr Trees ihr rechnet, desto mehr Rssourcen CPU, RAM werden benötigt. Die CPU eigentlich nur beim Training. Das läuft jetzt generell in einem Nebenprozess ab. Ihr braucht keine Bedenken wegen irgendwelcher Blockierungen in FHEM zu haben.
Aber der RAM-Verbrauch steigt mit steigender Tree Anzahl an. Je nach eurer Hardware könnt ihr ein bisschen probieren um das Optimum zu finden.

Als Beispiel habe ich 4600 Rohdatensätze und lasse 10 Trees (den Standard) rechnen. Damit erhalte ich für ca. 80% der Stundenwerte einen Treffer von der KI. Der RAM liegt bei 710 MB, Allerdings habe ich 5 SF-Instanzen parallel laufen, davon 3 mit KI Unterstützung.

Die Version liegt schon vorab im contrib. FHEM auf jeden Fall nach dem Download restarten.


LG,
Heiko

[DS_Starter]

Nur mal so nebenbei, gestern und heute hatte ich auf einer meiner Instanzen Abweichungen von nur 0,8% bzw. -0,3%. Die Instanz verwendet die SolCast API.
Aber das ist schon sehr außergewöhnlich und nur der sehr stabilen Wetterlage geschuldet.
Es freut aber trotzdem. 

[300P]

Das ist wirklich ein sehr gutes Ergebnis bei dir


Schade - bei mir in den letzten Tagen teils >= -100 % daneben  
Also immer mehr geerntet als der Forecast (DWD) "sagte" 


Trotzdem wunderbar wenn die Batterie bis zum Rand voll wird 

[stefanru]

Bei mir 2,9 % und -1,5 %, das sind doch Hammer Zahlen!
Ich benutze 2 DWD Stationen.

Gruß,
Stefan

[300P]

Ich benutze 2 DWD Stationen.

Darüber denke ich momentan auch nach....
War bislang in den letzten Jahren sonst besser

[DS_Starter]

Naja, das ist wie geschrieben schon sehr außergwöhlich. Normal liegen die Abweichungen bei +-2 - 30% je nach Witterungslage. Bei ganz schlechten Bedingungen auch mehr.

[300P]

Ja, aber wenn den ganzen Tag Sonne diese Woche vorausgesagt wird ist da schon etwas verwunderlich wenn mein Forecast mehrere Tage "voll daneben" liegt.
(sorry - liegt evtl. aber auch an meinem Standort bzw. den Zahlen die DWD dafür vorgibt)