76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Begonnen von DS_Starter, 11 Februar 2024, 14:11:00

Vorheriges Thema - Nächstes Thema

peterboeckmann

#6435
Hallo Heiko,

Meine Visualisierung anbei.
Das sieht mir im Moment für die Nachtstunden recht niedrig aus und für den Tag tendenziell etwas zu hoch. Aber mal abwarten.
Edit: bei PV-Überschuss laufen im Keller zwei Luftentfeuchter und bei den Temperaturen morgen sicher auch wieder die Klimaanlage. Daher sind die gut 2 kWh/h nicht total unrealistisch.

Die Steepness habe ich tatsächlich in 0.1-Schritten von 0.9 auf 0.1 an abgesenkt.
Und die Hidden Layers habe ich bis 26-16 vergrößert, bis dem Modul die Komplexität zu hoch wurde und dann wieder auf 22-12 verkleinert.
Alles aufgrund der Meldung:
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 erfordertDiese kam jetzt beim nächsten Retrain mit unveränderten Parametern übrigens wieder.
Ist es überhaupt sinnvoll, ohne Änderung irgendwelcher Parameter und ohne viele neue Daten aufgezeichnet zu haben, neu zu trainieren?

Das Log habe ich heute nicht mitlaufen lassen, kann ich morgen aber nochmal tun. Welches Flag war das nochmal im attr ctrlDebug? aiProcess?

Viele Grüße,
Peter
MQTT,Modbus,HTTPMod,DbLog,LaCrosse,SolarForecast,TelegramBot,Twilight,vitoconnect,withings
fhem,fhempy,debmatic
Debian
RaspberryPi5,HomeMatic,HomeMaticIP,Shelly,JeeLink,SignalDuino,ZWDongle,SONOS,alexa,Hue,tradfri,MobileAlerts,Siemens Home Connect,Roborock S50,Wallbox,Harmony,Tuya Smartlife

300P

Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast| DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP| ESP32_AI_on_the_Edge|ESP32CAM usw.

DS_Starter

Das Problem mit der frühen Konvergenz kann man vllt. auch mit anderen Einstellungen lösen. Muß man sich Trainingslog mal anschauen.

ZitatIst es überhaupt sinnvoll, ohne Änderung irgendwelcher Parameter und ohne viele neue Daten aufgezeichnet zu haben, neu zu trainieren?
Ja, ist es. Es wird kaum beachtet, aber das NN bekommt mit jedem Trainingslauf einen sogenannten Seed, der jedesmal anders ist:

2026.06.22 21:22:08.338 1: openMeteo1 DEBUG> First attempt 0 with Seed=28704

Die Bedeutung kann ich nicht besser beschreiben als das LLM meines Vertrauens:

Bedeutung des wechselnden Seeds beim Trainingsstart
Der Seed steuert den Zufallszahlengenerator, der beim FANN-Training an zwei entscheidenden Stellen wirkt:

1. Gewichtsinitialisierung
Vor dem ersten Epoch werden alle Netzgewichte zufällig initialisiert. Der Seed bestimmt diese Startpositionen im Gewichtsraum. Verschiedene Seeds → verschiedene Startpunkte → potenziell verschiedene lokale Minima, in die der Gradient Descent konvergiert.

2. Trainings-Datenmischung (Shuffling)
Falls dein Training die Samples vor jedem Epoch mischt (bei INCREMENTAL oft implizit), beeinflusst der Seed auch die Reihenfolge der Präsentation.

Was ein wechselnder Seed bedeutet
Pro Lauf unterschiedliche Konvergenz:

- Jeder Trainingslauf startet von einem anderen Punkt im Gewichtsraum
- Das Netz kann in unterschiedliche lokale Minima laufen
- Ergebnisse (R², RMSE, Slope) variieren zwischen Läufen ohne Änderung der Daten oder Hyperparameter


ZitatDas Log habe ich heute nicht mitlaufen lassen, kann ich morgen aber nochmal tun. Welches Flag war das nochmal im attr ctrlDebug? aiProcess?
Ja, der ist es.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

#6438
@Peter,

die starke Dynamik zwischen Tag und Nacht resultiert eventuell aus dem gesetzten Flag "pv".
Das NN assoziiert damit steigende Verbräuche bei PV bzw. das Gegenteil. Vllt. wird dieser Zusammnhang bei dir überbewertet -> ausprobieren.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

peterboeckmann

Hallo Heiko, hallo 300P,

anbei das TrainingsLog.

Keine Ahnung, woher die ganzen geskippten Datensätze kommen.
Da sie aber geskippt werden, sollten sie ja keinen Einfluss auf das Training haben, oder?

