76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[peterboeckmann]

Hallo Heiko,

der Stundenwechsel um 12 Uhr hat jedenfalls geklappt.

Viele Grüße,
Peter

[Wolle02]

Jetzt kommt mit der V2.2.3 beim Stundenwechsel keine Kommastelle mehr.

[marboj]

Code Auswählen Erweitern

setupInverterDev01
OpenDTU_2370752 pvOut=power:W capacity=800 etotal=yieldtotal:kWh strings=Ost,West
setupInverterDev02
OpenDTU_2370752 pvOut=power:W capacity=800 etotal=yieldtotal:kWh strings=SüdGarage,SüdGarten feed=bat

Habe jetzt einen 2. Inverter angelegt und die Strings zugeordnet. Jetzt wird aber der doppelte Ertrag angezeigt, obwohl die Strings zugeordnet sind...

Gruß
Marco

[DS_Starter]

So, bei PV Forecast sollte bei dir/euch auch keine Nachkommstelle mehr erscheinen --> contrib.

[DS_Starter]

Habe jetzt einen 2. Inverter angelegt und die Strings zugeordnet. Jetzt wird aber der doppelte Ertrag angezeigt, obwohl die Strings zugeordnet sind...

Der doppelte Ertrag wovon?

Ansonsten muß Debug bemüht werden --> ctrlDebug=collectData,radiationProcess

[peterboeckmann]

Hallo Heiko,

So, bei PV Forecast sollte bei dir/euch auch keine Nachkommstelle mehr erscheinen --> contrib.

ja, das passt jetzt wieder.

Danke und Viele Grüße,
Peter

[marboj]

Hallo Heiko,

die Infos waren vielleicht zu düftig:

Stand vor der Batterie war, dass 4 Panele am WR waren und der einen Gesamtoutput der 4 Module angezeigt hat.

Jetzt ist es so, dass die Batterie an 2 Panelen hängt und der Ausgang der Batterie an den Eingängen 1 und 2 des WR, die Eingänge 3 + 4 des WR haben noch die Panele.

Die Batterie schaltet den Ertrag der Panele durch an den WR, wenn diese voll ist.

Wie bekomme ich das sinnvoll dargestellt.

Mein erster Ansatz, der bei Überschusseinspeisung funktiniert, dass ich einen zweiten Inverter angelegt habe (mit feed=bat) und dem die Summe der Panele 1+2 als Ertrag zuordne.

Somit ist die Anzeige bei Überschusseinspeisung richtig.

Wenn aber der Speicher Strom an 1+2 abgibt, würde das ja auch als Solarertrag angezeigt.

Wie bekomme ich das am Besten angezeigt? Sowohl der Speicher als auch der WR sind als Geräte im FHEM vorhanden.

Gruß
Marco

[Shadow3561]

Ich muss leider noch einmal dazwischen grätschen. Sorry.
Ich habe bei mir die KI-Verbrauchsprognose aktiviert und bekomme viel zu hohe Verbräuche vorhergesagt.
Anscheinend bin ich zu dusselig um alles richtig interpretieren und die Einstellungen dementschend anzupassenpassen.

Code Auswählen Erweitern

aiConActivate=1 aiConAlpha=0.5  aiTrainStart=7 aiStorageDuration=3000 aiTreesPV=3 aiConHiddenLayers=50-25 aiConTrainStart=5:2 aiConProfile=v1_common_active_pv aiConBitFailLimit=0.50

Code Auswählen Erweitern

letztes KI-Training: 05.03.2026 12:46:28 / Laufzeit in Sekunden: 4759
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 20.38 ms
Verbrauchernummer Wärmepumpe:  -

=== Modellparameter ===

Normierungsgrenzen: PV=5797 Wh, Hausverbrauch: Min=0 Wh / Max=17670415 Wh
Trainingsdaten: 7225 Datensätze (Training=5780, Validation=1445)
Architektur: Inputs=69, Hidden Layers=50-25, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.5, BitFail-Limit=0.35
Aktivierungen: Hidden=SIGMOID, Steepness=0.9, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_common_active_pv
Zufallsgenerator: Mode=2, Period=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 9610 (max. 15000)
Training MSE: 0.000000
Validation MSE: 0.000001
Validation MSE Average: 0.000001
Validation MSE Standard Deviation: 0.000000
Validation Bit_Fail: 0
Model Bias: 553 Wh
Model Slope: 1.0
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 3954.92 Wh
MedAE: 1628.48 Wh
RMSE: 7879.64 Wh
RMSE relative: 2755 %
RMSE Rating: very bad
MAPE: 689.42 %
MdAPE: 450.91 %
R²: 1.00

