76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Gibt es denn einen Weg, SF so zu konfigurieren oder Datenbestände (rück)zusetzen, sodass die Verbrauchsdaten des vorherigen Tages nicht mehr herangezogen werden und nur noch die für geplanten Verbraucher berücksichtigt werden?

Ich habe schon darüber nachgedacht, aber keine Variante gefunden.
Gesetzt den Fall, alle historischen Daten wären 0 oder nicht vorhanden, gäbe es einen prognostizierten Grundverbrauch von 0.
Man hat aber im Haushalt üblicherweise nur einen kleinen Teil der Verbraucher in SF registriert. Das würde bedeuten eine ausschließlich auf Einbeziehung der Planungsdaten und Excludes der registrierten Verbraucher wäre völlig daneben und unbrauchbar.

Wenn sowas unbedingt gewünscht ist, müsste ich einen komplett neuen/ergänzenden Codeblock für diesen Fall schreiben. Dann würde ich aber auch gern den use Case dahinter verstehen weshalb dies sinnvoll ist.

Edit:

@Heiko: Der meiner Frage zugrunde liegende Anwendungsfall ist für Dich nachvollziehbar, richtig?

Eigentlich nicht 

[Parallix]

...

@Heiko: Der meiner Frage zugrunde liegende Anwendungsfall ist für Dich nachvollziehbar, richtig?

Eigentlich nicht 

Kein Thema! Dann erläutere ich ihn eben.

Anmerkung: Der (ohne KI besser anzuwickelnde) Anwendungsfall entsteht durch ein hochgradig volatiles Nutzungsverhalten, dass sich nicht auf Basis früherer Nutzungen prognostizieren lässt.

Hier die Beschreibung des  Anwendungsfalls:

Der Hausspeicher soll so geladen werden, dass man mit diesem unter Zugrundelegung eines durchschnittlichen Grundverbrauchs (ohne Netzbezug) durch die Nacht kommt. Vorgenannter Grundverbrauch lässt sich durch einen ,,must"-Consumer modellieren.

Wenn ein EV an der Wallbox angesteckt ist (ermittelbar via Reading), soll dieses immer dann so geladen werden, dass hierdurch das o.g. Ziel auch weiterhin erreicht werden kann. Hierzu wird der Ladevorgang auf mehrere Tage mit jeweils durchgehenden Teilladungen aufgeteilt. Während vorgenannter Teilladungen können die Ladeleistungen variieren, minimal jedoch nicht unter P_CHG_MIN und nicht über P_CHG_MAX liegen. Es existiert keine Möglichkeit den Ladezustand des EVs via FHEM zu ermitteln. Lediglich die vollständige Aufladung bis zum am EV einstellbaren TargetSOC_EV kann (via Reading) festgestellt werden.

Der Start und das Ende des EV-Ladevorgangs soll so erfolgen, dass die tägliche Energiemenge möglicher  Umladungen ( BESS → BEV)  stets unter einem max. Wert E_BTV_MAX ĺiegt. Hierdurch können die Umladeverluste minimiert werden. Um sicherzustellen, dass das Fahrzeug nach einer via Reading angegebenen Zeit Time2TargetSOC_EV auf den TargetSOC_EV gebracht ist, wird  E_BTV_MAX bis zum Zieltag sukzessive bis zu einem Limit E_BTV_MAX_LIMIT erhöht. Die jeweilige Einstellung von E_BTV_MAX lässt sich durch einen über ,,must"-Consumer mit täglich variierdender Leistung und Ladedauer modellieren. Kann der TargetSOC_EV zum Zielzeitpunkt nicht erreicht werden, so erfolgt eine rechtzeitig eingeleitete Netzladung.

[DS_Starter]

Der Hausspeicher soll so geladen werden, dass man mit diesem unter Zugrundelegung eines durchschnittlichen Grundverbrauchs (ohne Netzbezug) durch die Nacht kommt. Vorgenannter Grundverbrauch lässt sich durch einen ,,must"-Consumer modellieren.

Das war das fehlende Puzzleteil. Insgesamt ist das schon ein "very advanced" Scenario was du umsetzen möchtest.
Ich werde mal schauen, ob ich einen geeigneten Code implementieren kann, der bei consForecastLastDays=0 sämtliche historischen Daten ignoriert und nur die Power-Anteile der geplanten Verbraucher berücksichtigt.   

[Parallix]

Der Hausspeicher soll so geladen werden, dass man mit diesem unter Zugrundelegung eines durchschnittlichen Grundverbrauchs (ohne Netzbezug) durch die Nacht kommt. Vorgenannter Grundverbrauch lässt sich durch einen ,,must"-Consumer modellieren.

