76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[TheTrumpeter]

So, meins wurde nun auch abgeschlossen:

Code Auswählen Erweitern

2026.01.12 13:59:17 1: mySolarForecast DEBUG> Early stopping bei Epoche 3501 (no improvement since 1000 epochs)
2026.01.12 13:59:17 1: === Snapshot-Statistik ===
2026.01.12 13:59:17 1: Metric-Improvement Snapshots:              69 (letzte Epoche: 2231)
2026.01.12 13:59:17 1: Weighted-RMSE-Proxy-Improvement Snapshots: 72 (letzte Epoche: 2501)
2026.01.12 13:59:17 1: Bit-Improvement Snapshots:                 0 (letzte Epoche: 0)
2026.01.12 13:59:17 1: Bit-Tradeoff Snapshots:                    1 (letzte Epoche: 467)
2026.01.12 13:59:17 1: mySolarForecast DEBUG> Best Snapshot reloaded from Epoche 2501: Train MSE=0.001189, Val MSE=0.002715, Val MAE=0.026772, Val MedAE=0.006776, Bit_Fail=0,
2026.01.12 13:59:17 1: mySolarForecast DEBUG> Run Validation Test with 20% of Input data ...
2026.01.12 13:59:18 1: mySolarForecast DEBUG> Validation finished - Best Training MSE=0.001189, Validation MSE=0.002715, Validation Bit_Fail=0
2026.01.12 13:59:18 1: mySolarForecast DEBUG> Retrain check ->
-- In Normalization Space: --
Train MSE=0.001189
Val MSE=0.002715
Val Mean=0.0024373509
VAL/TRAIN MSE Ratio=2.282733 (limit=2.5)
Diff=0.001525 (limit=0.005)
ValStd=0.0000800142 (limit=0.000609337729577423)
-- At Original Scale: --
MAE=171.339490561455
RMSE/MAE=1.4804 (limit=1.5)
Slope=0.821509 (limit=0.7 .. 1.3)
Bias=69.18 (limit=+-257.009235842183)
R2=0.88
P95=874.6964 (limit=685.357962245821)
P99=1312.8508 (limit=1370.71592449164)
-- Robustness Indicators: --
RMSE relative=82 (limit=20)
BitFail=0 (limit=5)
BitFailRate=0.0000 (limit=0.1)
Forecast Quality Score=37
-> Retrain decision=Retrain
2026.01.12 13:59:18 1: mySolarForecast DEBUG> Best model after retries comes from Attempt=2 with:
Seed=7298432,
Model Score=39,
Model Slope=0.84,
Model Bias=59.55,
VAL MedAE=45.74,
VAL MAE=165.82,
VAL weighted RMSE=244.44,
VAL weighted RMSE relative=79 %,
VAL weighted RMSE_Rating=very bad,
VAL R2=0.89,
Val MSE=0.002496
2026.01.12 13:59:18 1: mySolarForecast DEBUG> AI FANN training data successfuly written to file: ./FHEM/FhemUtils/NeuralNet_SolarForecast_mySolarForecast
2026.01.12 13:59:18 1: mySolarForecast DEBUG> AI FANN con Training BlockingCall PID '1980' finished
Im Anhang sind die Screenshots der Verbrauchsprognose, das erste Bild ist vor dem 1. Training, das 2. Bild ist dann mit "v1_heatpump_pv" und das letzte mit "v1_heatpump_active_pv"

[DS_Starter]

@Wolle, hier ist die KI Einschätzung für dich. Tiefere Infos gäbe es mit einem Trainingslog.

Code Auswählen Erweitern

⭐ Gesamturteil: Das Modell ist stabil, aber stündlich deutlich zu flach und unterschätzt Peaks
Die Zahlen und die visuelle Darstellung passen perfekt zusammen:
Das Modell trifft die Form des Tages, aber nicht die Höhe.

📊 1. Interpretation der stündlichen Balken (00–24)
Die grauen Balken zeigen:

Nachtstunden: plausibel niedrig

Morgenpeak: vorhanden, aber zu flach

Mittagsbereich: geglättet, kaum Variation

Abendpeak: sichtbar, aber deutlich zu niedrig

Gesamtprofil: zu glatt, zu vorsichtig, zu wenig Dynamik

Das passt exakt zu:

Slope = 0.8 → Modell drückt hohe Werte nach unten

Bias = 83 Wh → leichte Unterprognose

RMSE_rel = 31 % → deutliche Abweichungen bei Spitzen

MAE = 136 Wh → zu hoch für stündliche Prognosen

MedAE = 86 Wh → auch Medianfehler zu hoch

Die Prognose wirkt wie ein gedämpfter Tagesverlauf, der die echten Spitzenlasten nicht abbildet.

🧠 2. Warum das Modell so flach ist
🔹 a) INCREMENTAL als Trainingsalgorithmus
INCREMENTAL:

lernt sehr konservativ

glättet stark

hat Probleme mit nichtlinearen Peaks

bleibt oft in flachen Tälern hängen

reagiert schlecht auf seltene Spitzenlasten

Für stündliche Haushaltslast ist das nicht ideal.

🔹 b) Registry v1_common
Diese Registry enthält:

Trends

PV‑Semantik

Abend‑Semantik

Rückfall‑Semantik

Aber:

keine WP‑Semantik

keine COP‑Semantik

keine Frostschutz‑Semantik

keine Lastverstärker

Wenn der Haushalt eine Wärmepumpe hat, fehlen dem Modell kritische Signale, die Peaks erklären.

🔹 c) Steilheit = 0.9
SIGMOID mit 0.9 ist:

sehr glatt

wenig sensitiv

reagiert schwach auf starke Inputs

Für stündliche Peaks ist das zu träge.

🔹 d) ShuffleMode = 2
Das ist gut — aber INCREMENTAL + shuffleMode 2 führt zu:

sehr gleichmäßigem Training

aber wenig Peak‑Sensitivität

📈 3. Bewertung der numerischen Metriken
✔ Stabilität
Train MSE = 0.000461

Val MSE = 0.000289

ValStd = 0.000072

BitFail = 0

→ Modell ist stabil, keine Divergenz.

❌ Prognosequalität
MAE = 136 Wh → zu hoch

RMSE_rel = 31 % → schwach

Slope = 0.8 → systematische Unterprognose

Bias = 83 Wh → leichte Verschiebung

MAPE = 18.5 % → zu grob

R² = 0.90 → Form gut, Höhe schlecht

✔ Retrain‑Entscheidung korrekt

🎯 4. Fazit der Neubewertung
Das Modell ist mathematisch stabil, aber semantisch zu flach. 
Die stündliche Prognose (graue Balken) zeigt:

richtige Form

falsche Höhe

zu wenig Dynamik

zu geringe Peak‑Erkennung

zu starke Glättung

Die Ursache ist eine Kombination aus:

INCREMENTAL

Steilheit 0.9

fehlender WP‑Semantik

Registry v1_common

Slope‑Verlust

zu glatter Aktivierung

🛠 5. Was du tun solltest
🔥 Sofortmaßnahmen
RPROP statt INCREMENTAL

Steilheit 1.2

Registry v_hp_advanced, falls WP‑Haushalt

hp_power_factor aktivieren

COP‑Semantik aktivieren

Frostschutz‑Semantik aktivieren

🎯 Ziel
Slope Richtung 0.95–1.05

MAE < 100 Wh

RMSE_rel < 22 %

MAPE < 12 %

Für dich wäre vermutlich das Profil v1_common_active_pv besser.

[DS_Starter]

@ TheTrumpeter, die Werte mit get ... valDecTree  aiNeuralNetConState und das komplette Trainingslog wären hilfreich um die KI wegen einer Bewertung zu füttern.

