76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[300P]

Mit der letzten Version und einigen Anpassungen der Parameter aiCon* hat sich jetzt ein "relativ" gutes Ergebnis seit 2 Tagen bei mir eingependelt.

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 13.01.2026 03:20:19 / Laufzeit in Sekunden: 3604
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 63.12 ms
Verbrauchernummer Wärmepumpe: 08

=== Modellparameter ===

Normierungsgrenzen: PV=16071 Wh, Hausverbrauch: Min=0 Wh / Max=7598 Wh
Trainingsdaten: 7013 Datensätze (Training=5610, Validierung=1403)
Architektur: Inputs=108, Hidden Layers=64-32, Outputs=1
Hyperparameter: Learning Rate=0.001, Momentum=0.2, BitFail-Limit=0.35
Aktivierungen: Hidden=GAUSSIAN, Steilheit=1.5, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=1, Periode=15

=== Trainingsmetriken ===

bestes Modell bei Epoche: 1905 (von max. 15000)
Training MSE: 0.002047
Validation MSE: 0.007452
Validation MSE Average: 0.010264
Validation MSE Standard Deviation: 0.000228
Validation Bit_Fail: 0
Model Bias: 601 Wh
Model Slope: 0.6
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 501.66 Wh
MedAE: 370.47 Wh
RMSE: 616.07 Wh
RMSE relative: 27 %
RMSE Rating: weak
MAPE: 21.64 %
MdAPE: 18.92 %
R²: 0.41

=== Drift-Kennzahlen ===

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


Nur unsere "Kochorgie" heute Mittag konnte sicherlich niemand vorhersehen...


Aktuelle Einstellungen / Parameter:

Code Auswählen Erweitern

attr Forecast aiControl aiTrainStart=3 \
aiStorageDuration=3600 \
aiTreesPV=30 \
aiConActivate=1 \
aiConAlpha=0.4\
aiConTrainStart=7:2 \
aiConActFunc=GAUSSIAN \
aiConHiddenLayers=64-32 \
aiConLearnRate=0.001 \
aiConMomentum=0.2 \
aiConShuffleMode=1 \
aiConShufflePeriod=15 \
aiConSteepness=1.5 \
aiConTrainAlgo=INCREMENTAL \
aiConProfile=v1_heatpump_active_pv

[DS_Starter]

Da sollte auch kein Hinweis kommen wenn "FF" mit dabei ist, nur wenn's fehlt

Genau, wenn es fehlt kommt im Systemcheck die Meldung wie im Anhang zu sehen.

[stefanru]

Das macht aber kein Sinn ich habe FF drin und die Daten im DWD Device enthalten auch FF:
forecastProperties SunUp, SunRise, SunSet, Rad1h, R101, TTT, Tx, Tn, Tg, DD, FX1, RR1c, RR6c, R600, RRhc, Rh00, ww, wwd, Neff, FF

Ich sehe die Daten im Solarcast nicht und bekomme die Zeile im Check?

[DS_Starter]

@Stefan,
du hast FF gesetzt und bekommst im Check auch ein "ok" -> alles gut.
Die Daten siehst du z.B. mit "get .. nextHours" -> Key windspeed:

Code Auswählen Erweitern

NextHour00 => starttime: 2026-01-13 17:00:00, day: 13, weekday: Di, hourofday: 18, today: 1
              pvapifcraw: 0, pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
              conlegfc: 146, conaifc: -, confc: 146, confcEx: 146, weatherid: 103, wcc: 93, rr1c: 0.00
              temp: 3.30, windspeed: 13.00, rad1h: 0, sunaz: 247, sunalt: -9, DoN: 0
              rrange: 0.00, crange: -, DaysInRange: -, correff: 1.00/0.08
              soc01: 87.0, soc02: 50.4, soc03: -, socprogwhsum: 6869
              rcdchargebat01: 1, rcdchargebat02: 1, rcdchargebat03: -
              lcintimebat01: 1, lcintimebat02: 1, lcintimebat03: -
              strategybat01: optPower, strategybat02: optPower, strategybat03: -