Das war das fehlende Puzzleteil. Insgesamt ist das schon ein "very advanced" Scenario was du umsetzen möchtest.

Ja, in der Tat. Was den Ladecontroller angeht, so bin ich da schon recht weit gekommen, bis ich feststellen musste, dass in SF die Logik (aktuell ) nicht ganz so funktioniert, wie ich es mir (auf Basis der Online-Hilfe und des Wikis) vorgestellt habe.

Ich werde mal schauen, ob ich einen geeigneten Code implementieren kann, der bei consForecastLastDays=0 sämtliche historischen Daten ignoriert und nur die Power-Anteile der geplanten Verbraucher berücksichtigt.   

Das wäre galaktisch!

[grappa24]

Wie bekomme ich denn das m.M.n übertriebene "Folgeverhalten" besser geregelt

Code Auswählen Erweitern

letztes KI-Training: 25.01.2026 02:46:18 / Laufzeit in Sekunden: 11337
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 108.8 ms
Verbrauchernummer Wärmepumpe:  -

=== Modellparameter ===

Normierungsgrenzen: PV=11990 Wh, Hausverbrauch: Min=0 Wh / Max=6468 Wh
Trainingsdaten: 8471 Datensätze (Training=6776, Validierung=1695)
Architektur: Inputs=69, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.5, BitFail-Limit=0.34
Aktivierungen: Hidden=SIGMOID, Steilheit=0.9, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_common_active_pv
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 2445 (von max. 15000)
Training MSE: 0.001336
Validation MSE: 0.001799
Validation MSE Average: 0.002191
Validation MSE Standard Deviation: 0.000353
Validation Bit_Fail: 2
Model Bias: 73 Wh
Model Slope: 0.8
Trainingsbewertung: ok

=== Fehlermaße der Prognosen ===

MAE: 147.46 Wh
MedAE: 71.41 Wh
RMSE: 193.47 Wh
RMSE relative: 46 %
RMSE Rating: acceptable
MAPE: 22.36 %
MdAPE: 15.32 %
R²: 0.86

=== 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: -


[DS_Starter]

Wie bekomme ich denn das m.M.n übertriebene "Folgeverhalten" besser geregelt

Da gibt es m.M. nach mehrere Ansätze die einzeln oder in Kombination dem entgegenkommen:

- ein anderes Profil auswählen
- aiConMomentum erhöhen -> Mittel (z.B. 0.8 ): glättet die Lernschritte, beschleunigt die Konvergenz und verhindert Zickzack-Bewegungen
- aiConSteepness verringern -> 0.5 oder 0.6
- BitFail-Limit senken: Von 0.34 auf z. B. 0.25 -> zwingt das Modell zu konservativerer Anpassung
- aiConAlpha einsetzen -> vllt. 0.7
- evtl. wechseln zu SIGMOID_SYMMETRIC oder ELLIOT_SYMMETRIC (aiConActFunc)

Nach Parameteränderung ist Retraining nötig.
Aber ungeachtet der Trendfolge die zu sehen ist, zählt m.M. nach am Ende das Tagesergebnis, welches möglichst ausgeglichen sein sollte.

Edit: Wenn man genau hinschaut, sind die Stunden 08,09 und 11,12 gegenseitig ganz gut aufgehoben. Stunde 13:00 ist überschätzt und hat danach drastisch reduziert und ist bis 16:00 noch weiter runtergekommen. Ich würde fast sagen, dass das als Reaktion auf unvorhergesehene Entwicklungen schon ziemlich gut ist und die Trendfolge das tut was sie soll.

[DS_Starter]

Bei mir ist heute ein ähnliches Verhalten an zwei Punkten zu sehen. Dennoch steht die CO-Abweichung bei aktuell 1,3%. Was will man mehr ...

Hier noch die Einstellungen/Kennzahlen:

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 22.01.2026 18:27:17 / Laufzeit in Sekunden: 193
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 19.7 ms
Verbrauchernummer Wärmepumpe: -

=== Modellparameter ===

Normierungsgrenzen: PV=8503 Wh, Hausverbrauch: Min=0 Wh / Max=8938 Wh
Trainingsdaten: 8435 Datensätze (Training=6748, Validation=1687)
Architektur: Inputs=69, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.4, BitFail-Limit=0.28
Aktivierungen: Hidden=SIGMOID, Steepness=1.3, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_common_active_pv
Zufallsgenerator: Mode=2, Period=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 370 (max. 15000)
Training MSE: 0.000195
Validation MSE: 0.000306
Validation MSE Average: 0.000300
Validation MSE Standard Deviation: 0.000011
Validation Bit_Fail: 0
Model Bias: 138 Wh
Model Slope: 0.8
Trainingsbewertung: ok

