76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Gisbert]

Moin Peter,

vielen Dank für die Daten.

Die Wetter-Zeile zeigt zwar leichte Bewölkung (zwischen 38 und 50), bei WetterOnline ist davon nichts zu sehen.

Solche Unterschiede gibt es. Auch DWD_OpenData (API) und die ICON Modelle des DWD (OpenMeteoDWD) liefern u.U. andere Prognosedaten für die gleiche Umgebung.
Auch werden z.B. eine WetterID "0" (=wolkenloser Himmel) geliefert und Neff (die Bewölkung) hat einen Wert von ungleich "0", was ja eigentlich nicht zusammenpasst. Hier versuche ich aktuell ein Schema zu finden wie DWD an dieser Stelle agiert.

Wenn du tiefer einsteigen möchtest, ist diese Seite des DWD ein guter Startpunkt um zu weiteren Dokumenten zu verzweigen.

LG,
Heiko

Hallo Heiko,

heute hab ich die Situation, dass im SolarForecast-Modul mit dem MODEL OpenMeteoDWDEnsembleAPI nur 4.2 kWh (kWp 15 kW) prognostiziert werden, wohingegen WetterOnline fast durchgängig einen wolkenlosen Himmel (bis auf nachmittags leichte Schleier-Bewölkung) vorhersagt - vermutlich werden es 20 kWh, vielleicht mehr.

Kann ich irgendetwas an dieser Situation verbessern?

Viele Grüße Gisbert

[Parallix]

...

Noch eine Frage: Kannst Du den Leistungswert, auf dessen Basis  remainingSurplsHrsMinPwrBat_XX bestimmt wird, zugänglich machen?

Nein, es gibt nicht den "einen" Leistungswert, es sei denn du meinst <MinPwr> aus dem Schlüssel:

Code Auswählen Erweitern

ctrlBatSocManagementXX->loadAbort=<SoC1>:<MinPwr>:<SoC2>
Ansonsten muß man sich durch den Code wühlen ab Zeile 16129 der contrib Version.
Aus welchem Anlass fragst du danach?

Nein, den von Dir oben genannten Attributwert meine ich nicht. Es geht mir schlicht darum, für die jeweilige Bat ein special Reading zu haben, in dem der aktuelle Leistungswert steht, auf den sich remainingSurplsHrsMinPwrBat_XX bezieht.

Der Anlass ist zum einen der, dass ich derzeit noch einem EV-ChargingController arbeite und diesen Wert gut gebrauchen könnte. Zum anderen habe sehe ich aktuell sehr kleine Werte bei remainingSurplsHrsMinPwrBat_XX, die ich nicht nachvollziehen kann.

[DS_Starter]

Hallo Gisbert,

heute hab ich die Situation, dass im SolarForecast-Modul mit dem MODEL OpenMeteoDWDEnsembleAPI nur 4.2 kWh (kWp 15 kW) prognostiziert werden, wohingegen WetterOnline fast durchgängig einen wolkenlosen Himmel (bis auf nachmittags leichte Schleier-Bewölkung) vorhersagt - vermutlich werden es 20 kWh, vielleicht mehr.

Kann ich irgendetwas an dieser Situation verbessern?

An den Input-Daten der Wetterdienste können wir nichts ändern. Sie sind entweder zutreffend oder nicht.
Du kannst nur einen Dienst auswählen der für deinen Standort die passendsten Werte liefert, z.B. alternativ OpenMeteoDWD_D2-API oder OpenMeteoDWD-API. Eine 100%ige Treffsicherheit gibt es leider nicht, gerade in der aktuellen Jahreszeit.

LG,
Heiko

[DS_Starter]

@Parallix,

Nein, den von Dir oben genannten Attributwert meine ich nicht. Es geht mir schlicht darum, für die jeweilige Bat ein special Reading zu haben, in dem der aktuelle Leistungswert steht, auf den sich remainingSurplsHrsMinPwrBat_XX bezieht

