76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Hallo Oelidoc,

ich habe zwar keine solche Anlage und kann keine Erfahrung einbringen, aber ich steuere mal das Ergebnis meiner kurzen Recherche bei.
Vielleicht hilft dir das schon etwas und kannst es mit BYD Usern verifizieren:

Du stößt vermutlich an Grenzen der SMA/BYD‑Logik, die SolarForecast nicht übersteuern kann.
Was vermutlich passiert

CmpBMS ist nur ein ,,Wunschzettel" an den WR: 
Die Registergruppe 40793–40801 liefert dem STP SE Zielwerte (Set_LadeP_max, ChargeAbort etc.), aber der WR/BYD‑BMS darf diese ignorieren, wenn interne Schutz‑ oder Pflegealgorithmen greifen (Top‑Balancing, SoC‑Kalibrierung, Zellpflege). Das ist in den SMA‑Unterlagen sinngemäß so beschrieben: das Batteriemanagement hat Vorrang vor externen Vorgaben.

Set_LadeP_max=0 ist kein ,,hartes Stoppsignal": 
Bei SMA steht 0 in vielen Leistungs‑Registern für ,,keine Begrenzung" bzw. ,,Default verwenden". Es ist gut möglich, dass der WR 0 bei Set_LadeP_max nicht als ,,Ladeleistung verbieten", sondern als ,,kein Limit" interpretiert und deshalb mit seiner internen Kennlinie weiter bis 100 % lädt.

Abort wirkt nur in bestimmten Modi:
Einige Abort‑Flags greifen nur bei Netzladung oder bestimmten Betriebsarten, nicht bei PV‑Direktladung oder bei vom BMS initiierten Pflegezyklen. Wenn der BYD‑BMS dem WR sagt ,,jetzt bitte vollmachen/top‑balancen", hat dieses Kommando Vorrang vor deinem Modbus‑Abort.

SMA/BYD wollen regelmäßig 100 % sehen: 
Viele Hochvolt‑Speicher verlangen gelegentlich eine Vollladung, um Zellbalancing und SoC‑Kalibrierung zu machen. Das passiert typischerweise im Bereich 90–100 % und dauert genau in der Größenordnung, die du beobachtest (15–20 min). Externe Leistungsbegrenzungen werden in dieser Phase oft übersteuert.

Was du konkret tun kannst
Nicht mit 0 arbeiten, sondern mit kleinem Limit testen: 
Statt Set_LadeP_max=0 z.B. einen sehr kleinen Wert (z.B. 50–100 W) schreiben und schauen, ob der WR dann tatsächlich die Ladeleistung reduziert. Wenn er dann brav begrenzt, weißt du: 0 bedeutet ,,kein Limit", nicht ,,Stop".

WR‑seitige SoC‑Ziele prüfen: 
Im STP‑SE gibt es teils Einstellungen für ,,Betriebsreserve", ,,Backup‑Reserve" oder minimale/maximale SoC‑Ziele. Wenn dort z.B. 100 % als Ziel hinterlegt sind, wird der WR versuchen, das zu erreichen, egal was SolarForecast vorgibt.

Akzeptieren, dass die letzten 10 % BMS‑Domäne sind: 
Für Verschleißreduzierung ist es meist ausreichend, den Akku im Alltag zwischen z.B. 20–90 % zu halten. Wenn BYD/SMA sich gelegentlich die 90–100 % für Balancing ,,nehmen", ist das eher positiv für Zellgesundheit und SoC‑Genauigkeit, auch wenn es deiner Wunschlogik widerspricht.

LG,
Heiko

[oelidoc]

Hallo Heiko,
vielen Dank für deine wie immer super verständliche und ausführliche Erklärung.

Akzeptieren, dass die letzten 10 % BMS‑Domäne sind: 

Ich werde deinen Rat befolgen und lediglich mal Set_LadeP_max=50 versuchen.

Liebe Grüße

oelidoc

[TheTrumpeter]

So, ich habe den Vormittag über noch weitere Anpassungen gemacht. Alle Empfehlungen, die von Gemini nun noch kommen, sind nicht umsetzbar bzw. sinnvoll.
Damit belasse ich das erstmal so und beobachte, wie es sich mit weiteren Daten zur Kühlung entwickelt.



### 📊 FANN-Analyse & Optimierungs-Bericht (Modul 76_SolarForecast.pm)

**Status des letzten Trainingslaufs (07.08.2026):** `Trainingsbewertung: Retrain`
*  **Laufzeit:** 2.004 Sekunden (ca. 33 Min.) | **Algorithmus:** INCREMENTAL
*  **Modell-Güte:** R² = 0.53 (Wärmepumpen-Grundstruktur steht felsenfest)
*  **Fortschritt:** Das Lockern der Fehlertoleranz (`BitFail-Limit=0.36`) hat gegriffen. Die `Validation Bit_Fail` sind spürbar von 63 auf **48** gesunken. Das Lernverhalten ist mit **18.3 % Epochenausnutzung** sehr gesund.

