76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[300P]

Es kann weitergehen. Das Modul im contrib ist upgedated.
Ich konnte sehr wahrscheinlich das Problem mit den Daten von 300P indentifizieren und beheben.

Nächster Schritt wäre download und retrain mit unveränderten Parametern.

Der MSE-Wert berechnet sich......morgen dann das Ergebnis

Code Auswählen Erweitern

...............
2026.01.02 23:47:47 1: Forecast DEBUG> Epoche 3800: Train MSE=0.005262, Val MSE=0.018045, Val MAE=0.099730, Val MedAE=0.068744, Bit_Fail=16
2026.01.02 23:48:21 1: Forecast DEBUG> Epoche 3900: Train MSE=0.005200, Val MSE=0.017774, Val MAE=0.098886, Val MedAE=0.068582, Bit_Fail=16
2026.01.02 23:48:56 1: Forecast DEBUG> Epoche 4000: Train MSE=0.005172, Val MSE=0.016687, Val MAE=0.095610, Val MedAE=0.067800, Bit_Fail=15


[DS_Starter]

Und du siehst wie sich die Werte von Epoche zu Epoche verbessern.

[300P]

Ja - ist so 🤗

[DS_Starter]

Dann gute Nacht ... bin gespannt was du morgen zeigen kannst.

LG

[grappa24]

moin,

hier meine neuesten Werte mit HiddenLayers 80-40-20 und der v2.0.0 von gestern Abend:

PHEV: 12 kWh Akku und max 3.5 kW Ladeleistung
WP:   Keine

Code Auswählen Erweitern

letztes KI-Training: 03.01.2026 05:04:17 / Laufzeit in Sekunden: 19357
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 68.72 ms

=== Modellparameter ===

Normierungsgrenzen: PV=13080 Wh, Hausverbrauch: Min=0 Wh / Max=5038 Wh
Trainingsdaten: 7943 Datensätze (Training=6354, Validierung=1589)
Architektur: Inputs=34, 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
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 60 (von max. 15000)
Training MSE: 0.004237
Validation MSE: 0.002891
Validation MSE Average: 0.005071
Validation MSE Standard Deviation: 0.000919
Validation Bit_Fail: 4
Model Bias: 52 Wh
Model Slope: 0.9
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 164.37 Wh
MedAE: 104.07 Wh
RMSE: 218.17 Wh
RMSE relative: 52 %
RMSE Rating: very bad
MAPE: 27.16 %
MdAPE: 22.41 %
R²: 0.84

=== Drift-Kennzahlen ===

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

 Erläuterung der Kennzahlen
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 relative (Root Mean Squared Error) → mittlere quadratische Abweichung relativ zum Medianverbrauch in %
   Richtwerte:
   < 5% → sehr gut, das Modell trifft fast perfekt
   5–10% → gut, das Modell ist zuverlässig
   10–20% → akzeptabel, das Modell ist brauchbar
   > 20% → schwach, das Modell hat starke Ausreißer
   > 35% → katastrophal, das Modell ist unbrauchbar

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.


[300P]

Guten Morgen !

Es gibt ein Ergebnis nach ca. 2.5 h Laufzeit   

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 03.01.2026 02:12:17 / Laufzeit in Sekunden: 9984
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 39.99 ms

=== Modellparameter ===

Normierungsgrenzen: PV=17532 Wh, Hausverbrauch: Min=0 Wh / Max=5920 Wh
Trainingsdaten: 6770 Datensätze (Training=5416, Validierung=1354)
Architektur: Inputs=34, 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
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 6391 (von max. 15000)
Training MSE: 0.004113
Validation MSE: 0.011110
Validation MSE Average: 0.013588
Validation MSE Standard Deviation: 0.000707
Validation Bit_Fail: 3
Model Bias: 801 Wh
Model Slope: 0.5
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 477.30 Wh
MedAE: 381.40 Wh
RMSE: 579.26 Wh
RMSE relative: 29 %
RMSE Rating: weak
MAPE: 24.10 %
MdAPE: 20.74 %
R²: 0.47

=== Drift-Kennzahlen ===

Drift Score: 2.94
Drift RMSE relative: 52.77
Drift Bias: 757.98
Drift Slope: 0.537
Drift Bewertung: severe


-> Screenshot mit aktuellem Forecast (etwas wenig wegen WP-Nutzung bei Kälte um 0 Grad / Schneefall und garantiert kein PV-Ertrag wegen 10 cm Schnee auf den Panels  )
-> Screenshot WP-Verbrauchsverläufe

Falls mehr Daten zur Analyse gewünscht werden - gern auf Nachfrage.
 

[DS_Starter]

Moin,

@grapa24, wie sieht das Diagramm dazu aus? Die Kennzahlen sind nicht schlecht, die Bewertung muß ich überarbeiten.
Für EV muß ich mir demnächst etwas einfallen lassen. Das Netz kann nicht wissen wann ein EV geladen wird, es gibt keine Anhaltspunkte außer Zeitreihen und evtl. noch PV Prognose.