=== Rauschen ===

Rauschen Bewertung: noisy
Empfehlung für Bit_Fail: 0.4 (Einstellung von aiControl->aiConBitFailLimit)

=== Drift-Kennzahlen ===

Drift Score: -
Drift RMSE ratio: -
Drift Slope: -
Drift Bias: -
Drift Bewertung: -


[peterboeckmann]

Da klinke ich mich doch bei Shadow3561 mal mit ein.
Auch bei mir ist die Verbrauchsprognose deutlich zu hoch, wenn auch nicht ganz so extrem.
Auch ich tue mich schwer damit, die richtige Konfiguration des NN zu finden.

Du darfst diesen Dateianhang nicht ansehen.

Code Auswählen Erweitern

aiTrainStart=3
aiStorageDuration=18250
aiTreesPV=30
aiConActivate=1
aiConProfile=v1_common_active_pv
aiConBitFailLimit=0.28
aiConShuffleMode=1
aiConSteepness=1.0
aiConTrainStart=4:3


Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 02.03.2026 03:26:19 / Laufzeit in Sekunden: 378
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 15.83 ms
Verbrauchernummer Wärmepumpe: -

=== Modellparameter ===

Normierungsgrenzen: PV=11440 Wh, Hausverbrauch: Min=0 Wh / Max=15960 Wh
Trainingsdaten: 7600 Datensätze (Training=6080, Validation=1520)
Architektur: Inputs=69, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.5, BitFail-Limit=0.28
Aktivierungen: Hidden=SIGMOID, Steepness=1.0, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_common_active_pv
Zufallsgenerator: Mode=1, Period=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 924 (max. 15000)
Training MSE: 0.000345
Validation MSE: 0.000549
Validation MSE Average: 0.000529
Validation MSE Standard Deviation: 0.000060
Validation Bit_Fail: 0
Model Bias: 186 Wh
Model Slope: 0.9
Trainingsbewertung: ok

=== Fehlermaße der Prognosen ===

MAE: 213.99 Wh
MedAE: 75.26 Wh
RMSE: 263.39 Wh
RMSE relative: 38 %
RMSE Rating: good
MAPE: 26.18 %
MdAPE: 10.57 %
R²: 0.90

=== Rauschen ===

Rauschen Bewertung: borderline
Empfehlung für Bit_Fail: 0.34 (Einstellung von aiControl->aiConBitFailLimit)

=== Drift-Kennzahlen ===

Drift Score: -
Drift RMSE ratio: -
Drift Slope: -
Drift Bias: -
Drift Bewertung: -



Erläuterungen zu den Kennzahlen

Model Bias → zeigt, ob das Modell den Verbrauch im Durchschnitt zu niedrig oder zu hoch vorhersagt:
   Positiver Bias → das Modell unterschätzt den Verbrauch im Mittel
   Negativer Bias → das Modell überschätzt den Verbrauch im Mittel
   Interpretation:
      Der Wert wird in Wh angegeben und beschreibt die durchschnittliche Abweichung pro Stunde.
      Die interne Bias‑Korrektur hebt oder senkt die Vorhersage entsprechend, jedoch nur
      im Bereich der Grundlast, um Peaks nicht zu verfälschen.

Model Slope → zeigt, ob das Modell zu flach oder zu steil reagiert.
   Der Wert beschreibt das Verhältnis zwischen:
      - Änderung im echten Verbrauch
      - Änderung in der Modellvorhersage
   und wird als dimensionsloser Faktor angegeben.
   Interpretation:
      Slope = 1.0 → Das Modell bildet die Verbrauchshöhen korrekt ab. Steigt der echte Verbrauch um X, steigt die Vorhersage ebenfalls um X
      Slope < 1.0 → Das Modell reagiert zu flach. Peaks werden abgeschwächt. Beispiel: Slope = 0.9 → Das Modell bildet 90% der realen Dynamik ab.
      Slope > 1.0 → Das Modell reagiert zu stark. Peaks werden überbetont, Schwankungen überzeichnet.

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 rel (Root Mean Squared Error) → der gewichtete RMSE misst die quadratische Abweichung von Prognose und Verbrauch in % - mit Gewichtung für hohe Lasten.
   Richtwerte:
   < 20% → ausgezeichnet, das Modell trifft sowohl Grundlast als auch Peaks sehr präzise
   20-40% → gut, das Modell ist zuverlässig und bildet typische Verbrauchsmuster sauber ab
   40-70% → akzeptabel, das Modell ist brauchbar, aber Peaks oder spontane Lasten werden nicht immer gut getroffen
   70-120% → schwach, das Modell hat deutliche Schwierigkeiten, insbesondere bei Lastspitzen oder unruhigen Haushalten
   > 120% → unbrauchbar, die Prognosen weichen stark vom realen Verbrauch ab

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.