---

#### 1. 🔍 Wo liegen aktuell die größten Schwachstellen?

*  **Der unnachgiebige "Feature-Overkill" (`123 Inputs`):**
    Das Netz wird mit Eingangskanälen überflutet. Die ideale 14-7-Architektur muss dadurch zu viele Verknüpfungen berechnen. Die echten, harten Schaltsignale der Wärmepumpe gehen mathematisch im Rauschen unter.
*  **Starres, blockiertes Overfitting (`MSE diff = 0.006542 > 0.005`):**
    Da das Netz durch die höhere Aktivierungssteilheit (`Steepness=1.5`) schärfer trennt, lernt es die Rauschkomponenten der 123 Inputs im Trainingsset noch präziser auswendig. Der Validierungsfehler zieht nicht nach und blockiert die Modulfreigabe.
*  **Gedeckelte Modell-Steigung (`ModelSlope = 0.54`):**
    Die Peak-Verbräuche der Wärmepumpe (z. B. Warmwasser- oder Heiztaktungen) werden im Forecast systematisch geglättet. Das harte Profilkriterium (`slope_min=0.60`) bleibt unerreichbar.

---

#### 2. 🛠� Die wirksamsten Maßnahmen mit dem größten Hebel

*  **Maßnahme 1: Radikale Feature-Reduktion (Inputs reduzieren) ⬇️**
    *  *Hebel:* Dies ist die einzig verbleibende Stellschraube. Jedes gestrichene historische Feature (z. B. unbedeutende Vergangenheitsstunden) eliminiert dutzende synaptische Gewichte. Das Overfitting bricht zusammen und das Modul erteilt die Freigabe.
*  **Maßnahme 2: Reduktion der Prognose-Features (Forecast-Horizonte reduzieren) ⬇️**
    *  *Hebel:* Verringert die Anzahl der parallel verarbeiteten Wetterstunden in die Zukunft, um die mathematische Last von den Eingangsschichten des Netzes zu nehmen.

---

#### 3. ⚠️ Hinweise auf strukturelle Probleme

*  **Reine Datensättigung auf der Eingangsseite (Ausoptimiert):**
    Es liegt kein Hyperparameter- oder Algorithmusproblem vor. Das Lernverhalten ist numerisch stabil, was die extrem geringe Standardabweichung der Validierung (`0.000020`) beweist. Das strukturelle Problem ist ausschließlich die mangelnde Relevanzdichte der 123 Eingangsdaten im FHEM-Modul. Jedes weitere Tuning an den Hyperparametern verschiebt nur noch Nachkommastellen.

---

#### 4. 🚀 Konkrete, umsetzbare nächste Schritte

Da das rein mathematische Netz-Tuning abgeschlossen ist, muss nun zwingend die FHEM-Konfiguration der Datenquellen angepasst werden, um die Freigabe zu erzwingen:

1.  **Historienstunden im FHEM-Modul hart kappen:**
    Suche in den Attributen des Moduls nach Parametern wie `aiConHistoryHours`. Falls dieser Wert auf 24 oder höher steht, konsequent auf **6 oder maximal 12 Stunden** herabsetzen. Verbrauchsmuster von vor über einem Tag enthalten für die Wärmepumpen-Steuerung keine verwertbare Signalstärke.
2.  **Redundante Wetterdaten-Inputs deaktivieren:**
    Überprüfe, ob mehrere Wetter- oder Strahlungsprognosen (z. B. DWD und Proplanta parallel) aktiv in das Netz einspeisen. Ungenutzte Kanäle abschalten. **Ziel: Beim nächsten Trainingsstart muss die Anzeige `Inputs` zweistellig sein (unter 90).**
3.  **Architektur und Hyperparameter einfrieren:**
    Belasse alle anderen Werte exakt so, wie sie jetzt sind (`14-7` Hidden Layers, `INCREMENTAL`, `Learning Rate = 0.0001`, `Momentum = 0.7`, `Steepness = 1.5`, `BitFail-Limit = 0.36`). Die Struktur passt perfekt, sobald die Inputs abgemagert sind.
4.  **Abschließendes Training starten:**
    Triggere nach der Bereinigung der Inputs ein manuelles Retrain. Die MSE-Differenz wird sofort unter 0.005 kollabieren, die Slope über 0.60 springen und die `Retrain`-Blockade gelöst.

[DS_Starter]

Du könntest uns bei Gelegenheit auch mal Screenshots von den realen Balkendiagrammen zeigen die sich nun mit dem Modell ergeben.
Es sollte deutlich anders als bisher aussehen, auch wenn es sicher noch Verbesserungspotenziale geben wird.