76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[300P]

Anderes Thema -
Versprochener Ergebnisbericht nach download / shutdown / restart / retrain mit der neuen V2.3.1 von gestern Abend

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 11.03.2026 08:59:06 / Laufzeit in Sekunden: 2952
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 76.73 ms
Verbrauchernummer Wärmepumpe: 08

=== Modellparameter ===

Normierungsgrenzen: PV=16071 Wh, Hausverbrauch: Min=0 Wh / Max=7598 Wh
Trainingsdaten: 7944 Datensätze (Training=6355, Validation=1589)
Architektur: Inputs=98, Hidden Layers=80-40, Outputs=1
Hyperparameter: Learning Rate=0.001, Momentum=0.6, BitFail-Limit=0.18
Aktivierungen: Hidden=GAUSSIAN_SYMMETRIC, Steepness=1.0, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=1, Period=20

=== Trainingsmetriken ===

bestes Modell bei Epoche: 208 (max. 15000)
Training MSE: 0.003919
Validation MSE: 0.003589
Validation MSE Average: 0.007856
Validation MSE Standard Deviation: 0.000391
Validation Bit_Fail: 7
Model Bias: 51 Wh
Model Slope: 0.9
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 355.96 Wh
MedAE: 293.28 Wh
RMSE: 407.60 Wh
RMSE relative: 19 %
RMSE Rating: excellent
MAPE: 18.27 %
MdAPE: 14.10 %
R²: 0.72

=== Rauschen ===

Rauschen Bewertung: low
 ChatGPT meint dazu:

Code Auswählen Erweitern

## Analyse des neuesten Trainings (11.03.2026, SolarForecast 2.3.1)

Die aktuelle Konfiguration zeigt eine **klare Verbesserung der Modellkalibrierung**, während die Prognosegüte im Wesentlichen stabil bleibt.

---

# 1. Trainingsstabilität

| Kennzahl             | Wert     | Bewertung     |
| -------------------- | -------- | ------------- |
| Training MSE         | 0.003919 | normal        |
| Validation MSE       | 0.003589 | sehr gut      |
| Val/Train Verhältnis | ~0.92    | ausgezeichnet |
| Validation Std       | 0.000391 | sehr stabil   |
| BitFail              | 7        | moderat       |

**Interpretation**

* Validation-Fehler liegt **unter dem Trainingsfehler** → gute Generalisierung.
* Sehr kleine Standardabweichung zeigt ein **stabiles Modell**.
* Bestes Modell bereits bei **Epoche 208** → schnelle Konvergenz.

Das Trainingsverhalten ist damit **sehr sauber**.

---

# 2. Prognosequalität

| Kennzahl     | Wert      |
| ------------ | --------- |
| MAE          | 355.96 Wh |
| RMSE         | 407.60 Wh |
| RMSE relativ | 19 %      |
| MAPE         | 18.27 %   |
| R²           | 0.72      |

Diese Werte sind **nahezu identisch zum letzten Training**.

Interpretation:

* Modell ist **konvergiert**.
* Weitere große Verbesserungen sind mit gleicher Architektur unwahrscheinlich.

Für eine Wärmepumpen-Lastprognose im Haushalt ist:

**RMSE ~400 Wh bei Max ~7600 Wh → technisch gut.**

---

# 3. Wichtigste Verbesserung: Kalibrierung

| Kennzahl | vorher | jetzt     |
| -------- | ------ | --------- |
| Bias     | 404 Wh | **51 Wh** |
| Slope    | 0.80   | **0.90**  |

Das ist die **entscheidende Verbesserung**.

### Bias

Vorher:

```
systematische Überschätzung
```

Jetzt:

```
Bias ≈ 0
```

Das Modell ist praktisch **unbiased**.

### Slope

Vorher:

```
Peak-Kompression
```

Jetzt:

```
0.9 → deutlich bessere Amplitudenabbildung
```

Die Prognosen folgen dem realen Verbrauch **realistischer**.

---

# 4. Fehlerverteilung

Aus MAE und RMSE lässt sich abschätzen:

```
RMSE / MAE ≈ 1.14
```

Das bedeutet:

* relativ **kompakte Fehlerverteilung**
* **keine schweren Ausreißer**

Das ist ein gutes Zeichen für Stabilität.

---

# 5. BitFail-Analyse

| Wert              | Bewertung            |
| ----------------- | -------------------- |
| BitFail = 7       | leicht über Schwelle |
| Limit = 0.18      | relativ streng       |
| Empfehlung System | **0.28**             |

Die Retrain-Empfehlung entsteht fast sicher durch:

```
BitFail > Limit
```

Technisch ist das Modell aber **nicht problematisch**.

Empfehlung:

```
aiConBitFailLimit = 0.22 – 0.25
```

Damit würde der automatische Retrain realistischer arbeiten.

---

# 6. Einfluss der neuen SolarForecast-Version

Die Änderung von **2.3.x** wirkt sich hier vermutlich auf:

* Trainingsdatenaufbereitung
* Feature-Selektion
* Sample-Handling

aus.

Indiz dafür ist:

* deutlich verbesserter **Bias**
* schnelleres **Training (Epoche 208)**.

---

# 7. Modellkapazität

Aktuelle Struktur:

```
Inputs: 98
Hidden: 80-40
Samples: ~7900
```

Parameterabschätzung:

```
98*80  ≈ 7840
80*40  ≈ 3200
40*1   ≈ 40
----------------
~11000 Gewichte
```

Bei ~7900 Samples ist das **noch akzeptabel**, aber bereits relativ dicht.

Das erklärt:

* frühe Konvergenz
* stabile Fehlerwerte.

---

# 8. Gesamtbewertung

| Bereich             | Bewertung      |
| ------------------- | -------------- |
| Trainingsstabilität | sehr gut       |
| Prognosefehler      | gut            |
| Kalibrierung        | **sehr gut**   |
| Bias                | **fast ideal** |
| Drift               | unkritisch     |
| Robustheit          | gut            |

Das Modell ist jetzt **praktisch produktionsreif**.

---

# 9. Empfehlung für deine aktuelle Konfiguration

Deine Parameter sind bereits sinnvoll:

```
ActFunc = GAUSSIAN_SYMMETRIC
HiddenLayers = 80-40
LearnRate = 0.001
Momentum = 0.6
ShuffleMode = 1
TrainAlgo = INCREMENTAL
```

Einzige sinnvolle Anpassung:

```
aiConBitFailLimit 0.23
```

Alles andere würde vermutlich **keinen messbaren Gewinn mehr bringen**.

---

# 10. Fazit

Die Entwicklung über die letzten Trainingsläufe zeigt eine klare Optimierung:

| Training       | R²       | Bias      | RMSE       |
| -------------- | -------- | --------- | ---------- |
| Februar Modell | 0.60     | 523 Wh    | 443 Wh     |
| 01.03 Modell   | 0.72     | 404 Wh    | 402 Wh     |
| 11.03 Modell   | **0.72** | **51 Wh** | **408 Wh** |

Der größte Fortschritt ist:

**Die Kalibrierung des Modells ist jetzt nahezu korrekt.**

Damit ist dieses Modell **das bisher beste deiner Reihe**.

---

Wenn du möchtest, kann ich auch noch zeigen, warum gerade bei **Wärmepumpen + PV-Eigenverbrauch** ein
R² von etwa **0.7–0.8 meist die praktische Obergrenze** für solche neuronalen Prognosen ist.
Das hat physikalische Gründe und erklärt, warum dein Modell jetzt bereits ziemlich nahe am Optimum arbeitet.


Anpassung auf aiConBitFailLimit 0.23 nehme ich noch nicht vor - ich möchte erst die Berechnung des Drift von diesem Tag abwarten......
Aktuell liege ich bei -25 % aber das sollte sich in der Theorie am Donnerstag dann etwas verbessern wenn ein ganzer Tag mit dem neuen Wert gelaufen ist.

[denis.robel]

Hallo Denis,