=== Fehlermaße der Prognosen ===

MAE: 97.34 Wh
MedAE: 64.49 Wh
RMSE: 114.26 Wh
RMSE relative: 18 %
RMSE Rating: excellent
MAPE: 16.39 %
MdAPE: 9.52 %
R²: 0.89

=== Rauschen ===

Rauschen Bewertung: low
Empfehlung für Bit_Fail: 0.28 (Einstellung von aiControl->aiConBitFailLimit)

=== Drift-Kennzahlen ===

Drift Score: 2.17
Drift RMSE ratio: 3.86
Drift Slope: 0.644
Drift Bias: 3.87
Drift Bewertung: moderate


[grappa24]

CO-Abweichung fortlaufend: 14 %   gestern: -11,7 %

[DS_Starter]

Ja, da gibt es mit Sicherheit noch Optimierungspotential. Es ist teilweise schon mühselig die optimalsten Einstellungen für den eigenen Haushalt zu finden.
Ich überlege auch schon wie ich die granularen Möglichkeiten der Feature-Registry dem User zugänglich machen kann. Momentan geht das nur über die Profile. Da gäbe es wirklich viel Potential, aber das ist nicht so ohne weiteres machbar und darüber kann man auch wiederum viel kaputt machen. Vllt. habe ich noch einen zündenden Gedanken...

[300P]

Wie bekomme ich denn das m.M.n übertriebene "Folgeverhalten" besser geregelt

Hast du auch schon mit diversen Version trainiert oder bislang "nur" Version=v1_common_active_pv genutzt ?

Wenn ja:
Setze evtl auch mal den BitFail-Limit=0.34 auf 0.15 / 0.25 um zu sehen was in welche Richtung passiert und werfe es ChatGPT zum Fraß (zur Beurteilung und Vergleich) vor.
Ich habe bestimmt an die 50 Trainingsläufe hinter mir und aktuell bin ich (und ChaptGPT) mit dem Ergebnis zufrieden !!
ChaptGPT wurde von mir so gequält das mir ab und an sogar eine Sperrzeit wegen "FREE"-Zugang erteilt wurde   

Wenn nein:
Dann versuche andere "Versionen" und trainiere neu damit und gebe sie ChatGPT zum Vergleichen.


PS:
Erzähle / Schreibe wofür / wovon dazu etc. usw.

Code Auswählen Erweitern

Mit FHEM und nach einem Update auf die neueste Version der 076_Solarforecast.pm vom 18.01.2025

- NEU - Angabe der jeweils aktuellen Aussentemperatur als zusätzlichen Impuls für die Wärmepumpe mittels des Attributes : "setupEnvironment MQTT_EMSwp:boiler_data_outdoortemp"
- NEU - Angabe / Vorgabe eines BitFailLimit's statt eines Festwertes von 0.35 mittels des Attributes : aiConBitFailLimit=0.15 (Erlaubte Eingabewerte: 0.05 .. 0.50 , default: 0.35)

habe ich einen erneuten Trainingslauf mit den folgenden Angaben für das neutrales Netz gemacht:

attr Forecast aiControl aiTrainStart=3
aiStorageDuration=3600
aiTreesPV=30
aiConActivate=1
aiConAlpha=0.9
aiConTrainStart=7:2
aiConActFunc=ELLIOT_SYMMETRIC
aiConHiddenLayers=64-32
aiConLearnRate=0.005
aiConMomentum=0.6
aiConShuffleMode=1
aiConShufflePeriod=20
aiConSteepness=1.0
aiConTrainAlgo=INCREMENTAL
aiConProfile=v1_heatpump_active_pv
aiConBitFailLimit=0.15

dann deine Ergebnis noch dazu packen und du wirst nach einigen Trainings bzw. Ergebnissen dann so etwas erhalten:

Code Auswählen Erweitern