@300P, Die Kennzahlen sind auf jeden Fall noch verbesserungswürdig. Aber da kommt es darauf an wie ich mit den Features und Semantiken vorankomme.
Mit WP könnte es sich lohnen mit aiConShuffleMode=1 zu arbeiten. Dadurch wird beim Train/Test der Rohdatencontainer chronologisch getrennt. Könnte hilfreich sein weil wir hier eine Jahreszeitliche Abhängigkeit haben -> testen.

Ihr könnt, wenn ihr Lust habt, noch etwas mit den Einstellungen spielen um eure Modelle auszutesten. Auch ein Mix aus AI und Legacy mit aiConAlpha kann gute Ergebnisse unterstützen um beide Welten zu verschmelzen.

Auf jeden Fall habe ich schon die nächsten Modellerweiterungen im Hinterkopf und werde Bescheid geben wenn ich ein Update ins contrib geladen habe. Wichtig sind nun Sematiken, also die Herstellung von Beziehungen/Trigger die FANN helfen Zusammenhänge zu erkennen.
Ideal wäre eine Füllsensor im Wäschekorb der darauf hinweist dass nun bald gewaschen werden muß ... Joke. 
Aber ich denke ihr wißt worauf es abzielt... 

LG,
Heiko

[DS_Starter]

Ich war schon etwas weiter gekommen. Hier die aktuellen Ergebnisse:

Code Auswählen Erweitern

letztes KI-Training: 03.01.2026 08:32:00 / Laufzeit in Sekunden: 775
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 10.81 ms

=== Modellparameter ===

Normierungsgrenzen: PV=9276 Wh, Hausverbrauch: Min=0 Wh / Max=8938 Wh
Trainingsdaten: 7971 Datensätze (Training=6376, Validierung=1595)
Architektur: Inputs=34, 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
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 377 (von max. 15000)
Training MSE: 0.000195
Validation MSE: 0.000306
Validation MSE Average: 0.000303
Validation MSE Standard Deviation: 0.000005
Validation Bit_Fail: 0
Model Bias: 120 Wh
Model Slope: 0.8
Trainingsbewertung: Borderline

=== Fehlermaße der Prognosen ===

MAE: 97.95 Wh
MedAE: 61.55 Wh
RMSE: 115.50 Wh
RMSE relative: 18 %
RMSE Rating: acceptable
MAPE: 15.83 %
MdAPE: 9.35 %
R²: 0.90
Aber ich erweitere das Modul noch vor dem nächsten Update.

[grappa24]

Wichtig sind nun Sematiken, also die Herstellung von Beziehungen/Trigger die FANN helfen Zusammenhänge zu erkennen.
Ideal wäre eine Füllsensor im Wäschekorb der darauf hinweist dass nun bald gewaschen werden muß ... Joke. 

Anwesenheitserkennung für Bewohner läuft bei mir - Big Brother lässt grüßen 

[DS_Starter]

.. Ja, kommt demnächst mit rein.

Edit: Noch der Hinweis. Wenn ihr FANN aktiviert habt mit aiConActivate=1 und ihr startet ein neues Training, schaltet SF intern sofort in den Legacy Mode um und verwendet die klassische Methode zur Con-Prognose bis das Training durch ist. Es gibt dadurch also kein GAP.

[300P]

PS:
Für die WP-Fraktion ist es vermutlich nicht so stark einflussnehmend ob jemand anwesend ist oder nicht - es wird ja nicht On/Off geheizt wie bei einer Gas/Öl-Heizung in sehr alten Zeiten
Mit 50-70 Grad Vorlauf in die Radiatoren.

Auch einige ,,nicht WP-Heizer" gehen aber inzwischen aus Kosten- und Effizient-Gründen dazu über die Vorlauftemperaturen bei der Heizung zu verringern (soweit dies es geht).

Der größte Einflussfaktor ist sicherlich bei allen Heizungsarten die Ausssentemperatur. Nach der richtet sich der dann notwendige Energieverbrauch wohl entscheident.

Daher sind die meisten (auch 20-30 Jahre alte) Heizungen bereits mit Außentemperatursensoren ausgestattet die dann die damit VL-Temperatur / Leistung der Gastherme/Ölheizung/WP entsprechen mittels eine hinterlegten Vorlaufkurve / -temperatur oder -tabelle zur Aussentemperatur steuern.

Evtl. wäre es ratsamer hier eine Abhängige Formel für die Temperatur und deren Verbrauch hinterlegen zu können?!?!?

[Wolle02]

PS:
Für die WP-Fraktion ist es vermutlich nicht so stark einflussnehmend ob jemand anwesend ist oder nicht - es wird ja nicht On/Off geheizt wie bei einer Gas/Öl-Heizung in sehr alten Zeiten
Mit 50-70 Grad Vorlauf in die Radiatoren.