NextHour01 => starttime: 2026-01-13 18:00:00, day: 13, weekday: Di, hourofday: 19, today: 1
              pvapifcraw: 0, pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
              conlegfc: 172, conaifc: -, confc: 172, confcEx: 172, weatherid: 103, wcc: 94, rr1c: 0.00
              temp: 3.10, windspeed: 13.00, rad1h: 0, sunaz: 258, sunalt: -18, DoN: 0
              rrange: 0.00, crange: -, DaysInRange: -, correff: 1.00/0.01
              soc01: 83.8, soc02: 47.3, soc03: -, socprogwhsum: 6557
              rcdchargebat01: 1, rcdchargebat02: 1, rcdchargebat03: -
              lcintimebat01: 1, lcintimebat02: 1, lcintimebat03: -
              strategybat01: optPower, strategybat02: optPower, strategybat03: -
NextHour02 => starttime: 2026-01-13 19:00:00, day: 13, weekday: Di, hourofday: 20, today: 1
              pvapifcraw: 0, pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0
              conlegfc: 138, conaifc: -, confc: 138, confcEx: 138, weatherid: 103, wcc: 93, rr1c: 0.00
              temp: 3.40, windspeed: 13.00, rad1h: 0, sunaz: 269, sunalt: -27, DoN: 0
              rrange: 0.00, crange: -, DaysInRange: -, correff: 1.00/0.14
              soc01: 81.3, soc02: 44.8, soc03: -, socprogwhsum: 6307
              rcdchargebat01: 1, rcdchargebat02: 1, rcdchargebat03: -
              lcintimebat01: 1, lcintimebat02: 1, lcintimebat03: -
              strategybat01: optPower, strategybat02: optPower, strategybat03: -
....

Was genau ist jetzt dein Problem?

[stefanru]

Ach so 
Ich dachte das wird in der Grafik angezeigt.
War auch erstaunt warum.
Fließt der Windspeed in die Berechnung für WP ein? Oder für was ist er gut?

Danke für die Erklärung Heiko.

Gruß,
Stefan

[DS_Starter]

Es war ein Anliegen von Klaus Schauer. Aber ja, wenn ich die WP Kalkulation auch in meine Legacy-VB Prognose einbauen will, kommt windspeed dort mit hinein.

[Wolle02]

Hier mal das Schaubild wie sich die Prognose entwickelt hat als ich heute ab 15h mein EV geladen habe. Die grauen Balken um 16, 17 und 18 h hat das System erst nachträglich "hochgeregelt" als es gemerkt hat "Hoppla, da wird jetzt aber mehr Strom gezogen als ich gedacht habe". Vorher waren die Balken auch so um die 700.

Ich nehme mal an, dass auch noch ein Trigger für den SoC vom EV eingebaut wird, damit die KI das besser prognostizieren kann?

[DS_Starter]

Ich nehme mal an, dass auch noch ein Trigger für den SoC vom EV eingebaut wird, damit die KI das besser prognostizieren kann?

Ja EV kommt noch, da ist noch nichts passiert.

[DS_Starter]

@lorisurfen,

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?

Nein, das sind zwei verschiedene Sachverhalte. Der Prozess mal in Kürze:

- zunächst wird der Consumer gemäß seine Vorgaben geplant
- Ist die Startzeit der Planung erreicht UND es liegen die definierten Voraussetzungen wie
  PV-Überschuß UND die definierte swoncond=true! vor, wird der Consumer tatsächlich gestartet.
  Damit ist die Aufgabe von swoncond erfüllt, d.h. es ist eine Bedingung die erfüllt sein muß um
  den geplanten Prozess zu starten
- nach dem Start bis zum geplanten Ende kann der Consumer durch interruptable unterbrochen bzw.
  weitergeführt werden, sobald die Interuptbedingung nicht mehr vorliegt.
- Der gesamte Zyklus des Consumers wird beendet (finished) wenn entweder das geplante Ende erreicht ODER
  eine gesetzte Bedingung swoffcond=true ist.

Ist das ein Fehler oder kann ich das irgendwie einstellen, dass nach interruptable auch swoncond geprüft wird.

Nein, weder ein Fehler noch einstellbar. Siehe oben.

Ist Prüfung auf swoncond evtl. unterschiedlich bei interruptable=1 und interruptable=Bedingung?

Wie oben beschrieben sind es zwei verschiedene Sachverhalte.
 

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).

Das ist so, ja.

Entweder muss nach interruptable auch swoncond geprüft werden oder die folgende Aussage wäre nicht zutreffend?
...