Viele Grüße,
Peter
MQTT,Modbus,HTTPMod,DbLog,LaCrosse,SolarForecast,TelegramBot,Twilight,vitoconnect,withings
fhem,fhempy,debmatic
Debian
RaspberryPi5,HomeMatic,HomeMaticIP,Shelly,JeeLink,SignalDuino,ZWDongle,SONOS,alexa,Hue,tradfri,MobileAlerts,Siemens Home Connect,Roborock S50,Wallbox,Harmony,Tuya Smartlife

DS_Starter

Die geskippten DS haben keinen EInfluß. In diesen DS ist "con" nicht gesetzt (con=undef), also kein Verbrauch gespeichert. Vllt. war er negativ, was dazu führt dass das Modul ihn nicht speichert weil unsinnig.

Jetzt die Analyse des Logs mit konkreten Empfehlungen zur Verbesserung:

Analyse des Logs

Warum kein Snap bei Epoche 500–700?
Das ist eine wichtige Beobachtung. Der letzte Snap in Attempt 0 lag bei Epoche 449:

Val MSE = 0.003544, Val MAE = 0.032382, Val MedAE = 0.020755

Bei den 100-Epochen-Reports danach:
E500: Val MSE=0.003481  Val MAE=0.036487  Val MedAE=0.026497
E600: Val MSE=0.003351  Val MAE=0.036766  Val MedAE=0.027002
E700: Val MSE=0.003132  Val MAE=0.036487  Val MedAE=0.026883
Val MSE verbessert sich (0.003544 → 0.003132), aber Val MAE und MedAE verschlechtern sich deutlich (0.032 → 0.036+). Da der Snap-Metric auf einer MAE/MedAE-Composite-Größe basiert, und nicht auf reiner Val MSE, triggert kein Snap.
Was hier passiert: Nach Epoche 449 beginnt das Netz unter INCREMENTAL, Ausreißer stärker zu drücken (MSE-Reduktion), aber auf Kosten der mittleren Fehler (MAE-Anstieg). Das ist ein klassisches Overfitting-auf-Outliers-Muster — das Netz opfert die Median-Qualität für wenige Extrempunkte.

Frühe Konvergenz und Low-Slope-Problem
Über alle 4 Attempts ist das Muster konsistent:
AttemptBest EpochSlopeR²Val MSE04490.270.340.003493112590.610.520.002519213780.610.520.002518311490.600.520.002523
Slope ~0.60 ist systematisch zu niedrig (Limit 0.7..1.3) — das Modell unterschätzt Peaks konsistent. R²=0.52 ist akzeptabel, aber Slope zeigt eine strukturelle Regression-zur-Mitte.

Parameterempfehlungen

1. Hidden Steepness erhöhen: 0.1 → 0.3
Das ist der wichtigste Hebel. Mit steepness=0.1 ist die SIGMOID_SYMMETRIC extrem flach — die Aktivierung reagiert kaum auf Eingabeunterschiede, Gradienten fließen schwach. Das drückt die Slope nach unten, weil das Netz Extreme nicht lernen kann.
hidden steepness=0.3   # oder 0.5 als zweiter Test

2. Learning Rate leicht erhöhen: 0.001 → 0.003
Alle Attempts stagnieren bei Val MSE ~0.0025. Die extrem niedrige LR in Kombination mit Momentum=0.7 führt zu sehr langsamer Fortbewegung — das Netz bleibt in einem flachen Bereich hängen, der zwar stabil, aber suboptimal ist.
learning rate=0.003

3. Netzarchitektur: 22-12 → 22-16 oder 24-14
10322 Trainingsdatensätze mit dem v1_heatpump_active_pv_bev-Profil haben viele Feature-Interaktionen (Lag-Features, BEV-Features, Temperature-Features). Die zweite Schicht mit nur 12 Neuronen kann ein Engpass sein.

4. Momentum reduzieren: 0.7 → 0.5
Bei INCREMENTAL mit hohem Momentum und niedriger LR akkumuliert sich der Impuls in Richtungen, die schon erkundet wurden — das erschwert das Verlassen flacher Plateaus.

Zusammenfassung der Prioritäten
# Primärer Test:
hidden steepness=0.3   # war 0.1
learning rate=0.003    # war 0.001

# Sekundärer Test falls unzureichend:
hidden Neurons=22-16   # war 22-12
learning momentum=0.5  # war 0.7

Die Erwartung: Steepness=0.3 + LR=0.003 sollte die Slope von 0.60 in Richtung 0.80–0.90 bringen und das MAE/MedAE-Plateau nach ca. Epoche 450 auflösen.

Ich persönlich würde auch auf SIGMOID umstellen.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter