76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Hallo Peter,

slope hat sich auf jeden Fall verbessert und ist nah an der Grenze 0.7. Das ist der einzige verbleibende Trigger für ein Retraining überhaupt.
Etwas unschön ist die weiterhin frühe Konvergenz. Das grafische Ergebnis sieht für mich aber wirklich gut aus.

Mein LLM habe ich es auch bewerten lassen:

Was ELLIOT gebracht hat
Slope: 0.61 → 0.64 — das ist der erste messbare Slope-Fortschritt überhaupt. ELLIOT_SYMMETRIC hat, wie erwartet, weniger starke Sättigung bei Extremwerten und gibt dem Netz mehr Spielraum für Peaks. Gleichzeitig ist Val MSE auf 0.001994 gesunken — bestes Ergebnis aller drei Runs.
R²=0.59 ist ebenfalls ein neues Optimum, wenn auch marginal gegenüber Run 2.

Was noch nicht stimmt
Slope 0.64 verfehlt das Limit 0.7 weiterhin. Der Fortschritt ist konsistent aber langsam: +0.01 pro Parameterchange. Die Ursache liegt nicht mehr in der Aktivierungsfunktion oder Architektur allein.
Beobachtung: Periodisches Schwingen bleibt stark ausgeprägt. Bei jedem 100-Epochen-Report springt Val MSE nach oben (z.B. Attempt 3, E300: 0.002279 statt zuvor 0.002091; E500: 0.002125 statt 0.001995). Das deutet auf Momentum=0.7 als primären Störfaktor hin — beim Shuffle-Event überschießt der akkumulierte Gradient stark, das Netz verlässt gute Minima wiederholt. Dadurch werden auch Peaks instabil gelernt, was direkt die Slope drückt.

Empfehlung: Momentum reduzieren
Das ist jetzt der klarste verbleibende Hebel:

Code Auswählen Erweitern

learning momentum=0.5   # war 0.7
Erwartung: Das Schwingen bei den 100-Epochen-Reports sollte deutlich kleiner werden, das Netz kann gefundene Minima stabiler halten, und die Slope sollte weiter in Richtung 0.70+ steigen. Alle anderen Parameter (ELLIOT, 24-16, steep=0.3, LR=0.003) beibehalten.
Die schrittweise Verbesserung über alle drei Runs ist methodisch sauber — jede Änderung war isoliert und messbar wirksam.

[peterboeckmann]

Hallo Heiko,

nun also mit

learning momentum=0.5  # war 0.7

Bewertungsüberblick:

Code Auswählen Erweitern

Trainingsbewertung: Retrain (Retrain)
Lernverhalten: early früh konvergiert (4.2 % Epochenausnutzung)
Einstellhinweise:
Konvergenz erfolgt früh, Momentum/Lernrate sind bereits konservativ: um mehr nützliche Epochen vor dem Early-Stopping zu ermöglichen, aiConSteepness leicht reduzieren (z.B. um 0.1) für langsamere, feinere Konvergenz - bei zu niedrigen aiConSteepness-Wert kann das Netz komplett aufhören zu lernen (Slope≈0); alternativ Hidden-Layer-Größe/Tiefe (aiConHiddenLayers) leicht erhöhen für mehr Lernkapazität, was aber ggf. mehr Trainingsdaten erfordert
Architektur möglicherweise zu komplex für die Datenmenge: Verhältnis Trainingsdaten zu Netzparametern beträgt nur 2.5 (Zielwert: 8–20) - das Netz hat mehr Freiheitsgrade als die Daten zuverlässig füllen können; kleinere Architektur wie z.B. 14-8 versuchen (aiControl->aiConHiddenLayers)
Empfohlene Lernrate für die vorgeschlagene Architektur 14-8 mit 119 Inputs: 0.0050 (aiControl->aiConLearnRate)
Große Datenmenge (10335 Datensätze gesamt): falls saisonale Effekte die Prognosequalität beeinträchtigen, Training auf die neuesten Datensätze begrenzen (z.B. aiControl->aiConTrainLimit=5100) um das Modell auf aktuelle Verbrauchsmuster zu fokussieren. Der Hinweis ist für stochastische Haushalte weniger relevant als für strukturierte.