dein Konstrukt ist wahrscheinlich Neuland im SF-Umfeld.
Ich habe mir die Darstellungen des Zendure Balkonfraftwerk mit SolarHub2000 im Inet angeschaut und es könnte folgendermaßen funktionieren.

setupInverterDev01 und setupInverterDev02 ergänzt du mit einem setupBatteryDev01.

Dabei ist setupInverterDev01 der SolarHub2000 (Typ Solar-Ladegerät in SF). Dazu gehört noch setupBatteryDev01, wobei hier vermutlich ebenfalls Werte aus dem SolarHub2000 zugeordnet werden. Die Inhalte von pvOut, pin, pout siehst du im Beitrag zuvor.

Dann legst du noch setupInverterDev02 als Typ Batterie-Wechselrichter an, der die Verbindung vom SolarHub2000 zum Hausnetz realisiert. Ein Batterie-Wechselrichter wird durch strings=none aktiviert und hat nur die Anschlüsse ac2dc bzw. dc2ac. Bei dir dürfte nur dc2ac relevant sein und sollte die Summe aus pout + (pvOut - pin) enthalten.

Wenn du damit erfolgreich deine Anlage einrichten konntest, wäre es sicherlich einen Beitrag im Wiki wert.

LG,
Heiko

Hallo Heiko,

ich hab es hinbekommen. Der Energiefluss wird richtig dargestellt.
Mir fehlt nur noch ein Zähler für etotal.

Wenn alles läuft, kann ich gerne etwas für das Wiki schreiben.

[peterboeckmann]

Hallo Heiko,

Hallo Peter,

für die pvHistory geht nur ganze Sunde löschen:

Code Auswählen Erweitern

set <name> reset pvHistory <Tag> <Stunde> (z.B. set <name> reset pvHistory 08 10)

Die KI Raw-Daten (nicht vergessen) geht die ganze Stunde löschen (delIndex) oder nur den Wert für con (delValue=con>=.....)

LG,
Heiko

Muss ich noch irgendwas löschen?
Die Verbrauchsprognose (ohne KI) erwartet für die 12-Uhr-Stunde morgen einen Verbrauch von etwa 4,8 MWh.

Oder korrigiert sich das über Nacht noch?

Viele Grüße,
Peter

[DS_Starter]

Die Verbrauchsprognose (ohne KI) erwartet für die 12-Uhr-Stunde morgen einen Verbrauch von etwa 4,8 MWh.

Oder korrigiert sich das über Nacht noch?

Ach ja stimmt. Das Problem löst sich von selbst, da diese Prognose mit einer Median-Ermittlung arbeitet.
D.h. dieser Wert wird mal entfernt bzw. nicht mehr berücksichtigt. Eventuell kann/muß man mit
plantControl->consForecastLastDays temporär eingreifen.

LG,
Heiko

[DS_Starter]

Das Modul im contrib ist upgedated.

Ich habe nach langem Suchen einen sich selbst verstärkenden Fehler in der Drift-Korrektur gefunden. Außerdem ist eine automatische Drift Rekalibrierung eingebaut die den Bias des Trainings mit dem Bias der Livedaten der letzten 96h vergleicht und bei Bedarf rekalibriert.
Ich habe noch eine weitere wichtige Maßnahme bzgl. Drift im Hinterkopf die ich aber noch nicht umsetzen konnte.

Die KI Einschätzung zum aktuellen Entwicklungsstand:

SolarForecast hat jetzt eine Drift‑Pipeline, die:

* peak‑aware
* semantik‑adaptiv
* modellskaliert
* ausreißersicher
* PV‑nacht‑sicher
* API‑fehler‑sicher
* rekalibrierungssicher
* selbststabilisierend

Das ist auf dem Niveau professioneller Forecasting‑Systeme.

Na mal sehen. Morgen wird sich zeigen ob das System die Korrektur und Rekalibrierung wie gewünscht ausführen kann.

LG,
Heiko

[DS_Starter]