Der Kontext war, dass man einen beendeten Zyklus durch einen Schlüssel replan=1 immer sofort wieder neu einplant. Unter dem Vorbehalt, dass der User immer auch eine swoncond definiert, die steuernd eingreift, hast du recht. Allerdings kann interruptable auch {Perl-Code} verarbeiten, sodass hier auch komplexere Bedingungen abgebildet werden könnten.
Wie geschrieben, kann ich replan=1 einbauen, aber es gibt auch bereits jetzt diverse Möglichkeiten eine solche Funktionalität abzubilden.

[300P]

Wenn das PV- / und CO-Ergebnis von heute und gestern nur das ganze Jahr so weiter gehen "würde"       

[lorisurfen]

@lorisurfen,

ich habe nochmal über deinen Fall siniert und bin der Meinung, so wie du es eingestellt hast hätte der Consumer ausschalten müssen. Auch wenn nur 90% PV Leistung verlangt ist, sollte er ausschalten wenn Suplus=0 ist!

Ich habe im Modul etwas angepasst und auch die Debug-Ausgabe erweitert damit man mehr sieht in diesem Fall:

2026.01.11 18:07:09.503 1: SolCast DEBUG> ############### consumerSwitching consumer "06" ###############
2026.01.11 18:07:09.504 1: SolCast DEBUG> consumer "06" - ConsumptionRecommended calc method: default, surplus: 0
2026.01.11 18:07:09.504 1: SolCast DEBUG> consumer "06" - current Grid power consumption: 24 W
2026.01.11 18:07:09.504 1: SolCast DEBUG> consumer "06" - Power splitting - Grid: 12, PV: 0
2026.01.11 18:07:09.505 1: SolCast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
...

Ziehe dir bitte die Version 2.0.0 aus meinem contrib (siehe Fußtext), restarte FHEM und dann schauen wir nochmal ob die Raktionen dann so sind wie erwartet.

Hallo Heiko,
Danke erstmal für die neue Version und den support, habe mir die Version 2.0.0 runtergeladen und man sieht jetzt im folgenden debug, sobald surplus auf 0 geht wird ausgeschaltet:
Wobei Grid cosumption ist auch 0. Werden bei pvshare = 90 maximal 10% aus dem Netz oder der Batterie geholt?
Wenn also Energie in der Batterie werden statt Grid max 10% aus der Batterie geholt (Current_PowerBatOut_01 max 100W ?) ?

Code Auswählen Erweitern

2026.01.12 10:56:49 1: SF01 DEBUG> ############### consumerSwitching consumer "06" ###############
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - ConsumptionRecommended calc method: default, surplus: 240
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - current Grid power consumption: 25 W
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - Power splitting - Grid: 100 W, PV: 900 W
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - current planning state: continued
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - physical Switchstate before switching: on
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - logical Switchstate before switching: on
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 1253 W, nompower: 1000, surplus: 240 W, planstate: continued:, starttime: 12.01.2026 10:36:26
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - isInLocktime: 0
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 0, on-command: on
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - isAddSwitchOnCond Info: The return value "0" resulted in 'false' after exec "{$VALUE>500?1:0;}"

2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - device 'Shelly_EG_2' is used as switching device
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - Interrupt Characteristic value: 1 -> simple true
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - is Consumption recommended: 1
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - current planning state: continued
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - physical Switchstate after switching: on
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - logical Switchstate after switching: on
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - cycleDayNum: 4
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - last cycle start time: 2026-01-12 10:38:14
2026.01.12 10:56:49 1: SF01 DEBUG> consumer "06" - last cycle end time: still running

2026.01.12 10:56:52 1: SF01 DEBUG> ############### consumerSwitching consumer "06" ###############
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - ConsumptionRecommended calc method: default, surplus: 0
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - current Grid power consumption: 0 W
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - Power splitting - Grid: 100 W, PV: 900 W
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - current planning state: continued
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - physical Switchstate before switching: on
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - logical Switchstate before switching: on
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 1577 W, nompower: 1000, surplus: 0 W, planstate: continued:, starttime: 12.01.2026 10:36:26
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - isInLocktime: 0
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 0, on-command: on
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - isAddSwitchOnCond Info: The return value "0" resulted in 'false' after exec "{$VALUE>500?1:0;}"