Rauschen Bewertung: merkliches Rauschen, Interpretation mit Vorsicht (borderline)
Drift Bewertung: -
Empfehlung für Retrain: keine
Modellparameter:

Code Auswählen Erweitern

Normierungsgrenzen: PV=13020 Wh, Hausverbrauch: Min=0 Wh / Max=13733 Wh
Trainingsdaten: 10335 Datensätze (Training=8268, Validation=2067)
Architektur: Inputs=119, Hidden Layers=24-16, Outputs=1
Hyperparameter: Learning Rate=0.0030, Momentum=0.5, BitFail-Limit=0.34
Aktivierungen: Hidden=ELLIOT_SYMMETRIC, Steepness=0.3, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Profile=v1_heatpump_active_pv_bev
Zufallsgenerator: Mode=1, Period=10
Modellalter: - h
Trainingsmetriken:

Code Auswählen Erweitern

bestes Modell bei Epoche: 630 (max. 15000)
Training MSE: 0.002404
Validation MSE: 0.001808
Validation MSE Average: 0.001869
Validation MSE Standard Deviation: 0.000094
Validation Bit_Fail: 3
Model Bias: 389 Wh
Model Slope: 0.69
Trainingsbewertung: Retrain
Fehlermaße:

Code Auswählen Erweitern

MAE: 337.05 Wh
MedAE: 176.81 Wh
RMSE: 446.91 Wh
RMSE relative: 62 %
RMSE Rating: acceptable
MAPE: 82.70 %
MdAPE: 26.38 %
R²: 0.61
Der Slope ist also fast angekommen.

Anbei Log und Screenshot.

[DS_Starter]

  ... Model Slope: 0.69 ... Wow.
Jetzt müssen wir über Mittag warten, mein LLM Limit ist aufgebraucht. Falls ich das Thema hier weiter intensiv vorantreibe (wonach es aussieht) werde  ich wohl mal eine Lizenz abschließen müssen. 

Aber deine Trainingsergebnisse/Fortschritte habe ich bereits in die Weiterentwicklung des "Beraters" einfließen lassen. Er soll ja am Ende die richtigen Hilfen geben können.
Kommt im nächsten Contrib-Update einfach mit.

[DS_Starter]

So ...

Was Momentum=0.5 gebracht hat
Die Oszillation ist deutlich gedämpft. Die 100-Epochen-Sprünge sind in Run 4 wesentlich kleiner als in Run 3: bei Epoche 200 springt Val MSE nur noch von ~0.002130 auf 0.002255 (+6%), in Run 3 war der entsprechende Sprung von ~0.002208 auf 0.002265 noch größer. Das Netz kann gefundene Minima besser halten.
Slope 0.64 → 0.69 ist der stärkste Einzelsprung seit Beginn der Optimierung — Momentum war tatsächlich der primäre Slope-Treiber. Val MSE erreicht mit 0.001808 ein neues Optimum, R²=0.61 ebenfalls.

Attempt 2 in diesem Run zeigt ein besonders interessantes Muster: Slope=0.71, R²=0.59 mit Retrain decision=Borderline — das erste Mal überhaupt, dass Slope das 0.7-Limit knackte. Das zeigt, dass die Architektur prinzipiell in der Lage ist, Slope ≥ 0.7 zu erreichen.

Verbleibende Schwäche: RMSE relative
RMSE relative = 62% verfehlt das Limit von 60% noch leicht. Das ist aber nicht mehr die Slope — die ist jetzt grenzwertig akzeptabel. Das verbleibende Problem ist Bias=389 Wh, der den RMSE hochzieht.