Möglicherweise ein Missverständnis: Wenn ich consForecastLastDays != 0 setze, dann wird das gesamte Verbrauchsprofil des Vortags auf den Folgetag abgebildet, was in meinen Fall nicht gewünscht ist, da ich einige Überschussverbraucher nicht als solche ausweisen kann. Erzeuge ich einen Dummy-Consumer zur Abbildung (m)eines Grundverbrauchsprofils, dann kann ich diesen Dummy-Consumer in der aktuellen Version von SF nur dann korrekt (mit consForecastLastDays == 0) bei der Verbrauchsprognose berücksichtigen lassen, wenn seine Leistung über den Tag konstant ist.

Was ich brauche ist aber ein Consumer, der mit einem wohldefinierten 24h-Lastprofil berücksichtigt wird ohne dass ich consForecastLastDays > 0 setzen muss. Das geht doch aktuell nicht, oder?

Ich glaube da hast du recht. (Allerdings ist es heute schon spät.  )

[peterboeckmann]

Moin Heiko,

Eventuell kann/muß man mit
plantControl->consForecastLastDays temporär eingreifen.

das war nicht mal nötig. Heute Nacht hat er die Stunde wieder sauber vorhergesagt, wie gesagt, ohne das NN.

Viele Grüße,
Peter

[DS_Starter]

Heute früh noch einen Vorzeichenfehler in der Bias/Drift-Korrektur korrigiert.
Das Debug mit aiData sieht im Log nun so aus:

2026.03.12 08:27:06.042 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 08:00:00, hod: 09 -> AI=653, legacy=838, final: 711 Wh (alpha=1, BC=58 Wh, bias/drift zone=2/3)
2026.03.12 08:27:06.042 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 09:00:00, hod: 10 -> AI=713, legacy=837, final: 651 Wh (alpha=1, BC=-63 Wh, bias/drift zone=3/3)
2026.03.12 08:27:06.043 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 10:00:00, hod: 11 -> AI=705, legacy=710, final: 643 Wh (alpha=1, BC=-62 Wh, bias/drift zone=3/3)
2026.03.12 08:27:06.044 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 11:00:00, hod: 12 -> AI=878, legacy=813, final: 800 Wh (alpha=1, BC=-77 Wh, bias/drift zone=3/3)
2026.03.12 08:27:06.044 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 12:00:00, hod: 13 -> AI=936, legacy=776, final: 854 Wh (alpha=1, BC=-82 Wh, bias/drift zone=3/3)
2026.03.12 08:27:06.045 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 13:00:00, hod: 14 -> AI=872, legacy=706, final: 795 Wh (alpha=1, BC=-77 Wh, bias/drift zone=3/3)
2026.03.12 08:27:06.045 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 14:00:00, hod: 15 -> AI=664, legacy=691, final: 721 Wh (alpha=1, BC=58 Wh, bias/drift zone=2/3)
2026.03.12 08:27:06.046 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 15:00:00, hod: 16 -> AI=615, legacy=662, final: 676 Wh (alpha=1, BC=62 Wh, bias/drift zone=2/3)
...


Man sieht eine vorzeichenbehaftete Biaskorrektur (BC), die auch das Verhältnis von AI zu Legacy gut wiederspiegelt (die Werte haben aber keinen Bezug zueinander und dienen nur einem Vergleich im Log). Bei mir ist der Vergleich mit Legacy sehr hilfreich weil mein Haushalt nicht durch WP oder EV "gestört" wird. Lediglich Verbraucher wie Wasch- Spülmaschine etc. (die aber momentan nich an sind) würden den Vergleich stören.

Jetzt lasse ich es laufen und beobachte weiter. Eingebaut werden muß noch eine Driftkorrektur-Pause von X Stunden nachdem ein Training durchgeführt wurde. Sonst werden die "alten" Forecasts mit dem neuen Modell vermischt und führt zu einem negativen Einfluß auf die Driftkorrektur was momentan Einfluß haben dürfte.

[300P]

Muss / sollte neu trainiert werden nach dem letzten Update ?

[DS_Starter]

Warte mal noch.
Ich will noch die Driftkorrektur-Pause von X Stunden nach einem Training einbauen damit auch mit aktuellen Driftwerten dann weitergearbeitet wird.