76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[peterboeckmann]

Hallo Heiko,

Du kannst diese Dinge auch hier posten und ich kann dann auch eine Analyse laufen lassen. Das meiste steht ja schon da, nur das Log des Traings fehlt

vielen Dank für das freundliche Angebot.

Log und Screenshot habe ich als Dateien angehängt.

Den Copilot habe ich dann gefragt:

Code Auswählen Erweitern

Ich benutze das FHEM Modul SolarForecast mit AI::FANN zur Prognose meines Energieverbrauchs.
  Die erreichten Kennwerte erscheinen sehr gut zu sein, das Ergebnis der Prognose ist jedoch unrealistisch hoch, insbesondere in den Nachtstunden.
  Anbei ist das Trainingslog, die erreichten Kennwerte und die Visualisierung. Ich möchte eine Bewertung und Vorschläge zur Verbesserung.

nformationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 07.03.2026 09:48:46 / Laufzeit in Sekunden: 1558
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 20.76 ms
Verbrauchernummer Wärmepumpe: -

=== Modellparameter ===

Normierungsgrenzen: PV=11440 Wh, Hausverbrauch: Min=0 Wh / Max=15960 Wh
Trainingsdaten: 7726 Datensätze (Training=6180, Validation=1546)
Architektur: Inputs=69, Hidden Layers=80-40-20, 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: 2785 (max. 15000)
Training MSE: 0.000304
Validation MSE: 0.000849
Validation MSE Average: 0.000778
Validation MSE Standard Deviation: 0.000042
Validation Bit_Fail: 0
Model Bias: 286 Wh
Model Slope: 0.9
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 279.25 Wh
MedAE: 81.72 Wh
RMSE: 338.42 Wh
RMSE relative: 48 %
RMSE Rating: acceptable
MAPE: 35.83 %
MdAPE: 11.24 %
R²: 0.84

=== 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: -
und er hat geantwortet:

Code Auswählen Erweitern

Die Kernaussage vorweg: **Dein Modell trainiert hervorragend, aber es generalisiert in der Nacht massiv falsch**, weil die Eingangsmerkmale und die Normalisierung nicht zu den realen Verbrauchsdynamiken in der Nacht passen. Die Trainingsmetriken sehen gut aus, aber das Modell produziert systematische Fehlvorhersagen – ein klassisches Beispiel für *metrisch gutes, praktisch schlechtes* Verhalten.

Damit du klar siehst, woher das kommt und was du konkret verbessern kannst, gehe ich strukturiert vor.

---

## 🔍 Was im Log und in den Kennzahlen auffällt

### 1) **Die Trainingsmetriken sind gut – aber nicht stabil**
Aus dem Log (z. B. *,,Train MSE=0.000304, Val MSE=0.000849"* und *,,R²=0.84"*) sieht man, dass das Modell sauber konvergiert. 
Aber gleichzeitig:

- **VAL/TRAIN MSE Ratio = 2.79 (Limit 2.5)** 
- **Retrain-Entscheidung = Retrain** 
- **Rauschen = borderline** 
- **Model Bias ≈ +285 Wh** 
- **Slope ≈ 0.90** 

Das bedeutet: 
Das Modell ist *leicht unterfit* und *leicht verzerrt*, aber nicht katastrophal. 
Die Nachtfehler kommen also nicht von schlechtem Training, sondern von **systematischer Fehleinschätzung bestimmter Situationen**.

---

## 🌙 Warum die Nachtwerte völlig unrealistisch hoch sind

### 1) **Die Normalisierung ist extrem breit**
Aus dem Log:

> *,,Normierungsgrenzen: Hausverbrauch Min=0 / Max=15960 Wh"*

Dein echter Nachtverbrauch liegt vermutlich bei **100–400 W**, aber das Modell rechnet im Bereich **0–15960**. 
Das führt dazu, dass kleine reale Unterschiede in der Nacht im Normalisierungsraum praktisch verschwinden.

### 2) **Die Eingangsmerkmale sind stark PV-lastig**
Die Features im Log zeigen:

- `lag1`, `lag24`, `hppf`, `tmp*`, `rollstd`, `up/down`, `pvX` 
- Viele davon hängen direkt oder indirekt mit PV-Erzeugung zusammen.

In der Nacht sind diese Features:

- konstant 
- verrauscht 
- nicht informativ 

Das Modell hat also **keine echten Signale**, um den Nachtverbrauch zu unterscheiden. 
Es extrapoliert dann aus Tagesmustern → und landet bei absurden Werten.

### 3) **Die Trainingsdaten haben 1553 Lücken**
Zitat:

> *,,1553 Records skipped due to incomplete or invalid data"*

Das ist **20 % der Daten**. 
Wenn diese Lücken ungleichmäßig verteilt sind (z. B. nachts häufiger), entsteht ein Bias.

### 4) **Der Bias von +285 Wh wirkt nachts besonders stark**
Ein Bias von +285 Wh ist tagsüber unkritisch. 
Aber nachts, wo der reale Verbrauch vielleicht 200 Wh ist, bedeutet das:

- 200 Wh + 285 Wh = 485 Wh 
- nach Rücktransformation und Slope ≈ 0.9 → noch höher 
- plus Ausreißerbehandlung → noch höher 

Das erklärt die extremen Nachtwerte.

---

## 📊 Warum die Visualisierung so extrem aussieht

Die Grafik zeigt:

- ab 22:00 Uhr steigen die Werte massiv 
- bis 00:00 Uhr auf über 11 kWh 
- danach langsam fallend

Das ist ein typisches Muster, wenn:

- das Modell **keine Nachtmerkmale** hat 
- die Normalisierung **zu breit** ist 
- der Bias **positiv** ist 
- die PV-Features **irrelevant** sind 
- die Historie **nicht genug Nachtvariation** enthält

---

## 🛠� Konkrete Verbesserungen (praxisnah für FHEM / SolarForecast)

### 1) **Normalisierung enger setzen**
Statt:

- Max = 15960 Wh

Besser:

- Max = 6000–8000 Wh (realistische Spitzen)
- oder automatische p99-Normalisierung aktivieren

Das verbessert die Auflösung im unteren Bereich massiv.

---

### 2) **Nacht-spezifische Features hinzufügen**
Aktuell fehlen:

- Wochentag
- Uhrzeit (sin/cos)
- Feiertag
- Temperatur (falls WP)
- Haushaltslasten (falls verfügbar)
- Rolling mean der letzten 7 Nächte
- Rolling min/max der letzten 24h

Ohne diese kann das Modell Nachtverhalten nicht lernen.

---

### 3) **PV-Features nachts deaktivieren oder maskieren**
PV-Features sind nachts reines Rauschen. 
SolarForecast kann PV-Inputs nachts auf 0 setzen – das solltest du aktivieren.

---

### 4) **BitFail-Limit leicht senken**
Empfehlung im Log:

> *,,Empfehlung für Bit_Fail: 0.34"*

Aktuell: 0.35 
→ Setze auf **0.30–0.32**

Das zwingt das Modell zu stabileren Vorhersagen.

---

### 5) **Datenqualität verbessern**
1553 fehlende Datensätze sind zu viel. 
Prüfe:

- ob nachts häufiger Lücken sind 
- ob bestimmte Sensoren ausfallen 
- ob PV-Daten nachts fehlerhaft sind 
- ob Hausverbrauch nachts auf 0 springt (Fehler!)

---

### 6) **Modellarchitektur vereinfachen**
80–40–20 Neuronen sind für 7726 Datensätze sehr groß. 
Das führt zu:

- Overfitting 
- Instabilität 
- Nacht-Extrapolationen 

Empfehlung:

- 40–20–10 
oder 
- 30–15–5

---

### 7) **Trainingsdaten splitten: Sommer/Winter getrennt**
Nachtverbrauch im Sommer ≠ Nachtverbrauch im Winter. 
SolarForecast unterstützt saisonale Modelle → aktivieren.

---

## 🧭 Zusammenfassung

**Das Modell ist gut trainiert, aber die Eingangsmerkmale und die Normalisierung sind nicht geeignet, um Nachtverbrauch korrekt vorherzusagen.** 
Die extremen Nachtwerte entstehen durch:

- zu breite Normalisierung 
- fehlende Nacht-Features 
- PV-lastige Inputs 
- Bias + Slope 
- Datenlücken 
- zu große Modellarchitektur 

Mit den oben genannten Maßnahmen bekommst du realistische Nachtwerte.

---

Wenn du möchtest, kann ich dir im nächsten Schritt **eine konkrete, optimierte SolarForecast-Konfiguration** vorschlagen, basierend auf deinen Daten und deinem Setup.
Ich lese da drei Maßnahmen für mich heraus:
- aiConHiddenLayers=40–20–10
- aiConBitFailLimit=0.32
- aiConProfile=v1_common_active

Verstehe ich das richtig?

Edit:
@300P,

Es dauert halt manchmal etwas ehe man sieht wie das ,,System" regariert.

Auch Dir vielen Dank für Deinen Rat. Ich versuche es erstmal mit dem LLM, wie Heiko empfohlen hat.

Vielen Dank und viele Grüße,
Peter

[Parallix]

...

@Heiko: Hast Du denn auch die bislang doch korrekt funktionierende Skalierung angepackt?

Nicht explizit. Die diskreten Rundungen sind in zentrale Rundungsfunktionen überführt.
Was genau meinst du bzgl. der Skalierung?
Dann schaue ich an der Stelle nochmal nach ob bei der Umstellung etwas übersehen wurde.

Wenn Du Dir die von mir eingestellte Grafik anschaust, dann siehst Du in den Bins prognostizierte Verbrauchswerte von 0 kWh. 0,1 kWh, 4,2 kWh und 8.4 kWh. Alle führen zu gleich hohen Balken. Das war früher nicht so. Achtung: Dieser Fehler taucht nur sporadisch auf!

[peterboeckmann]

Wenn Du Dir die von mir eingestellte Grafik anschaust, dann siehst Du in den Bins prognostizierte Verbrauchswerte von 0 kWh. 0,1 kWh, 4,2 kWh und 8.4 kWh. Alle führen zu gleich hohen Balken. Das war früher nicht so. Achtung: Dieser Fehler taucht nur sporadisch auf!

Eine gewisse Mindesthöhe der Balken scheint durch die Beschriftung vorgegeben zu sein.
Edit: Ich meine, das war schon immer so.

@Heiko: was hältst du davon, die Beschriftung des niedrigeren Balkens unter den Balken zu schreiben und die des höheren Balkens über den Balken?
Dadurch sollten die Balkenhöhen genauer den jeweiligen Wert darstellen, oder?

Viele Grüße,
Peter