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.

[300P]

Alle Empfehlungen, die von Gemini nun noch kommen, sind nicht umsetzbar bzw. sinnvoll.

Ich bin inzwischen bei mir bei der geringen Zahl von "aiConHiddenLayers=8" gelandet -rein durch "füttern" von Gemini und ChapGPT so "etwas" eigenem Gehirnschmalz. Also nicht immer nur umsetzen wollen was Gemini dir sagt !!!
Aktuell schraube ich nur noch an 3 Werten "rum"

aiConBitFailLimit=0.41  -> allein um die "Bemerkung dazu zum Retrain hierdurch zu vermeiden....
aiConLearnRate=0.0005    -> je nachdem wie kurz oder lang die Berechnungen / Epochen genutzt werden ;
aiConMomentum=0.3        -> von hoch 0.8 bis tief 0.3 - je nach Ergebnis und meinem Bauchgefühl

Code Auswählen Erweitern

aiConActFunc=ELLIOT_SYMMETRIC
aiConActivate=1
aiConAlpha=0.8
aiConBitFailLimit=0.41
aiConHiddenLayers=8
aiConLearnRate=0.0005
aiConMomentum=0.3
aiConProfile=active,heatpump,pv
aiConSteepness=1.0
aiConTrainAlgo=INCREMENTAL
aiConTrainLimit=0
aiConTrainStart=70:9
aiStorageDuration=3600
aiTrainStart=3
aiTreesPV=30
geminiAPIkey=XYZ



Ergebnis aktuell:

Code Auswählen Erweitern

Allgemeine Informationen
- trainiert mit Modulversion: 2.9.4
- letztes KI-Training: 05.08.2026 22:54:49 (Laufzeit in Sekunden: 969)
- KI Abfragestatus: ok
- letzte KI-Ergebnis Generierungsdauer: 136.65 ms
- Verbrauchernummer Wärmepumpe: 07,08

Bewertungsüberblick
- Trainingsbewertung: Retrain (slope=0.5987 < slope_min=0.60)
- Data-Parameter-Ratio Bewertung: ok
- Lernverhalten: gesundes Lernverhalten (6.2 % Epochenausnutzung)
- Rauschen Bewertung: merkliches Rauschen, Interpretation mit Vorsicht (borderline)
- Drift Bewertung: low
- Empfehlung für Retrain: keine

Modellparameter
- Normierungsgrenzen: PV=9975 Wh, Hausverbrauch: Min=0 Wh / Max=6970 Wh
- Trainingsdaten: 11450 Datensätze (Training=9160, Validation=2290)
- Architektur: Inputs=123, Hidden Layers=8, Outputs=1
- Hyperparameter: Learning Rate=0.0001, Momentum=0.3, BitFail-Limit=0.41
- Aktivierungen: Hidden=ELLIOT_SYMMETRIC, Steepness=1.0, Output=LINEAR
- Trainingsalgorithmus: INCREMENTAL, Profile=v1_heatpump_active_pv (Haushalt mit Wärmepumpe und/oder Klimaanlage, PV-gesteuertem Lastmanagement, ausgeprägten Tages-/Verbrauchsrhythmen)
- Zufallsgenerator: Mode=1, Period=25
- Modellalter: 40 h

Trainingsmetriken
- bestes Modell bei Epoche: 923 (max. 15000)
- Training MSE: 0.008572
- Validation MSE: 0.005950
- Validation MSE Average: 0.005962
- Validation MSE Standard Deviation: 0.000006
- Validation Bit_Fail: 4
- Data Parameter Ratio: 11.439
- Model Bias: 361 Wh
- Model Slope: 0.60
- Trainingsbewertung: Retrain

Fehlermaße der Prognosen
- MAE: 367.11 Wh
- MedAE: 247.59 Wh
- RMSE: 468.35 Wh
- RMSE relative: 60 %
- RMSE Rating: acceptable
- MAPE: 39.13 %
- MdAPE: 29.73 %
- R2: 0.51

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