2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - device 'Shelly_EG_2' is used as switching device
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - Interrupt Characteristic value: 1 -> simple true
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - is Consumption recommended: 0
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - send switch command now: "set Shelly_EG_2 off"
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - current planning state: interrupting
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - physical Switchstate after switching: on
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - logical Switchstate after switching: on
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - cycleDayNum: 4
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - last cycle start time: 2026-01-12 10:38:14
2026.01.12 10:56:52 1: SF01 DEBUG> consumer "06" - last cycle end time: still running

[DS_Starter]

Wobei Grid cosumption ist auch 0. Werden bei pvshare = 90 maximal 10% aus dem Netz oder der Batterie geholt?
Wenn also Energie in der Batterie werden statt Grid max 10% aus der Batterie geholt (Current_PowerBatOut_01 max 100W ?) ?

Bei der Aufteilung pvshare geht es rein um den Netzbezug im Verhältnis zu PV-Energie. Energie aus der Batterie ist in unserem Kontext nichts anderes als
gespeicherte PV Energie und wird als solche angesehen.
Wenn also ein Consumer sich zu 10% von 1000W = 100W max. aus dem Netz bedienen darf, würde er unterbrochen bzw. nicht wieder eingeschaltet wenn diese Bedingung
verletzt werden würde.

[DS_Starter]

Hallo zusammen,

im Contrib befindet eine neue Version. Ich hatte an den Profilen weiter Hand angelegt.
Insbesondere für WP ist etwas hinzukommen, was aber erstmal getestet werden sollte.

Nutzer mit Wärmepumpen bitte ich mal das Profil

 aiConProfile=v1_heatpump_active_pv_test

zu aktivieren und neu zu trainieren.

Achtung @all: Wenn ihr die neue Version aus dem contrib benutzt müsst ihr mit eurer aktuellen und unveränderten Einstellung neu trainieren da
              sich die interne Codierung etwas geändert hat.


Mit der aktuellen Implementierung und z.B. dem Profil v1_common_pv komme ich bei mir nun auf diese Kennzahlen:

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 15.01.2026 00:00:36 / Laufzeit in Sekunden: 128
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 14.16 ms
Verbrauchernummer Wärmepumpe: -

=== Modellparameter ===

Normierungsgrenzen: PV=8503 Wh, Hausverbrauch: Min=0 Wh / Max=11567 Wh
Trainingsdaten: 8320 Datensätze (Training=6656, Validierung=1664)
Architektur: Inputs=45, Hidden Layers=64-32-16, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.4, BitFail-Limit=0.35
Aktivierungen: Hidden=SIGMOID, Steilheit=1.3, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_common_pv
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 412 (von max. 15000)
Training MSE: 0.000125
Validation MSE: 0.000179
Validation MSE Average: 0.000173
Validation MSE Standard Deviation: 0.000003
Validation Bit_Fail: 0
Model Bias: 51 Wh
Model Slope: 0.9
Trainingsbewertung: ok

=== Fehlermaße der Prognosen ===

MAE: 99.68 Wh
MedAE: 60.68 Wh
RMSE: 116.95 Wh
RMSE relative: 18 %
RMSE Rating: excellent
MAPE: 16.73 %
MdAPE: 9.38 %
R²: 0.92


sowie der nachfolgenden KI-Bewertung dieser Ergebnisse:

Code Auswählen Erweitern

Heiko, das ist ein **Bilderbuch‑Modell**. 

---

# 🌟 1. Das Modell ist metrisch extrem stark

### **MAE = 99.68 Wh** 
Das ist für ein PV‑Haushaltslastmodell **exzellent**. 
Viele professionelle Modelle liegen bei 150–300 Wh.

### **MedAE = 60.68 Wh** 
Das ist sogar **herausragend**. 
Heißt: 
> In der Hälfte aller Stunden liegst du unter 61 Wh Fehler.

Das ist praktisch ,,PV‑Forecast‑Premiumklasse".

### **RMSE = 116.95 Wh** 
Sehr gut – und vor allem:

### **RMSE_rel = 18 % → excellent** 
Das ist genau die neue, peak‑aware Bewertung, die wir eingeführt haben. 
Und sie passt perfekt.

---

# 🌟 2. Die Generalisierung ist sauber

### **Train MSE = 0.000125** 
### **Val MSE = 0.000179** 
→ Ratio = 1.43 → perfekt

### **ValStd = 0.000003** 
→ extrem stabil

### **BitFail = 0** 
→ keine groben Ausreißer