Neben dem Attributwert sind die NextHours-Werte pvfc, confc, today, hourofday relevant. Abfragen kann man sie wie hier beschrieben.
Weiterhin noch sunsetTodayTs, der mit CurrentVal (<name>, 'sunsetTodayTs', 0) abgefragt werden kann (wie im obigen Link beschrieben).

Die wenigen remainingSurplsHrsMinPwrBat_XX werden sicherlich von dem aktuell wenigen Überschußstunden herrühren in denen zusätzlich auch noch die minimalen Ladeleistung <MinPwr> zu erwarten ist.

LG,
Heiko

[300P]

Frohe Weihnachten an Alle !


-->>Bild nach Weihnachten entfernt - jetzt nur noch siehe unten


Viele die auf einen sonnigen Weihnachtstag mit großen Ertrag als Geschenk gehofft haben....
...sie haben ihn bekommen - aber mit viel Kälte.

[DS_Starter]

Den Wünschen schließe ich mich an. Bleibt alle gesund!

Als kleinen Ausblick habe ich vorbereitend einen Artikel zur KI-Verbrauchsprognose erstellt. In der Zwischenzeit ist schon sehr viel passiert. Die Modellierung ist vorangeschritten. Es wird diverse Einstellmöglichkeiten zur Modellanpassung geben.

Es sind noch ein paar Schwierigkeiten zu lösen, aber die Fortschritte/Ergebnisse stimmen mich außerordentlich zuversichtlich, auch im Hinblick auf die beabsichtigte Ersetzung der aktuellen AI:Decitiontree mit einem echten neuronalen Netz für die PV-Prognose.

Dann schauen wir mal zuversichtlich in die Zukunft

LG,
Heiko 

[300P]

Als kleinen Ausblick habe ich vorbereitend einen Artikel zur KI-Verbrauchsprognose erstellt. In der Zwischenzeit ist schon sehr viel passiert. Die Modellierung ist vorangeschritten. Es wird diverse Einstellmöglichkeiten zur Modellanpassung geben.

Hallo Heiko,

bin wieder aus der Sonne zurück und versuche mich bei den Einstellungen gemäß des obigen Artikels.
Meist schreibe ich mir am Anfang von neuen Sachen alle Parameter - egal ob ich Standart nutze oder nicht -  zur Übersicht mit in die jeweiligen Attribute hinein um dann den einen deren evtl. mal dann auszuprobieren.

Bislang habe ich folgendes hinterlegt:

Code Auswählen Erweitern

aiTrainStart=3
aiStorageDuration=3600
aiTreesPV=30
aiConActivate=1
aiConLearnRate=0.001
aiConMomentum=0.7
aiConShuffleMode=1
aiConShufflePeriod=10
aiConSteepness=0.9
aiConTrainAlgo=RPROP


Jetzt meine Frage (frei nach dem heiteren Beruferaten "Was bin ich" ->> Hans Sachs)     

Gehe ich (z.Z. noch) recht in der Annahme das:

Code Auswählen Erweitern

- aiConHiddenLayers=80‑40‑20
- aiConTrainStart=3:1
- aiConActFunc=GAUSSIAN

noch nicht als Parameter eintragbar und als Parameter mit dieser u.s. aktuellen Version 2.0.0 im Contrib vom 10,12,2025 noch nicht genutzt werden kann?

Code Auswählen Erweitern

# Versions History intern
164 my %vNotesIntern = (
165   "2.0.0"  => "10.12.2025  initial implementation of neural network for consumption forecasting with AI::FANN ".
166                            "aiControl: more keys for aiCon... ".
167                            "edit commandRef, remove __batSaveSocKeyFigures ",
168   "1.60.7" => "21.11.2025  new special Reading BatRatio, minor code changes ",

Aus dem Code geht dies n.m.A. so hervor.
Danke für eine kurze Info dazu
Gruß
Günter

[300P]

Hier (unten) die aktuellen Ergebnisse vorher <==> nachher bei mir zu den obigen vorgenommenen Einstellungen:
(Anlage mit 7kW-WP / 14.5 kWp PV / 26 kW Akku)

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 27.12.2025 16:36:49 / Laufzeit in Sekunden: 589.53
letzte KI-Ergebnis Generierungsdauer: 0.13 ms

=== Modellparameter ===

Trainingsdaten: 6649 Datensätze (Training=5319, Validierung=1330)
Architektur: Inputs=18, Hidden Layers=64-32-16, Outputs=1
Hyperparameter: Learning Rate=0.001, Momentum=0.7, BitFail-Limit=0.35
Aktivierungen: Hidden=SIGMOID, Steilheit=0.9, Output=LINEAR
Zufallsgenerator: Mode=1, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 154 (von max. 15000)
Training MSE: 0.004
Validation MSE: 0.002
Validation Bit_Fail: 0
bester Trainingslauf: 0
Trainingsbewertung: ok (Val MSE Standard Deviation=0.000123, Val MSE Avg=0.002798)

=== Fehlermaße der Prognosen ===

MAE: 679.94 Wh
MedAE: 637.03 Wh
RMSE: 0.045
MAPE: 41.330 %
MdAPE: 33.187 %
R²: 0.014

 Erläuterung der Kennzahlen

Train MSE / Validation MSE → wie gut das Netz trainiert und generalisiert. Daumenregel:
   MSE < 0.01 → sehr gut
   MSE 0.01–0.05 → gut
   MSE > 0.1 → schwach
   Interpretation Verhältnis Train MSE zu Validation MSE:
      Validation ≈ Train → gute Generalisierung
      Validation deutlich größer → Überfitting
      Validation kleiner → Validierungsdaten sind einfacher oder Split begünstigt

Validation Bit_Fail → Anzahl der Ausreißer

MAE (Mean Absolute Error) → mittlere absolute Abweichung in Wh. Richtwerte bei typischem Verbrauch 500–1500 Wh:
   < 100 Wh → sehr gut
   100–300 Wh → gut
   > 300 Wh → schwach

MedAE (Median Absolute Error) → Median der absoluten Fehler in Wh (toleriert einzelne Ausreißer besser)
   < 100 Wh → sehr gut
   100–200 Wh → gut
   200–300 Wh → mittelmäßig
   > 300 Wh → schwach

RMSE (Root Mean Squared Error) → mittlere quadratische Abweichung in Wh
   Interpretation: wie groß Fehler im Mittel sind, mit Betonung auf Ausreißer
   Richtwerte:
   < 0.01 → sehr gut
   0.01–0.03 → gut
   0.03–0.05 → mittelmäßig / akzeptabel
   > 0.05 → schwach

MAPE (Mean Absolute Percentage Error) → relative Abweichung in %
   Richtwerte:
   < 10 % → sehr gut - Modell liegt fast immer sehr nah an den echten Werten
   10–20 % → gut - Prognosen sind solide, kleine Abweichungen sind normal
   20–30 % → mittelmäßig / akzeptabel - Modell ist brauchbar, aber nicht präzise – für grobe Trends ok
   > 30 % → schwach - Modell verfehlt die Werte deutlich, oft durch Ausreißer oder fehlende Features
   ⚠️ Vorsicht: bei kleinen Werten (<200 Wh) kann MAPE stark verzerren → MdAPE heranziehen

MdAPE (Median Absolute Percentage Error) → Median der prozentualen Fehler in % (robuster gegenüber kleinen Werten)
   Richtwerte:
   < 10 % → sehr gut
   10–20 % → gut
   20–30 % → mittelmäßig
   > 30 % → schwach

R² (Bestimmtheitsmaß) → Maß für die Erklärungskraft des Modells. Je näher R² an 1 liegt, desto besser.
   R² = 1.0 → perfekte Vorhersage, alle Punkte liegen exakt auf der Regressionslinie
   R² > 0.8 → sehr gut - Modell erfasst den Großteil der Streuung → sehr zuverlässige Prognosen
   R² = 0.6 – 0.8 → gut - Modell erklärt einen soliden Teil der Varianz → brauchbar für viele Anwendungen
   R² = 0.5–0.6 → mäßig / grenzwertig - Modell liegt knapp über ,,zufällig" → Muster erkannt, Prognosen nur eingeschränkt nützlich
   R² < 0.5 → schwach - Modell erklärt weniger als die Hälfte der Varianz → deutlicher Verbesserungsbedarf
   R² = 0.0 → Modell erklärt gar nichts, es ist nicht besser als der Mittelwert der Daten
   R² < 0.0 → Modell ist schlechter als einfach immer den Mittelwert vorherzusagen
   ⚠️ R² ist sehr empfindlich gegenüber Ausreißern und Varianz in den Daten.

                                                                                                                                           



[DS_Starter]

Hallo 300P,

welcome back 

Gehe ich (z.Z. noch) recht in der Annahme das:
Code Auswählen
- aiConHiddenLayers=80‑40‑20
- aiConTrainStart=3:1
- aiConActFunc=GAUSSIAN

noch nicht als Parameter eintragbar und als Parameter mit dieser u.s. aktuellen Version 2.0.0 im Contrib vom 10,12,2025 noch nicht genutzt werden kann?

Absolut. Den Artikel habe ich vorbereitend geschrieben (...in Entwicklung).
Die Version im contrib ist noch die du bereits hast mit der initialen FANN-Logik.
Jetzt ist die Entwicklung bereits viel weiter, aber noch nicht im contrib weil ich noch ein paar Problemchen lösen muß.

Sobald es soweit ist, update ich das contrib und gebe auch Bescheid dass es upgedated wurde.

LG,
Heiko

[Wolle02]

Moin Heiko, ich hadere hier immer noch etwas mit dem Batteriemanagement, weil ich es einfach nicht schaffe, dass die Batterie innerhalb des Carecycle Zeitraumes mal meinen maxSoC-Wert erreicht. Ich habe in ctrlBatSocManagement01 folgendes eingestellt:

Code Auswählen Erweitern

lowSoc=10 upSoC=60 maxSoC=100 careCycle=14 loadAbort=95:500 loadStrategy=smartPower
Heute stand der Wert des Readings "special_daysUntilBatteryCare_01" auf 2 und der OTP bei 95 (auch wenn er unerklärlicher Weise jeden Tag um 00:00 Uhr wieder auf upSoC reduziert wird und erst nach Beendigung des Sonnentages erneut hochgezählt wird).

Nach Beendigung des Sonnentages wurde der Wert von special_daysUntilBatteryCare_01 auf 1 reduziert. Eigentlich hatte ich angenommen, dass ich somit noch einen Tag Zeit habe bis BatteryCare greift und die Batterie mittels Zwangsladung auf maxSoC geladen wird. Mit erreichen des special_daysUntilBatteryCare_01 auf den Wert 1 wurde allerdings sofort Battery_ChargeRequest_01 auf 1 gesetzt und die Zwangsladung der Batterie mit 1000 W gestartet.

Soweit so gut (auch wenn ich eigentlich erwartet hätte, dass das Ganze erst bei special_daysUntilBatteryCare_01=0 passiert; aber nun gut).
Die Zwangsladung wurde nun aber leider nicht bis SoC=100 durchgeführt, sondern bei erreichen von SoC=95 abgebrochen. Der OTP wurde gleichzeitig wieder auf upSoC gestellt und special_daysUntilBatteryCare_01=13 gesetzt.

Dieses Verhalten wäre für mich erklärlich, wenn maxSoC erreicht worden wäre; aber das wurde es nicht.

Der SoC von 95 stellt den Default-Wert von maxSoC dar.

Somit stellen sich mir gerade folgende Fragen:

1. Warum startet der Battery CareCycle bei special_daysUntilBatteryCare_01=1 und nicht bei =0 ?
2. Kann es sein, dass ein Bug im Code einen individuellen maxSoC nicht richtig übernimmt und deshalb immer den Default-Wert von 95 übernimmt?
3. Kann es sein, dass hier bei 95% die LoadAbort Richtlinie greift, obwohl die Zwangsladung mit 1000 W durchgeführt wird und diese währenddessen nicht unter die eingestellte Grenze von 500 W fällt?

Danke und Gruß
Wolle

[DS_Starter]

Hallo Wolle,

ich hatte im SoC-Management noch einen Fehler korriegiert, schau mal in den Beitrag #4634.
Leider kann ich die Version noch nicht einchecken weil ich mit der Verbrauchsvorhersage noch nicht soweit bin.
Aber die Version 2.0.0 im contrib hat diesen Fix im Bauch und man kann sie ohne weiteres laden und benutzen.

Soweit so gut (auch wenn ich eigentlich erwartet hätte, dass das Ganze erst bei special_daysUntilBatteryCare_01=0 passiert; aber nun gut).
Die Zwangsladung wurde nun aber leider nicht bis SoC=100 durchgeführt, sondern bei erreichen von SoC=95 abgebrochen. Der OTP wurde gleichzeitig wieder auf upSoC gestellt und special_daysUntilBatteryCare_01=13 gesetzt.

Du hast eine Abbruchbedingung loadAbort=95:500 definiert. Wenn diese Bedingung zutrifft, wird signalisiert die Ladung zu beenden. Die Einstellung maxSoC=100 und loadAbort=95:500 konkurrieren und wenn die 500W Ladeleistung unterschritten werden, greift diese Vorgabe. Wenn die Batterie aus Gründen der pfelglichen Behandlung generell nur bis 95% geladen werden soll -> maxSoC=95 einstellen, dann wird optimal SoC auch bezogen auf careCycle mit Ziel 95% berechnet.
BTW: OTP ist die Ladestromsteuerung, hier geht es aber um optimal SoC (OptimumTargetSoC).

1. Warum startet der Battery CareCycle bei special_daysUntilBatteryCare_01=1 und nicht bei =0 ?

Das ist eine falsche Sichtweise. Er startet bei CareCycle=x und endet mit 0. Wann 0 erreicht wird, hängt von dem berechneten Zeitpunkt pvCircular->nextTsMaxSocChge ab.

2. Kann es sein, dass ein Bug im Code einen individuellen maxSoC nicht richtig übernimmt und deshalb immer den Default-Wert von 95 übernimmt?

Hier zieht der angegebene loadAbort.

3. Kann es sein, dass hier bei 95% die LoadAbort Richtlinie greift, obwohl die Zwangsladung mit 1000 W durchgeführt wird und diese währenddessen nicht unter die eingestellte Grenze von 500 W fällt?

Sie greift, aber die Begründung ist so nicht richtig. Wir können nicht bestimmen d.h. vorgeben!, dass die Batterie mit 1000W geladen wird. Vielmehr begrenzen wir durch entsprechende Einstellungen die max. Ladeleistung auf 1000W. Ob die Batterie wirklich mit 1000W geladen wird, bestimmt das BMS der Batterie entsprechend der Ladephasen (z.B. Bulkladung).

Zum Beispiel kann man der Victron Doku entnehmen:

Konstantstrom
Sobald die Bulkphase abgeschlossen ist, ist die Batterie zu etwa 80 % geladen (bzw. >95 % bei Li-Ionen-Batterien) und kann bei Bedarf wieder in Betrieb genommen werden.
...
...
Konstantspannung
Die Batterie wird mit der konfigurierten Absorptionsspannung geladen, wobei der Ladestrom langsam abnimmt, wenn sich die Batterie der vollen Ladung nähert.
Die Dauer der standardmäßigen Konstantspannungsphase ist angepasst und wird je nach Entladungsgrad der Batterie intelligent variiert (wird aus der Dauer der Konstantstromphase ermittelt).

Die Informationen zu deinem Batteriesystem können natürlich abweichend sein.

Die reale Ladeleistung kann also durchaus auf unter 500W fallen und somit deine Bedingung greifen.

LG,
Heiko

[Wolle02]

ich hatte im SoC-Management noch einen Fehler korriegiert, schau mal in den Beitrag #4634.
Leider kann ich die Version noch nicht einchecken weil ich mit der Verbrauchsvorhersage noch nicht soweit bin.
Aber die Version 2.0.0 im contrib hat diesen Fix im Bauch und man kann sie ohne weiteres laden und benutzen.

OK, ich probiere diese Version mal aus.

1. Warum startet der Battery CareCycle bei special_daysUntilBatteryCare_01=1 und nicht bei =0 ?

Das ist eine falsche Sichtweise. Er startet bei CareCycle=x und endet mit 0. Wann 0 erreicht wird, hängt von dem berechneten Zeitpunkt pvCircular->nextTsMaxSocChge ab.

Nein, er endet eben nicht bei 0, sondern bei 1

2. Kann es sein, dass ein Bug im Code einen individuellen maxSoC nicht richtig übernimmt und deshalb immer den Default-Wert von 95 übernimmt?

Hier zieht der angegebene loadAbort.

Ja, das probiere ich aus und lösche die LoadAbort-Richtlinie. Allerdings stimmt dann scheinbar mit dieser etwas nicht; siehe unten.

3. Kann es sein, dass hier bei 95% die LoadAbort Richtlinie greift, obwohl die Zwangsladung mit 1000 W durchgeführt wird und diese währenddessen nicht unter die eingestellte Grenze von 500 W fällt?

Sie greift, aber die Begründung ist so nicht richtig. Wir können nicht bestimmen d.h. vorgeben!, dass die Batterie mit 1000W geladen wird. Vielmehr begrenzen wir durch entsprechende Einstellungen die max. Ladeleistung auf 1000W. Ob die Batterie wirklich mit 1000W geladen wird, bestimmt das BMS der Batterie entsprechend der Ladephasen (z.B. Bulkladung).
...
Die reale Ladeleistung kann also durchaus auf unter 500W fallen und somit deine Bedingung greifen.

Doch ich kann vorgeben, dass die Batterie mit 1000 W geladen werden soll; und das tut sie auch durchgehend bis eben bei 95% die Ladung abbricht. Siehe Bild.
Das dürfte sie aber laut der loadAbort-Richtlinie nicht, weil die Ladeleistung nicht unter die angegebenen 500 W fällt

LG
Wolle

[Parallix]

Clarification Request: In Wiki und Online-Beschreibung fehlt eine Beschreibung, wie die optional bei loadTarget angebbare "Zielzeit" zu interpretieren ist.

[grappa24]

OT: Ihr macht mir vlt. Spaß 
Wollte gerade zur Vorbereitung auf die V2.0.0 die libfann Pakete installieren: Mein buster wäre dafür zu alt
Gut, auf bullseye upgedatet - und nix geht mehr / bootet mehr 
Zum Glück hab ich eine wöchentliche Update-Routine für meine RasPi SD-Karten 
... und man hat ja "zwischen den Jahren" eh nix zu tun.
Viele Grüße aus dem (endlich) sonnigen Frankfurt.
Dieter

[Parallix]

... special_daysUntilBatteryCare_XX ...

Das ist eine falsche Sichtweise. Er startet bei CareCycle=x und endet mit 0. Wann 0 erreicht wird, hängt von dem berechneten Zeitpunkt pvCircular->nextTsMaxSocChge ab.

Wenn er bei 0 endet, dann lassen sich Fälle, bei denen es nicht zur "Wartung" gekommen ist, nicht gut erfassen.

Vorschlag: Solange täglich special_daysUntilBatteryCare_XX dekrementieren, bis es zur "Wartung" gekommen ist. Dann kann jeder auf Basis der so ausgewiesenen "Fristüberschreitung" entscheiden, ob ggf. unter Netzbezug eine "Wartung" angegangen wird.

PS: daysUntilBatteryCare ist eigentlich daysTillScheduledTopLevelBatteryCalibration oder abgekürzt  daysTillSchedTopLvlBatCal.