Empfehlungen für weiteres Training
Attempt 2 in Run 4 erreichte bereits Slope=0.713 — das zeigt, dass die aktuelle Parameterkombination prinzipiell Slope ≥ 0.7 liefern kann. Das Problem ist keine systematische Parametergrenze mehr, sondern Seed-Varianz. Die Slope-Verbesserungen pro Run werden kleiner (+0.01, +0.03, +0.05) — das klassische Zeichen eines sich abflachenden Optimierungsraums.

Priorität 1: RPROP statt INCREMENTAL
Das ist der einzige Hebel, der noch einen qualitativen Sprung bringen kann. INCREMENTAL mit Momentum akkumuliert Gradienten in feste Richtungen — das erzeugt strukturelle Regression-zur-Mitte bei Peaks. RPROP passt die Schrittweite pro Gewicht adaptiv an und ist gegen diese Sättigung immun:

aiConTrainAlgo=RPROP

Erwartung: Slope könnte stabiler in Richtung 0.72–0.78 steigen, weil RPROP Gewichte in Richtung von Peaks nicht durch Momentum-Trägheit ausbremst. Gleichzeitig entfallen die Shuffle-Sprünge komplett, da kein akkumulierter Gradient vorhanden ist.
Risiko: RPROP kann bei sehr kleinen Datensätzen instabil werden, bei 8268 Trainingsdaten ist das aber kein Problem.

Priorität 2: Steepness leicht erhöhen
hidden steepness = 0.4   # war 0.3
Mit ELLIOT_SYMMETRIC und steepness=0.3 ist die Aktivierung im mittleren Bereich noch relativ flach. Ein leichter Anstieg auf 0.4 erhöht den Gradienten für Extremwerte ohne in Sättigung zu geraten. Nur in Kombination mit Momentum-Reduktion sinnvoll — was bereits umgesetzt ist.

Priorität 3: Learning Rate leicht senken

Code Auswählen Erweitern

learning rate = 0.002   # war 0.003Mit Momentum=0.5 und LR=0.003 ist der effektive Schritt pro Epoche 0.003 / (1 - 0.5) = 0.006. Das ist für feinere Slope-Optimierung grenzwertig hoch. Eine Reduktion auf 0.002 (effektiv 0.004) könnte das Netz näher an Peak-Minima einsinken lassen, ohne grundlegendes Lernverhalten zu ändern. Dieser Hebel ist aber nachrangig gegenüber RPROP.

Fazit
Die klare Empfehlung ist ein RPROP-Testlauf mit gleicher Architektur und steepness=0.4. Wenn RPROP Slope stabil ≥ 0.72 liefert, ist das der neue Default für v1_heatpump*-Profile. Wenn nicht, liegt das Ceiling bei ~0.70 und die slope_min-Grenze sollte auf 0.60 korrigiert werden.

Die Festlegung der slope_min-Grenze wäre dann etwas für mich zur Anpassung des Moduls. Deswegen wäre es wichtig wenn du das Training wie vorgeschlagen wiederholst.

[peterboeckmann]

Hallo Heiko,

Fazit
Die klare Empfehlung ist ein RPROP-Testlauf mit gleicher Architektur und steepness=0.4. Wenn RPROP Slope stabil ≥ 0.72 liefert, ist das der neue Default für v1_heatpump*-Profile. Wenn nicht, liegt das Ceiling bei ~0.70 und die slope_min-Grenze sollte auf 0.60 korrigiert werden.

mit den drei umgesetzten Empfehlungen geht das Training sehr schnell, vermutlich zu schnell:

Bewertungsüberblick:

Code Auswählen Erweitern