Edit:
Von den Fehlermaßen her sieht das für mich nicht so aus, wie es die Grafik widerspiegelt.
Im Diagramm ist die Prognose für vergangene Stunden häufig doppelt so hoch wie der tatsächliche Verbrauch. Für zukünftige Stunden ist die Abweichung noch extremer.
/Edit.

Wie gehe ich am besten vor, um die Prognose zu verbessern?

Viele Grüße,
Peter

[TheTrumpeter]

Hab' grad einen Fehler in der Anzeige des "Rest-PV" Wertes in der Kopfzeile gefunden...

Der dort angezeigte Wert stimmt nicht mit der Summe der Balken-Werte überein, siehe Screenshot.
(Selbst wenn noch der ganze Wert von 16-18 Uhr verwendet würde und nicht nur anteilig ab 16:11 Uhr, ist es viel zu viel...)

[grappa24]

mit der 2.2.2 habe ich folgenden Effekt bei der PV Prognose:

[DS_Starter]

mit der 2.2.2 habe ich folgenden Effekt bei der PV Prognose:

Hatten wir weiter oben. Ist ein Rundungsfehler -> V2.2.3 im contrib beseitigt ihn.

[DS_Starter]

@Shadow3561, @peterboeckmann,

euch würde ich raten ein Training zunächst mit dem KI-Standardwerten auszuführen und dann erneut das Ergebnis zu bewerten.
Die Einstellung von aiConProfile könnt ihr beibehalten.

Bei Shadow3561 fällt mir der extrem hohen Wert Max=17670415 Wh auf. Das wäre ein mx. Stundenverbrauch vom 17 MWh.
Wenn ein KI-Training mit "set ... aiDecTree runConTrain" gestartet wird und Debug "aiProcess" aktiviert ist, bekommt man am Anfang die Ausreißer oberhalb des Percentils 99,5:

Code Auswählen Erweitern

2026.03.05 19:16:57.112 1: openMeteo DEBUG> AI FANN - Target-Norm: raw_max=28317, p99=3330, p99.5=12693, targmaxval=16501
2026.03.05 19:16:57.115 1: openMeteo DEBUG> AI FANN - True Outliers above p99.5 (12693): 28317

Hier ist es ein Wert -> 28317.

@Shadow3561, führe das Training mit den Default-Einstellungen durch und poste diese beiden Zeilen aus dem Log.

[DS_Starter]

Hallo Marco,

Jetzt ist es so, dass die Batterie an 2 Panelen hängt und der Ausgang der Batterie an den Eingängen 1 und 2 des WR, die Eingänge 3 + 4 des WR haben noch die Panele.

Die Batterie schaltet den Ertrag der Panele durch an den WR, wenn diese voll ist.
Wie bekomme ich das sinnvoll dargestellt.

Mein erster Ansatz, der bei Überschusseinspeisung funktiniert, dass ich einen zweiten Inverter angelegt habe (mit feed=bat) und dem die Summe der Panele 1+2 als Ertrag zuordne.
Somit ist die Anzeige bei Überschusseinspeisung richtig.
Wenn aber der Speicher Strom an 1+2 abgibt, würde das ja auch als Solarertrag angezeigt.

Wie bekomme ich das am Besten angezeigt?

Jetzt wird das Bild etwas klarer.
Du darfst jetzt die Ausgänge der Batterie nicht an die Eingänge 1 und 2 des WR1 anlegen, auch wenn es vllt. physikalisch momentan so richtig ist.
Du lässt am WR1 nur die beiden Strings an den Eingängen 3 + 4.

Die Batterie mit dem Solar-Lader und zwei Strings passt schon. Jetzt kannst du noch einen virtuellen Batteriewechselrichter anlegen.
Dann sieht dein Setup so aus wie mein Screenshot, nur dass es bei dir jeweils 2 Strings pro Inverter gibt.

Grüße,
Heiko

[DS_Starter]

Die V2.2.3 mit den heutigen Rundungskorrekturen habe ich soeben eingecheckt und wird morgen früh in der Auslieferung sein.