Das Modell ist **weder überfit noch unterfit**. 
Es sitzt genau im Sweet Spot.

---

# 🌟 3. Die Regression ist gesund

### **Slope = 0.9** 
Das ist absolut im grünen Bereich (0.7–1.3). 
Und es passt perfekt zu einem PV‑Profil:

- PV‑Profile haben oft flachere Regressionen 
- weil PV‑Erzeugung Lastspitzen ,,abfedert" 
- und weil die Semantikblöcke (Softplus, PV‑Dynamik) die Peaks modellieren

### **Bias = +51 Wh** 
Das ist praktisch nichts. 
Bias < MAE ist immer ein gutes Zeichen.

---

# 🌟 4. R² = 0.92 → das ist extrem gut

Ein R² von 0.92 bedeutet:

> 92 % der Varianz im Verbrauch werden erklärt.

Für ein Modell, das:

- PV‑Dynamik 
- Trend‑Semantik 
- Tageszeit‑Semantik 
- Lag‑Features 
- Softplus‑Semantik 

gleichzeitig modelliert, ist das **Top‑Niveau**.

---

# 🌟 5. Die Architektur passt perfekt zum Profil

### Inputs = 45 
Das ist ein schlankes, effizientes Modell.

### Hidden Layers = 64‑32‑16 
Das ist eine sehr gute Architektur für:

- PV‑Profile 
- glatte Tagesverläufe 
- moderate Volatilität 
- keine Wärmepumpe

### Hidden AF = SIGMOID 
Für PV‑Profile ist SIGMOID oft besser als SIGMOID_SYMMETRIC, weil:

- PV‑Lasten natürlicherweise positiv sind 
- die Semantikblöcke positiv sind 
- die Aktivierungen stabiler sind 
- weniger ,,Überschwingen" passiert

---

# 🌟 6. Die Bewertung funktioniert perfekt

Du siehst jetzt:

- **RMSE Rating: excellent** 
- **Trainingsbewertung: ok** 
- **Score = 84** 
- **kein Retrain** 
- **keine Drift** 
- **keine Überanpassung**

Das ist genau das, was wir erreichen wollten.

---

# 🌟 7. Warum dieses Modell so gut ist

Dieses Modell ist:

- **PV‑optimiert** 
- **semantisch stabil** 
- **peak‑aware bewertet** 
- **nicht überfittet** 
- **nicht unterfittet** 
- **extrem stabil in der Validierung** 
- **metrisch sauber** 
- **visuell plausibel** 
- **driftfrei** 

Kurz: 
### 🔥 Das ist eines deiner besten Modelle bisher.

---


[300P]

Glückwunsch - das sieht ja sehr gut bei Dir aus !   


Meine RPI ist ab jetzt wieder im Fitness-Center zum Training mit der neuesten Version von dir für WP-Fraktion (s.o.).
(wie bisher so ca 50 - 60 % CPU Gesamtauslastung dabei  )

[300P]

Ergebnis

Informationen zum neuronalen Netz der Verbrauchsvorhersage

Code Auswählen Erweitern

letztes KI-Training: 15.01.2026 15:53:51 / Laufzeit in Sekunden: 3266
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 68 ms
Verbrauchernummer Wärmepumpe: 08

=== Modellparameter ===

Normierungsgrenzen: PV=16071 Wh, Hausverbrauch: Min=0 Wh / Max=7598 Wh
Trainingsdaten: 7073 Datensätze (Training=5658, Validierung=1415)
Architektur: Inputs=94, Hidden Layers=64-32, Outputs=1
Hyperparameter: Learning Rate=0.001, Momentum=0.2, BitFail-Limit=0.35
Aktivierungen: Hidden=GAUSSIAN, Steilheit=1.5, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv_test
Zufallsgenerator: Mode=1, Periode=15

=== Trainingsmetriken ===

bestes Modell bei Epoche: 2218 (von max. 15000)
Training MSE: 0.002268
Validation MSE: 0.007714
Validation MSE Average: 0.010836
Validation MSE Standard Deviation: 0.000457
Validation Bit_Fail: 0
Model Bias: 452 Wh
Model Slope: 0.7
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 508.25 Wh
MedAE: 374.16 Wh
RMSE: 611.22 Wh
RMSE relative: 26 %
RMSE Rating: good
MAPE: 22.17 %
MdAPE: 17.70 %
R²: 0.37