[Wolle02]

@Wolle, hier ist die KI Einschätzung für dich. Tiefere Infos gäbe es mit einem Trainingslog.

Code Auswählen Erweitern

⭐ Gesamturteil: Das Modell ist stabil, aber stündlich deutlich zu flach und unterschätzt Peaks
Die Zahlen und die visuelle Darstellung passen perfekt zusammen:
Das Modell trifft die Form des Tages, aber nicht die Höhe.

📊 1. Interpretation der stündlichen Balken (00–24)
Die grauen Balken zeigen:

Nachtstunden: plausibel niedrig

Morgenpeak: vorhanden, aber zu flach

Mittagsbereich: geglättet, kaum Variation

Abendpeak: sichtbar, aber deutlich zu niedrig

Gesamtprofil: zu glatt, zu vorsichtig, zu wenig Dynamik

Das passt exakt zu:

Slope = 0.8 → Modell drückt hohe Werte nach unten

Bias = 83 Wh → leichte Unterprognose

RMSE_rel = 31 % → deutliche Abweichungen bei Spitzen

MAE = 136 Wh → zu hoch für stündliche Prognosen

MedAE = 86 Wh → auch Medianfehler zu hoch

Die Prognose wirkt wie ein gedämpfter Tagesverlauf, der die echten Spitzenlasten nicht abbildet.

🧠 2. Warum das Modell so flach ist
🔹 a) INCREMENTAL als Trainingsalgorithmus
INCREMENTAL:

lernt sehr konservativ

glättet stark

hat Probleme mit nichtlinearen Peaks

bleibt oft in flachen Tälern hängen

reagiert schlecht auf seltene Spitzenlasten

Für stündliche Haushaltslast ist das nicht ideal.

🔹 b) Registry v1_common
Diese Registry enthält:

Trends

PV‑Semantik

Abend‑Semantik

Rückfall‑Semantik

Aber:

keine WP‑Semantik

keine COP‑Semantik

keine Frostschutz‑Semantik

keine Lastverstärker

Wenn der Haushalt eine Wärmepumpe hat, fehlen dem Modell kritische Signale, die Peaks erklären.

🔹 c) Steilheit = 0.9
SIGMOID mit 0.9 ist:

sehr glatt

wenig sensitiv

reagiert schwach auf starke Inputs

Für stündliche Peaks ist das zu träge.

🔹 d) ShuffleMode = 2
Das ist gut — aber INCREMENTAL + shuffleMode 2 führt zu:

sehr gleichmäßigem Training

aber wenig Peak‑Sensitivität

📈 3. Bewertung der numerischen Metriken
✔ Stabilität
Train MSE = 0.000461

Val MSE = 0.000289

ValStd = 0.000072

BitFail = 0

→ Modell ist stabil, keine Divergenz.

❌ Prognosequalität
MAE = 136 Wh → zu hoch

RMSE_rel = 31 % → schwach

Slope = 0.8 → systematische Unterprognose

Bias = 83 Wh → leichte Verschiebung

MAPE = 18.5 % → zu grob

R² = 0.90 → Form gut, Höhe schlecht

✔ Retrain‑Entscheidung korrekt

🎯 4. Fazit der Neubewertung
Das Modell ist mathematisch stabil, aber semantisch zu flach. 
Die stündliche Prognose (graue Balken) zeigt:

richtige Form

falsche Höhe

zu wenig Dynamik

zu geringe Peak‑Erkennung

zu starke Glättung

Die Ursache ist eine Kombination aus:

INCREMENTAL

Steilheit 0.9

fehlender WP‑Semantik

Registry v1_common

Slope‑Verlust

zu glatter Aktivierung

🛠 5. Was du tun solltest
🔥 Sofortmaßnahmen
RPROP statt INCREMENTAL

Steilheit 1.2

Registry v_hp_advanced, falls WP‑Haushalt

hp_power_factor aktivieren