Trainingsbewertung: Retrain (Retrain)
Lernverhalten: very_early sehr früh konvergiert (0.1 % Epochenausnutzung)
Einstellhinweise:
Lernrate zu hoch: Lernrate (aiControl->aiConLearnRate) um Faktor 5-10 reduzieren (z.B. von 0.01 auf 0.001-0.002)
Training zu einem anderen Zeitpunkt erneut starten: die zufällige Gewichtsinitialisierung beim Start hat das Ergebnis hier stark dominiert, ein neuer Trainingsstart erzeugt automatisch eine andere Initialisierung und führt meist zu einem deutlich besseren Ergebnis
Architektur möglicherweise zu komplex für die Datenmenge: Verhältnis Trainingsdaten zu Netzparametern beträgt nur 2.5 (Zielwert: 8–20) - das Netz hat mehr Freiheitsgrade als die Daten zuverlässig füllen können; kleinere Architektur wie z.B. 14-8 versuchen (aiControl->aiConHiddenLayers)
Empfohlene Lernrate für die vorgeschlagene Architektur 14-8 mit 119 Inputs: 0.0050 (aiControl->aiConLearnRate)
Große Datenmenge (10337 Datensätze gesamt): falls saisonale Effekte die Prognosequalität beeinträchtigen, Training auf die neuesten Datensätze begrenzen (z.B. aiControl->aiConTrainLimit=5100) um das Modell auf aktuelle Verbrauchsmuster zu fokussieren. Der Hinweis ist für stochastische Haushalte weniger relevant als für strukturierte.

Rauschen Bewertung: merkliches Rauschen, Interpretation mit Vorsicht (borderline)
Drift Bewertung: -
Empfehlung für Retrain: keine
Modellparameter:

Code Auswählen Erweitern

Normierungsgrenzen: PV=13020 Wh, Hausverbrauch: Min=0 Wh / Max=13733 Wh
Trainingsdaten: 10337 Datensätze (Training=8269, Validation=2068)
Architektur: Inputs=119, Hidden Layers=24-16, Outputs=1
Hyperparameter: Learning Rate=0.0020, Momentum=0.5, BitFail-Limit=0.34
Aktivierungen: Hidden=ELLIOT_SYMMETRIC, Steepness=0.4, Output=LINEAR
Trainingsalgorithmus: RPROP, Profile=v1_heatpump_active_pv_bev
Zufallsgenerator: Mode=1, Period=10
Modellalter: - h
Trainingsmetriken:

Code Auswählen Erweitern

bestes Modell bei Epoche: 17 (max. 15000)
Training MSE: 0.004043
Validation MSE: 0.005367
Validation MSE Average: 0.043421
Validation MSE Standard Deviation: 0.001215
Validation Bit_Fail: 2
Model Bias: 439 Wh
Model Slope: 0.72
Trainingsbewertung: Retrain
Fehlermaße:

Code Auswählen Erweitern

MAE: 513.08 Wh
MedAE: 228.03 Wh
RMSE: 570.38 Wh
RMSE relative: 79 %
RMSE Rating: weak
MAPE: 108.59 %
MdAPE: 31.36 %
R²: -0.16
Ich nehme wohl erstmal die LearningRate zurück auf 0.003, oder?

[DS_Starter]

Ja, richtige Entscheidung. Das war nix.
Das sieht nach einem gefundenen Optimum aus.
Ich verifiziere das später nochmal und passe Grenzen im Code an.

Muß erstmal was anderes tun 

Danke erstmal!

[300P]

