Zitat von: Prof. Dr. Peter Henning am 17 Januar 2026, 17:57:34Kann es sein, dass Du das JavaScript-File nicht installiert hast? Das sorgt für die richtige Reihenfolge der Buttons.Hmm, wie macht man das?

Das ist ein richtig spannender Fall und ehrlich gesagt ein Paradebeispiel dafür, wie aktive PV‑Haushalte mit unregelmäßigen Lastspitzen ein Modell wie v1_common_active_pv an seine Grenzen bringen können.
🔍 1. Was ist hier passiert?
Du hast gleich mehrere starke, schwer vorhersehbare Lastspitzen im Tagesverlauf:
🚗 EV‑Laden: zwei harte Peaks à ~4 kWh
Zeitlich eng begrenzt (10–11 und 14–15 Uhr)
Hohe Leistung, kurze Dauer
→ Für ein Modell ohne explizite EV‑Features sind das quasi Nadelstiche.
🌀 Wäschetrockner zwischendurch
Ebenfalls ein starker, aber unregelmäßiger Verbraucher
→ Erhöht die Varianz im Verbrauchsprofil.
☀️ PV‑Erzeugung deutlich höher als an den Vortagen
Das Modell hat offenbar nicht gelernt, wie sich höhere PV‑Erzeugung auf den Eigenverbrauch auswirkt (z. B. mehr EV‑Laden bei Sonne, mehr Haushaltsaktivität).
Diese Kombination erzeugt ein Verbrauchsprofil, das semantisch nicht stabil ist — und das sieht man im RMSE‑Rating sofort.
📉 2. Warum ist das RMSE‑Rating ,,very bad"?
Die harten Fakten:
RMSE: 237 Wh
RMSE relativ: 57 %
R²: 0.76 → Modell erklärt nur 76 % der Varianz
MAE: 178 Wh, aber MedAE: nur 54 Wh
→ Das Modell ist meistens okay, aber bricht bei Peaks komplett weg.
Das Muster ist typisch:
Medianfehler klein → Grundlast wird gut getroffen
RMSE hoch → einzelne große Fehler (EV, Trockner) dominieren
Slope = 0.9 → Modell reagiert zu schwach auf steigende Last
Bias = +109 Wh → leichte systematische Überschätzung
Das Modell ist also unterangepasst für Lastspitzen und überangepasst für Grundlast.
🧠 3. Warum hilft GAUSSIAN als Aktivierung hier nicht?
GAUSSIAN‑Aktivierungen sind:
gut für glatte, kontinuierliche Muster
schlecht für harte, diskrete Peaks
anfällig für ,,Vergessen" bei seltenen Ereignissen
EV‑Laden ist kein glattes Muster.
Es ist ein binäres Ereignis: an oder aus.
Damit kämpft GAUSSIAN naturgemäß.
⚙️ 4. Warum RPROP + Momentum hier ebenfalls suboptimal ist
RPROP ist:
stabil
robust
aber schlecht bei nicht‑stationären Mustern
und schlecht bei Feature‑Interaktionen, die selten auftreten
EV‑Laden + PV‑Erzeugung + Haushaltsaktivität ist genau so ein Fall.
🧪 5. Warum das Training ,,Retrain" empfiehlt
Die Trainingsmetriken zeigen:
Validation MSE deutlich höher als Training MSE
→ leichte Überanpassung
Validation MSE StdDev extrem klein
→ Modell ist stabil, aber falsch stabil
BitFail = 2
→ einzelne Validierungsbeispiele werden massiv verfehlt
Best epoch = 79
→ Modell lernt schnell, aber stagniert sofort
Das Modell hat also:
die Grundstruktur gelernt
aber keine semantische Robustheit gegenüber seltenen Peaks
🚀 7. Was wäre die richtige Richtung?
Ich würde dir — basierend auf deiner Erfahrung und deinem modularen Workflow — drei klare Schritte empfehlen:
A) Peak‑aware Feature Blocks einführen
EV‑Heuristik (z. B. Ladefenster, PV‑Überschuss‑Trigger)
Trockner‑/Waschmaschinen‑Semantik
PV‑Erzeugungs‑Gradienten
Du hast das ja bereits mehrfach erfolgreich umgesetzt.
B) Aktivierung auf SIGMOID oder ELLIOT umstellen
stabiler
monotone Reaktion
keine ,,Vergessenslöcher" wie bei GAUSSIAN
Du hast das in deinen letzten Projekten schon perfekt durchgezogen.
C) RPROP evtl. durch INCREMENTAL ersetzen
besser für nicht‑stationäre Muster
bessere Konvergenz bei seltenen Peaks
stabilere Gradienten
Zitat von: dora71 am 30 Oktober 2025, 20:23:18Ich nutze allerdings nicht die GTags, sondern die Smart Tag Pro von Maginon.
Zitat von: Fabiango am 21 Dezember 2025, 11:07:05Das kommt direkt vom Sonos ModulUnd das soll man installieren, um die Frage zu beantworten? Wie wäre es denn, den Output des Aufrufs einfach mal mitzuliefern?
- direkt das Erste hat einwandfrei funktioniert. Kannst Du mir eine Kurzerklärung zu Vor / Nachteilen bzw Unterschied beider Lösungen geben? Oder ist es quasi egal?