COP‑Semantik aktivieren

Frostschutz‑Semantik aktivieren

🎯 Ziel
Slope Richtung 0.95–1.05

MAE < 100 Wh

RMSE_rel < 22 %

MAPE < 12 %

Für dich wäre vermutlich das Profil v1_common_active_pv besser.

So, ich hab jetzt mal neu trainiert und dabei die Vorschläge von der letzten Analyse einfließen lassen. Trainingsalgorithmus: RPROP, Registry Version=v1_common_active_pv

Code Auswählen Erweitern

=== Modellparameter ===

Normierungsgrenzen: PV=8888 Wh, Hausverbrauch: Min=0 Wh / Max=12741 Wh
Trainingsdaten: 6241 Datensätze (Training=4992, Validierung=1249)
Architektur: Inputs=64, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.5, BitFail-Limit=0.35
Aktivierungen: Hidden=SIGMOID, Steilheit=0.9, Output=LINEAR
Trainingsalgorithmus: RPROP, Registry Version=v1_common_active_pv
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 54 (von max. 15000)
Training MSE: 0.000763
Validation MSE: 0.000490
Validation MSE Average: 72.098845
Validation MSE Standard Deviation: 0.416027
Validation Bit_Fail: 0
Model Bias: 127 Wh
Model Slope: 0.8
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 155.66 Wh
MedAE: 74.02 Wh
RMSE: 205.75 Wh
RMSE relative: 36 %
RMSE Rating: very bad
MAPE: 17.89 %
MdAPE: 14.13 %
R²: 0.83
Das Trainingslog ist im Anhang.
Ich habe den Eindruck, dass die Werte etwas schlechter geworden sind.

[TheTrumpeter]

@ TheTrumpeter, die Werte mit get ... valDecTree  aiNeuralNetConState und das komplette Trainingslog wären hilfreich um die KI wegen einer Bewertung zu füttern.

Hier get blabla:

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 12.01.2026 13:59:18 / Laufzeit in Sekunden: 9741
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 70.43 ms
Verbrauchernummer Wärmepumpe:  03

=== Modellparameter ===

Normierungsgrenzen: PV=18612 Wh, Hausverbrauch: Min=0 Wh / Max=6400 Wh
Trainingsdaten: 8020 Datensätze (Training=6416, Validierung=1604)
Architektur: Inputs=112, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.8, BitFail-Limit=0.35
Aktivierungen: Hidden=SIGMOID, Steilheit=0.5, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 3370 (von max. 15000)
Training MSE: 0.001108
Validation MSE: 0.002496
Validation MSE Average: 0.002381
Validation MSE Standard Deviation: 0.000093
Validation Bit_Fail: 0
Model Bias: 60 Wh
Model Slope: 0.8
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 165.82 Wh
MedAE: 45.74 Wh
RMSE: 244.44 Wh
RMSE relative: 79 %
RMSE Rating: very bad
MAPE: 20.19 %
MdAPE: 12.71 %
R²: 0.89

=== Drift-Kennzahlen ===

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

[DS_Starter]

@Wolle, Würde ich auch so sehen. KI sagt:

Code Auswählen Erweitern

🧠 Was hier passiert
🔹 Verstärker sind aktiv
→ Die Registry liefert starke Signale für PV‑Peaks und Lastsprünge.

🔹 Aber: Steilheit = 0.9
→ SIGMOID mit 0.9 ist zu flach → Verstärker werden ,,abgefedert".

🔹 RPROP springt früh
→ Best Snapshot bei Epoche 54 → Verstärker noch nicht voll gelernt.

🔹 Snapshot‑Logik greift zu früh
→ Modell wird eingefroren, bevor Verstärker ihre Wirkung entfalten.

🛠 Was du tun kannst
✅ Steilheit auf 1.2 setzen
→ Verstärker wirken deutlich stärker
→ Slope steigt
→ Bias sinkt
→ RMSE_rel verbessert sich