Drift-Kennzahlen (berechnet ab Modellalter > 6 h)
- Analysefenster: 96 h
- Drift RMSE Ratio: 1.37
- Semantic Ratio: 0.46
- Slope Reference: 1.00
- Slope Live: 0.39
- Slope Drift: 0.394
- Bias Reference: 0
- Bias Live: 528.96
- Bias Drift: 528.96
- Score: 0.94
- Index: 1.38
- Drift Bewertung: low
- Empfehlung für Retrain: keine
- letzte Rekalibrierung: -

Ich nutze immer die gleiche Chats mit einem "Dummy"-User per sicherer VPN Verbindung von irgendwo auf der Welt in der LLM aber erst wenn mindesten 60 Stunden Laufzeit nach einem Update aufgelaufen sind!!!!!
Vorher wird alles mögliche wegen der Veränderungen im SF-Modul bemängelt (zu steile Anstiege etc.. usw.)- aber dann fängt alles an sich zu fangen und ergibt dann wieder:

Code Auswählen Erweitern

Hist=[low,mild,mild,mild,mild,mild,low,low,low,mild,mild,mild,low,low,low,low,low,low,low,low] | Retrain=none (-)
Die LLM kennt die aiControl, die BWR/WR, die Strings, die Consumer, eigentlich fast die ganze SF-Konfiguration.
Dadurch bekomme ich n.m.M. inzwischen sehr gute Vorgaben von den LLM.

Wenn Dinge vorgegeben werden die nicht einstellbar sind - Onlinehilfe des Parameters zur Info dazugeben und sagen das geht so nicht umzusetzen....auch bei "Altersdemnenz" der LLM meckern er solle aufpassen und nicht alles immer wieder vergessen was ihm mitgeteilt wurde.....

Aktuell bin ich zufrieden mit der Vohersage (+/- 10 %)

Bin aber auch schon sehr gespannt wenn die Heizsaison anfängt.....was dann wieder an Turbulenzen kommt wird da die alten Werte der WP ja eigentlich durch die erzwungene "Neuerstellung" bei einem Update wohl weg sind.... ?!?
Aber dafür habe ich im Gegenzug auch aufgerüstet. Neben der WP (mit WW) kam noch Klimaanlage, Ceran-Kochfeld, E-Grill mit Terrasse, Kombi Wohnzimmer/Esszimmer und meinen kleinen Haus-IT-Bereich mit Shellys bzw. alten EM zur Messwerterfassung hinzu bzw. wurde damit bestückt.

Das waren dann schon inklusive der SF-Neuerungen in diesem Jahr so viele Veränderungen das ich jetzt auf gute CON-Vorhersagewerte im Winter hoffen kann 

[Wolle02]

Aber die grundlegende Schwierigkeit ist, dass der SOC der BEV-Batterie erst dann verfügbar ist wenn der BEV angesteckt ist. Für eine Prognose im Vorfeld - also noch kein BEV angeschlossen, aber wir wollen trotzdem vorhersagen wann er geladen wird - fehlt diese Info einfach.

Moin Heiko,

das ist aber nicht generell so. Meine OpenWB Wallbox hat ein Renault-Plugin über den der aktuelle SoC regelmäßig bei Renault abgeholt wird (das Auto telefoniert ja nach Hause). Das heißt ich habe bei mir ein Reading in dem immer der aktuelle SoC drinsteht, unabhängig davon ob das Auto angesteckt ist oder nicht (ist zwar a bissel buggy, weil manchmal liefert Renault auch für eine Zeit lang 100% zurück, obwohl das gar nicht stimmt; aber größtenteils funktioniert das).
Müssten andere vielleicht auch mal in ihren Wallboxen schauen. Es gibt ja auch Software wie evcc mit der man alle möglichen Wallboxen steuern kann. evcc bietet solche SoC-Plugins auch so viel ich weiß.