Gute Beobachtung – und nein, das ist nicht komisch, sondern exakt das Verhalten, das man bei diesem Mechanismus erwarten muss.
Ich erkläre dir sauber warum das passiert, was es bedeutet und was du jetzt tun solltest (oder bewusst nicht).
1️⃣ Erst die nüchterne Analyse des Ergebnisses
Harte Fakten (Vergleich vorher → jetzt)
Kennzahl vorher (0.15) jetzt (0.28) Bewertung
Validation MSE 0.00553 0.00760 ❌ schlechter
RMSE 520 Wh 652 Wh ❌ deutlich schlechter
MAE 433 Wh 526 Wh ❌ schlechter
R² 0.56 0.39 ❌ klarer Abfall
Bias 557 Wh 944 Wh ❌ massiv schlechter
Slope 0.7 0.5 ❌ Regression flacht ab
Validation Bit_Fail 79 2 ✔ Ziel erreicht
👉 Kurzfassung:
Du hast BitFail reduziert, aber Modellqualität geopfert.
2️⃣ Warum empfiehlt das System jetzt noch höheres BitFailLimit (0.34)?
Das ist der entscheidende Punkt 👇
Wie die Empfehlung funktioniert
Die BitFail-Empfehlung basiert NICHT auf Prognosequalität, sondern auf:
Residuenverteilung
Rauschen
Ausreißerhäufigkeit
Robustheit gegenüber Abweichungen
Mit höherem BitFailLimit:
weniger Fehler werden als ,,Fail" gezählt
das Modell gilt statistisch als ,,ruhiger"
➡️ Die Empfehlung optimiert die Bewertung, nicht die Qualität.
Das System sagt sinngemäß:
,,Wenn du dieses Modell behalten willst, dann hör auf, es so streng zu bewerten."
Nicht:
,,Mach das Modell besser."
3️⃣ Warum ist das Modell jetzt objektiv schlechter?
Ganz wichtig:
Du hast die Fehler toleranter, aber auch die Lernspannung reduziert
Effekt:
das Netz korrigiert systematische Fehler weniger aggressiv
Bias driftet nach oben
Slope fällt Richtung Mittelwert
das Netz ,,spielt sicher"
➡️ Klassischer Effekt:
Zu hohes BitFailLimit = träge Regression
Das sieht man glasklar:
Bias +400 Wh
R² −0.17
RMSE +130 Wh
Das ist kein Zufall, sondern exakt der erwartete Trade-off.
4️⃣ Die Rauschen-Bewertung ,,borderline"
Auch das passt ins Bild:
mit höherem BitFailLimit:
echte Struktur
und echtes Rauschen
werden weniger klar getrennt
➡️ Das Modell ,,glättet zu viel".
5️⃣ Klare Entscheidungsempfehlung (sehr deutlich)
❌ NICHT weiter erhöhen (0.34 wäre falsch)
Das würde:
Bias weiter erhöhen
Slope weiter Richtung 0.4 drücken
R² unter 0.35 fallen lassen
➡️ Das Modell würde zwar ruhig, aber schlecht.
✅ Was stattdessen richtig ist
Du hattest dein bestes Ergebnis hier:
📌 17.01.2026 – 23:27 Uhr
BitFailLimit = 0.15
RMSE ≈ 520 Wh
R² ≈ 0.57
Bias ≈ 635 Wh
Slope ≈ 0.7
👉 Das war objektiv dein Sweet Spot.
6️⃣ Meine klare Empfehlung jetzt
🔧 Einstellung für Produktivbetrieb
aiConBitFailLimit = 0.18 ... 0.22
Warum?
genug streng, um Bias/Slope zu halten
genug tolerant, um BitFails zu begrenzen
kein Qualitätsverlust wie bei 0.28
Wenn du eine Zahl willst:
0.20
7️⃣ Wichtiges Fazit (bitte merken)
Die BitFail-Empfehlung ist kein Optimierungsziel.
Sie ist ein diagnostischer Hinweis, kein Qualitätsmaß.
Du hast es jetzt perfekt demonstriert:
weniger BitFail ≠ besseres Modell
zu viel Toleranz macht das Netz faul
8️⃣ Bottom Line 🧠
❌ 0.34 → falsch
❌ 0.28 → schon zu viel
✅ 0.15–0.20 → optimal für dein System
✅ Außentemperatur war der wichtigste Gewinn
✅ Architektur & Hyperparameter sind jetzt ,,fertig"
Wenn du willst, machen wir als Nächstes:
eine feste Bias-/Slope-Korrekturformel für den Live-Betrieb
oder eine Regel, wann nicht neu trainiert werden darf
Aber: Du hast das Modell jetzt verstanden – und im Griff. 👌

[DS_Starter]

@all,

bevor die weiteren Schritte vorgenommen werden, habe ich mich entschlossen den aktuellen Stand der V 2.0.0 zu finalisieren und ins Repo einzuchecken.

Inzwischen sind schon etliche Mitstreiter mit AI::FANN sowie der Handhabung dieser Möglichkeit vertraut. Obwohl es noch weiteres Optimierungspotential gibt, ist die Lösung - auch weil sie ja optional aktiviviert werden kann - durchaus schon für einen produktiven Betrieb bereit.
Außerdem gibt es in der V 2.0.0 auch einige Fixes und Verbesserungen die nichts mit KI zu tun haben.

Die V 2.0.0 wird also morgen früh als offizielle Version im Update verfügbar sein.

LG,
Heiko