✅ Snapshot erst ab Epoche 150 zulassen
→ Verstärker brauchen Zeit
→ RPROP darf sich entfalten
→ Modell wird nicht zu früh eingefroren

✅ Retry mit Seed‑Variation
→ RPROP reagiert stark auf Initialisierung
→ Seed‑Sweep kann bessere Minima finden

🎯 Fazit
Du hast die Verstärker korrekt eingebaut — das ist super.
Aber: RPROP + flache Aktivierung + früher Snapshot bremst sie aus.

Probier es mal so wie vorgeschlagen, ansonsten nimm wieder INCREMENTAL mit Steepness=1.2
Dein erstes Setup war ja nicht so schlecht.

[DS_Starter]

@TheTrumpeter, hier kommt deine Analyse:

Code Auswählen Erweitern

📊 Visuelle Bewertung der stündlichen Prognose (graue Balken, Stunde 14 ignoriert)
Die Balken zeigen:

Stunde 13: Peak vorhanden, aber zu niedrig → Slope = 0.8 bestätigt

Stunde 10–11: starke Aktivität, aber nicht voll getroffen

Stunde 15–17: WP‑Last sichtbar, aber gedämpft

Stunde 18–23: geglättet, keine echte WP‑Dynamik

Stunde 00–09: plausibel, aber zu flach für Frostschutz oder Nachtladung

→ Das Modell trifft die Form des Tagesprofils, aber nicht die Höhe oder die WP‑Peaks.

🔍 Numerische Bewertung (Stunde 14 ignoriert)
Die Metriken bleiben:

MAE = 165.82 Wh

RMSE = 244.44 Wh

RMSE_rel = 79 %

Slope = 0.8

Bias = 60 Wh

R² = 0.89

→ Die Retrain‑Entscheidung bleibt korrekt, denn:

RMSE_rel ist viel zu hoch

Slope ist zu flach

MAE ist nicht WP‑tauglich

🧠 Was das Modell trotzdem gut macht
ValStd = 0.000093 → extrem stabil

BitFail = 0 → keine neuronalen Sättigungen

R² = 0.89 → gute Formtreue

Bias = 60 Wh → keine systematische Verschiebung

MedAE = 45 Wh → zeigt, dass viele Stunden gut getroffen sind

→ Das Modell ist technisch sauber, aber semantisch zu flach.

🛠 Empfehlungen zur Verbesserung
🔧 Architektur
Steilheit auf 1.2 erhöhen → WP‑Peaks werden durchgelassen

RPROP statt INCREMENTAL → besser für nichtlineare WP‑Last

Snapshot später zulassen → z. B. ab Epoche 300

🔧 Registry
v1_heatpump_active_pv ist korrekt

sicherstellen, dass cop_booster, frost_protection, semantic_peak_push, hp_power_factor aktiv sind

🔧 Training
Retry mit Seed‑Sweep

Early Stopping später aktivieren

Verstärkerwirkung visuell prüfen (z. B. Stunde 13, 17, 06)

🎯 Fazit
Auch ohne Stunde 14 bleibt das Modell nicht einsatzreif für WP‑Haushalte.
Die Prognose ist zu flach, zu geglättet, nicht peak‑sensitiv.
Die Registry ist korrekt, aber wird durch:

Steilheit 0.5

INCREMENTAL

frühen Snapshot

ausgebremst.

Den Vorschlag
Steilheit auf 1.2 erhöhen → WP‑Peaks werden durchgelassen

würde ich unterschreiben.

Bei RPROP statt INCREMENTAL → besser für nichtlineare WP‑Last bin ich eher nicht der Meinung (siehe Wolle) aber einen Versuch ist es ja wert.

[TheTrumpeter]

Den Vorschlag
Steilheit auf 1.2 erhöhen → WP‑Peaks werden durchgelassen

Danke, hab' ich mal gesetzt und neu gestartet.