Das zu verallgemeinern ist aber gefährlich und trifft nur für die Fälle zu bei denen die WP eine Fußbodenheizung bedient. Das ist aber mitnichten grundsätzlich so. Ich zB habe keine Fußbodenheizung, sondern bediene mit meiner WP durchaus herkömmliche Radiatoren wie in "sehr alten Zeiten" (naja mein Haus ist ja auch 100 Jahre alt). Aus diesem Grunde heize ich sehr wohl On/Off und nutze hierzu natürlich die Anwesenheitserkennung von Fhem.

Allerdings wird die WP bei mir nicht von der PV gespeist, sondern hat einen eigenen Zähler mit einem Wärmestromtarif. Ich habe leider im Winter nicht genug Ertrag als dass das den Aufwand und die Kosten für die Installation rechtfertigen würde.

[300P]

Ich meine so etwas in der Art für die WP
(je nach Hersteller-/WP-Größe ->>> individuell vom User in einem "attr" hinterlegbar)


=>>siehe Screenshot

[DS_Starter]

Nabend zusammen,

Evtl. wäre es ratsamer hier eine Abhängige Formel für die Temperatur und deren Verbrauch hinterlegen zu können?!?!?

Für FANN ist das nicht nötig. Die Abhängigkeiten zwischen Temperatur und Verbrauch ergeben sich aus den internen Verknüpfungen im Modul (den Semantiken), die ich der KI zum Lernen bereitstelle.
Konkret heißt das, FANN wird über die Rohdaten (aiRawData) verschiedene historische Kennwerte bereitgestellt, z.B.:

- Monat  (darüber die Jahreszeit)
- Wochentag
- Stunde des Tages
- Außentemperatur  (zur Zeit als Aufzeichnung vom Wetterdienst was hier ungünstig ist)
- E-Verbrauch pro Stunde
- Arbeitstag oder Wochenende
- Anwesenheit bzw. Urlaub/Feiertag  (zukünftig)
- PV-Ertrag
- Sonnstand (Azimut, Altitude)
- usw...

Es werden daraus noch etliche Zusatzsignale bereitgestellt, wie z.B. Deltas der letzen Stunden und vieles andere. Während des Trainingsprozesses stellt FANN Verknüpfungen/Gewichtungen zwischen all diesen Werten her und erkennt im Besten Fall die richtigen Muster, z.B. wenn 3 Grad kalt und Dezember und es ist Abends 20:00 an einem Wochende ist der E-Verbrauch typischerweise so und so hoch. FANN weiß nicht dass es eine WP gibt, nur die Rahmendaten zum Verbrauch.
Für die Abfrage muß ich dementsprechend Prognosedaten bereitstellen, also z.B.:

- in den nächsten Stunden wird es soviel Temp sein (Wetterprognose)
- wird es Arbeitstag und Uhrzeit sein (trivial)
- wird es soviel PV geben (PV Prognose)
- wird Anwesenheit im Haus sein (Feiertags/Urlaubsprognose)
- wird die bestimmte Jahreszeit sein (trivial)
- wird der Sonnenstand x/y sein (Prognose aus PAH's Astro)
- usw.

Aus all diesen Dingen ermittelt FANN mit dem trainierten Modell die Prognose für den E-Verbrauch für Stunde X.
Nur als kleine Erläuterung wie das Ganze so funktioniert. Machine Learning Spezies mögen bitte Nachsicht üben wenn nicht alles korrekt ausgedrückt ist. 

Was die Temperatur und andere "Umweltdaten" betrifft, wird es ein Attribut setupEnvironment geben, wo man als Nutzer Temperaturfühler, Anwesenheits-Devices und solche Dinge hinterlegen kann.

[300P]

Allerdings wird die WP bei mir nicht von der PV gespeist, sondern hat einen eigenen Zähler mit einem Wärmestromtarif. Ich habe leider im Winter nicht genug Ertrag als dass das den Aufwand und die Kosten für die Installation rechtfertigen würde.

Bei den aktuellen winterlichen PV-Erträgen, die ja immer im  Nov/Dez/Jan/Feb relativ gering sind, versorgt meine PV (14.5 kWp mit 26 kW Batterie) ebenfalls nur mit einem kleinen Anteil bei meinem WP-Verbrauch.
(Jedes kWh zählt bei keinem Wärmestromtarif !!!)

Meine bisherige hohe Autarkie von mehr als 95 % (ohne WP) hat arg gelitten seitdem die WP dieses Jahr mitläuft.....
Für 2025 gab es dann nur noch bei 69 % Autarkie.
Dabei hat sich die Eigennutzung von ca. 70 % auf 83 % erhöht.

Ich bin gespannt, wenn ich ich die ersten 12 vollen Monate hinter mir, habe was da dann als Ergebnis für den Zeitraum rauskommt.