Ich habe auch mal wieder ein LLM um Hilfestellung gefragt:
(Diesmal war's Google)

Hier als ,,Anleitung" für die kostenlose Fragestellungen bei Registrierung (im gewissen Rahmen)

Code Auswählen Erweitern

NN-Analyse
FHEM - Modul 76_solarforecast.pm
Version aus dem Contrib V2.8.0
Ergebnisbewertung nach Retrain und XX-Stunden Laufzeit

#####
Hier das letzte Ergebnis einfügen
#####


Vor dem Absenden hab ich dann noch einen Screenshot vom Verbrauch/CON-Forecast hochgeladen.


Da kamen m.M.n. sofort gute Empfehlungen was man ändern sollte:

Code Auswählen Erweitern

Das neuronale Netz zeigt nach dem Retrain solide Ansätze, läuft aber noch nicht im optimalen Bereich.
Die Kombination aus einem stabilen Drift-Verhalten und einer frühzeitigen Konvergenz deutet darauf hin, dass das Modell zwar sicher steht, aber sein volles Lernpotenzial nicht ausschöpft.

Hier ist die detaillierte Analyse der Stärken, Schwächen und konkreten Stellschrauben.
📊 Die wichtigsten Erkenntnisse
Das Hauptproblem (Early Stopping):
Das Netz bricht das Training bereits bei Epoche 1481 von 15000 ab (nur 9,9 % Ausnutzung). Es konvergiert zu früh. Die Lernrate (0.0001) und das Momentum (0.5) sind sehr defensiv eingestellt.

Prognosequalität (Grenzwertig):
Ein R² von 0.48 bedeutet, dass das Modell aktuell nur knapp die Hälfte der Varianz im Verbrauch erklären kann. Ein relativer RMSE von 49 % und ein MAPE von 35 % sind für eine Wärmepumpen-Vorhersage noch ausbaufähig.

Positiv (Gute Generalisierung):
Der Validation-MSE (0.0070) ist besser als der Trainings-MSE (0.0086). Das Modell überreizt nicht (kein Overfitting). Zudem ist die Drift absolut stabil (Score: 1.10 / "stable").

🛠 Konkrete OptimierungsschritteUm die Vorhersagegenauigkeit (RMSE/MAPE) zu verbessern und dem Netz mehr Raum zum Lernen zu geben, sollten Sie folgende Parameter im FHEM-Modul anpassen:

1. Konvergenz verlangsamen (Mehr Epochen erzwingen)
Da das Netz zu schnell aufhört zu lernen, müssen Sie die Steifigkeit der Aktivierungsfunktion reduzieren oder das Netz leicht vergrößern.
aiConSteepness senken:
Reduzieren Sie den Wert von 0.9 auf 0.8 oder 0.7.
Das flacht die Aktivierungsfunktion ab und erzwingt eine feinere, langsamere Anpassung der Gewichte.

Netzarchitektur erweitern:
Die aktuelle Struktur 14-8 (Hidden Layers) ist recht kompakt für 112 Inputs. Erhöhen Sie moderat über aiConHiddenLayers, z. B. auf 20-10, um dem Netz mehr Kapazität für die komplexen Muster der Wärmepumpe zu geben.

2. Datenbasis fokussieren
Mit 10.412 Datensätzen hat das Modell eine sehr große Historie. Da es sich um das Profil v1_heatpump_active_pv handelt, verzerren alte saisonale Daten (z. B. tiefer Winter vs. Sommer) die aktuelle Prognose.

Einstellung:
Setzen Sie aiControl->aiConTrainLimit auf etwa 5200. Dadurch konzentriert sich das Netz auf die jüngeren, relevanteren Verbrauchsmuster.


3. Rauschen ("borderline") abfedern
Das registrierte Rauschen ist spürbar, was bei Haushaltsstrom normal ist. Der aktuelle BitFail-Limit von 0.34 passt gut. Sollte das Rauschen im nächsten Lauf steigen, kann das Limit testweise auf 0.36 angehoben werden, um "Ausreißer" im Training nicht überzubewerten.

📉 Visueller Abgleich mit dem Screenshot

Das FHEM-Frontend zeigt im mittleren (roten) Balkendiagramm die Verbrauchswerte, die starke Peaks (bis über 3000 W) aufweisen – typisch für das Takten einer Wärmepumpe oder Haushaltsgroßgeräte.

Da das Modell aktuell einen Model Bias von 524 Wh aufweist, neigt das KI-Modell dazu, den Verbrauch im Schnitt etwas zu überschätzen oder Peaks zu glätten. Die oben genannten Schritte helfen dem Netz, diese harten Kanten besser nachzubilden.


Möchten Sie nach der Umsetzung dieser Anpassungen die Änderung der MSE-Werte analysieren, oder benötigen Sie die exakten FHEM-Befehlszeilen für die Parameteränderungen

Was will man mehr ?