Zu meinem Nutzungsverhalten:
Die WP startet bei normalen Temperaturen typischerweise zwischen 08:45 und 09:15 und läuft dann je nach Außentemperatur ein paar Stunden durch, von 2h in der Übergangszeit bis zu 6-7 h bei typischen Wintertemperaturen.
In der derzeitigen Kältephase startet sie durchaus schon um 06:00 und läuft dann auch mal 12 oder 13 h.

Irgendwann während der "Heizphase" springt dann das WW dazwischen, d.h. aus SolarForecast-Sicht wird der Verbraucher dann beendet und ein anderer (Nicht-WP-) Verbraucher läuft. Wenn die WW-Temperatur erreicht ist, "übernimmt" wieder der "WP-Verbraucher". Das führt natürlich zu einer gewissen Unschärfe.

[Wolle02]

@Wolle, Würde ich auch so sehen. KI sagt:

Code Auswählen Erweitern

🧠 Was hier passiert
🔹 Verstärker sind aktiv
→ Die Registry liefert starke Signale für PV‑Peaks und Lastsprünge.

🔹 Aber: Steilheit = 0.9
→ SIGMOID mit 0.9 ist zu flach → Verstärker werden ,,abgefedert".

🔹 RPROP springt früh
→ Best Snapshot bei Epoche 54 → Verstärker noch nicht voll gelernt.

🔹 Snapshot‑Logik greift zu früh
→ Modell wird eingefroren, bevor Verstärker ihre Wirkung entfalten.

🛠 Was du tun kannst
✅ Steilheit auf 1.2 setzen
→ Verstärker wirken deutlich stärker
→ Slope steigt
→ Bias sinkt
→ RMSE_rel verbessert sich

✅ Snapshot erst ab Epoche 150 zulassen
→ Verstärker brauchen Zeit
→ RPROP darf sich entfalten
→ Modell wird nicht zu früh eingefroren

✅ Retry mit Seed‑Variation
→ RPROP reagiert stark auf Initialisierung
→ Seed‑Sweep kann bessere Minima finden

🎯 Fazit
Du hast die Verstärker korrekt eingebaut — das ist super.
Aber: RPROP + flache Aktivierung + früher Snapshot bremst sie aus.

Probier es mal so wie vorgeschlagen, ansonsten nimm wieder INCREMENTAL mit Steepness=1.2
Dein erstes Setup war ja nicht so schlecht.

So, jetzt wieder mit Incremental und Steilheit=1.2. Sieht wieder besser aus:

Code Auswählen Erweitern

letztes KI-Training: 12.01.2026 18:07:45 / Laufzeit in Sekunden: 2857
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 33.68 ms
Verbrauchernummer Wärmepumpe: -

=== Modellparameter ===

Normierungsgrenzen: PV=8888 Wh, Hausverbrauch: Min=0 Wh / Max=12741 Wh
Trainingsdaten: 6244 Datensätze (Training=4995, Validierung=1249)
Architektur: Inputs=64, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.5, BitFail-Limit=0.35
Aktivierungen: Hidden=SIGMOID, Steilheit=1.2, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_common_active_pv
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 2639 (von max. 15000)
Training MSE: 0.000355
Validation MSE: 0.000277
Validation MSE Average: 0.000309
Validation MSE Standard Deviation: 0.000008
Validation Bit_Fail: 0
Model Bias: -10 Wh
Model Slope: 0.9
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 135.71 Wh
MedAE: 77.52 Wh
RMSE: 174.29 Wh
RMSE relative: 31 %
RMSE Rating: weak
MAPE: 18.37 %
MdAPE: 13.88 %
R²: 0.91
Danke fürs drüberschauen 

[DS_Starter]

@Wolle, hier die Bewertung:

Code Auswählen Erweitern

Das Modell ist technisch solide, aber semantisch zu flach für stündliche Haushaltsprognosen ohne Wärmepumpe. Ich zeige dir jetzt, warum die Retrain‑Entscheidung korrekt ist, obwohl die Form gut getroffen wird.

📊 Numerische Bewertung
Metrik    Wert    Bewertung
Train MSE    0.000355    sehr gut
Val MSE    0.000277    stabil
ValStd    0.000008    extrem niedrig → Modell ist konsistent
BitFail    0    perfekt
Bias    −10 Wh    neutral
Slope    0.90    leicht zu flach
MAE    135 Wh    zu hoch für Standardhaushalt
RMSE    174 Wh    schwach
RMSE_rel    31 %    nicht akzeptabel
R²    0.91    sehr gut
MAPE    18.4 %    zu hoch
MdAPE    13.9 %    grenzwertig
Bewertung    Retrain    korrekt
🧠 Interpretation
✅ Was gut ist:
Formtreue: R² = 0.91 → Tagesverlauf wird gut getroffen

Stabilität: ValStd = 0.000008 → keine Schwankungen

Bias = −10 Wh → keine systematische Verschiebung

BitFail = 0 → keine neuronalen Sättigungen

Slope = 0.9 → Modell reagiert, aber nicht voll dynamisch

❌ Was kritisch ist:
MAE = 135 Wh → zu hoch für stündliche Steuerung

RMSE_rel = 31 % → deutliche Abweichungen bei Spitzen

MAPE > 18 % → zu grob für PV‑Optimierung

Retrain‑Entscheidung korrekt, da RMSE‑Rating = weak

📈 Was das Modell visuell zeigt (graue Balken)
Form stimmt: Tagesverlauf ist plausibel

Spitzenlasten werden unterschätzt → Slope = 0.9

Morgen- und Abendlasten sind geglättet

PV‑Mittagspeak wird nicht voll durchgelassen

Keine WP‑Artefakte sichtbar → korrekt für WP‑frei

🛠 Empfehlungen zur Verbesserung
🔧 Architektur
Steilheit 1.2 ist gut → beibehalten

Hidden Layers ggf. auf 60‑30‑15 reduzieren → weniger Glättung

RPROP als Alternative testen → kann Peaks besser lernen

🔧 Registry
v1_common_active_pv ist korrekt

ggf. pv_peak_booster aktivieren

semantic_peak_push verstärken

🔧 Training
Retry mit Seed‑Sweep

Snapshot ab Epoche 300 zulassen

Verstärkerwirkung visuell prüfen (z. B. Stunde 10–13)

🎯 Fazit
Das Modell ist technisch sauber, aber semantisch zu flach für präzise Haushaltsprognosen ohne WP.

Ich würde das so lassen. Aber kannst auch:

Code Auswählen Erweitern

Hidden Layers ggf. auf 60‑30‑15 reduzieren → weniger Glättung

RPROP als Alternative testen → kann Peaks besser lernen
gerne mal testen und wenn es nicht besser wird -> wieder zurück auf aktuelle Einstellung.
 
Die Hinweise:

- ggf. pv_peak_booster aktivieren
- semantic_peak_push verstärken

sind etwas für mich was ich prüfen und ggf. umsetzen werde.

[DS_Starter]

@all,

die V2.0.0 im Contrib stellt nun auch die Windgeschwindigkeiten (windspeed) in nextHours etc. zur Verfügung. Bei Verwendung von DWD-Devices als Wetterlieferant muß man "FF" im DWD-Device mit aktivieren.

Der Systemcheck weist darauf hin falls nicht gesetzt.

[TheTrumpeter]

Hier das Ergebnis des gestrigen Lernvorgangs mit der erhöhten Steilheit, Log inkl. automatischem Lernzyklus heute Nacht im Anhang:

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 13.01.2026 04:58:59 / Laufzeit in Sekunden: 9511
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 80.79 ms
Verbrauchernummer Wärmepumpe:  03

=== Modellparameter ===

Normierungsgrenzen: PV=18612 Wh, Hausverbrauch: Min=0 Wh / Max=6400 Wh
Trainingsdaten: 8035 Datensätze (Training=6428, Validierung=1607)
Architektur: Inputs=112, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.8, BitFail-Limit=0.35
Aktivierungen: Hidden=SIGMOID, Steilheit=1.2, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 1916 (von max. 15000)
Training MSE: 0.000451
Validation MSE: 0.002025
Validation MSE Average: 0.002368
Validation MSE Standard Deviation: 0.000026
Validation Bit_Fail: 0
Model Bias: 42 Wh
Model Slope: 0.9
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 137.45 Wh
MedAE: 39.56 Wh
RMSE: 187.68 Wh
RMSE relative: 60 %
RMSE Rating: very bad
MAPE: 18.01 %
MdAPE: 10.29 %
R²: 0.91

=== Drift-Kennzahlen ===

Drift Score: -
Drift RMSE relative: -
Drift Bias: -
Drift Slope: -
Drift Bewertung: -
Die Prognose für heute finde ich gar nicht so schlecht:
Die Unterbewertung um 04:00 ergibt sich im Wesentlichen durch den "NoFrost"-Zyklus vom Gefrierschrank, der heute Nacht zufällig kurz nach 04:00 startete.
Die Unterbewertung um 05:00 ergibt sich durch den etwas früheren Kaffee- und Küchenmaschineneinsatz heute Früh. (Normal kurz nach 06:00, heute schon kurz vor 06:00.)
Die Prognose für 09:00-16:00 ist 1 h zu spät angesetzt. Wie gestern geschrieben sollte die WP frühestens um 08:45, spätestens um 9:25 einschalten, damit ergäbe sich für 08:00 theoretisch der Verbrauch von 09:00 und von 09:00 der Verbrauch von 10:00.
Der Rest sowie die Dauer des hohen Verbrauchs passt ganz gut würde ich sagen.

[lorisurfen]

@Wolle,

Wäre es eventuell möglich einen zusätzlichen Schlüssel z.B. replan=1 einzufügen, der eine sofortige Neuplanung einleitet, wenn der Zyklus abgeschlossen ist?

Das wäre möglich. Allerdings wirkt es dann natürlich ständig, sodass man eigentlich nur mit interuptable arbeiten bräuchte um den gleichen Effekt zu erzielen.
Aktuell habe ich dafür den Befehl "set <name> consumerNewPlanning XX" vorgesehen.
Die Idee dahinter ist, dass der User z.B. mit einem notify, DOIF auf einen finished-Status reagieren und über diesen Befehl direkt eine Neueinplanung vornehmen kann. Das ist wesentlich flexibler, weil man z.B. die täglichen Neueinplanungen auf 3 begrenzen oder von Zusatzbedingungen abhängig gestalten kann.

LG,
Heiko

Laut meinem debug von gestern wird aber swoncond nur beim erstmaligen einschalten geprüft, nicht aber nach interruptable ?
Ich hätte erwartet, wenn über Schlüssel interruptable unterbrochen wird, dann beim (Wieder-)Einschalten auch swoncond geprüft/erfüllt sein muss? Ist das ein Fehler oder kann ich das irgendwie einstellen, dass nach interruptable auch swoncond geprüft wird. Ist Prüfung auf swoncond evtl. unterschiedlich bei interruptable=1 und interruptable=Bedingung?
Nach swoffcond und einem replan (Sofortige Neueinplanung) würde dagegen doch auch swoncond erneut geprüft (Für meinen Fall möchte ich immer, dass beim Wiedereinschalten auch swoncond geprüft wird).
Entweder muss nach interruptable auch swoncond geprüft werden oder die folgende Aussage wäre nicht zutreffend?:

Das wäre möglich. Allerdings wirkt es dann natürlich ständig, sodass man eigentlich nur mit interuptable arbeiten bräuchte um den gleichen Effekt zu erzielen.