76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[300P]

So - Sauna-Verbrauchs-Exzess ist beendet
Batterien sind leergelutscht.

Das ist ja fast so, als ob ich ein kleines BEV laden würde....     
Vielleicht sollte ich doch noch irgendwann einmal der Sauna einen Zähler verpassen.

[DS_Starter]

Vielleicht sollte ich doch noch irgendwann einmal der Sauna einen Zähler verpassen.

Ja. 


Ich habe soeben die V 2.6.8 eingecheckt. Sie ist wie üblich morgen früh verfügbar.
Die Drift-Funktion habe ich noch etwas nachgebessert und mit aiProcess_long gibt es noch mehr Ausgabe zur Analyse:

Code Auswählen Erweitern

2026.05.11 23:00:05.478 1: SolDwd DEBUG> DRIFT SAFETY [con]: block=none
  -- RMSE Analysis --
     rmse_rel_ratio=3.388 | dynamic_limit=4.950 | margin=1.562 ok
     Limit Composition: base=4.0 | peak_part=0.188 (peak_ratio=0.188) | sem_part=0.263 (sem_ratio=0.958) | var_part=0.500 (slope_var=3.76408)
  -- Slope Analysis --
     slope_live=0.217 | slope_drift=0.255 | slope_rel_drift=0.745 | slope_var=3.76408
     slope_var_limit=8.94448 | var_ratio=0.42 ok
  -- Bias Analysis --
     bias_live=766.6 | bias_limit=670.8 | bias_ratio=1.14 !! ABOUT LIMIT !!
     quant30=559.0 | quant90=1068.0 | median_load=668.0
  -- Context --
     drift_score=3.420 | bias_drift_norm=2.058 | bias_var_norm=0.332
     peak_ratio=0.188 | sem_ratio=0.958
2026.05.11 23:00:05.479 1: SolDwd DEBUG> DRIFT [con]: Flag=moderate | Block=0 | SlopeLive=0.217 | DriftSlope=0.255 | BiasLive=766.63 | DriftBias=-169.89 | RMSErelLive=50.8 | RMSErelRatio=3.39 | BiasVarNorm=0.33 | DriftIndex=2.81 | DriftScore=3.42 | Zone3Hours=2 | Zone3Reset=0 | Hist=[moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderat


[300P]

Guten Morgen Heiko,

augenscheinlich ist die NN-CON-Vorhersage (aktuell -1.5% CON-Abweichung) trotz Blockieren der Rekalibrierung immer noch gut wenn es keine Ausnahmefälle (Sauna-Excesse  ) gibt.
Ich stehe bis heute Morgen noch bei der V2.6.7 - Update Contrib2.6.8 erfolgt jetzt gleich bei mir

[DS_Starter]

Moin 300P,

ja, dann hast du augenscheinlich keine echte Drift sondern nur Abweichungen durch kurzfristige, nicht‑repräsentative Verbrauchsmuster, die das Modell nicht generalisieren kann.
Denn nur wenn es sich um echte Drift handelt, soll die Rekalibrierung greifen.

Kurzfristige Peaks oder untypische Verbrauchsmuster erzeugen

* BiasLive‑Ausschläge
* RMSE‑Spitzen
* Slope‑Anomalien

Die Safety‑Logik (_aiDrift_safety_blocked) erkennt das (hoffentlich) als instabil / Ausreißer, nicht als echte Drift.
Genau dafür ist sie gebaut, das soll sie tun.
Dort wird Rekalibrierung verhindert bei:

* Ausreißern
* API-/Sensorfehlern
* instabiler Drift
* ,,model_bad_but_stable"
* Bias-/Slope‑Implausibilitäten
* Low‑Load‑Phasen

Das sind alles Nicht‑Drift‑Situationen.
Wenn die Rekalibrierung blockiert wird und die Vorhersage trotzdem gut bleibt, dann liegt keine echte Drift vor. 
Die Abweichungen stammen dann nur aus kurzfristigen Störungen oder Situationen, die das Modell nicht erklären kann (z.B. deine Sauna‑Exzesse).
Echte Drift bedeutet eine dauerhafte, stabile Verschiebung über viele Stunden – nur dann soll die Rekalibrierung greifen.
Alles andere wird von der Safety‑Logik bewusst abgefangen, damit das Modell nicht auf Ausreißer reagiert.
Nun ist jedes unserer Systeme anders und ich hoffe ein Optimum bzgl. der "Abfanglogik" gefunden zu haben. 

[300P]

Auf jeden Fall ist kein Bug im Modul
👌👍👌👍👌👍😉

[300P]

ups - grad gesehen das im Contrib eine ältere V2.6.8 liegt als im normalen Updateprozess geladen wird 

[DS_Starter]

Ja, kann passieren.

[300P]

Die Drift-Funktion habe ich noch etwas nachgebessert und mit aiProcess_long gibt es noch mehr Ausgabe zur Analyse:

Update und shutdown/restart nach "normalen" FHEM-Updatefunktion.
mmmh - Einträge sollten zur vollen Stunden dann kommen - oder ?

Code Auswählen Erweitern

2026.05.12 09:17:01 0: Server started with 443 defined entities (fhem.pl:30992/2026-03-21 perl:5.036000 os:linux user:fhem pid:494960)
2026.05.12 09:17:09 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 3192) line 1.
2026.05.12 09:18:27 2: AttrTemplates: got 272 entries
2026.05.12 10:00:16 1: Forecast DEBUG> start add AI raw data for hour: 10
2026.05.12 10:00:16 1: Forecast DEBUG> AI raw add - 1 entities added to raw data pool (set verbose 4 for output more detail)
2026.05.12 10:00:16 1: Forecast DEBUG> AI raw data saved into file: ./FHEM/FhemUtils/AIraw_SolarForecast_Forecast
2026.05.12 10:00:17 1: Forecast DEBUG> DRIFT [con]: Flag=moderate | Block=rmse_anomaly | SlopeLive=0.436 | DriftSlope=0.435 | BiasLive=1027.84 | DriftBias=1034.46 | RMSErelLive=112.0 | RMSErelRatio=28.01 | BiasVarNorm=1.16 | DriftIndex=2.73 | DriftScore=17.98 | Zone3Hours=36 | Zone3Reset=0 | Hist=[moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate]
2026.05.12 10:00:17 1: Forecast DEBUG> AI FANN drift data type 'con' successfully written to file: ./FHEM/FhemUtils/NeuralNet_SolarForecast_Forecast




EDIT:
Kommt das evtl. nur bei "block=none" ?

[DS_Starter]

Kommt das evtl. nur bei "block=none" ?

Ja, genau.

[300P]

Geht das evtl. in allen Konstellationen als Eintrag bei ....long?

[DS_Starter]

Geht das evtl. in allen Konstellationen als Eintrag bei ....long?

Nicht wirklich. Sobald ein Wert berechnet ist der zu blocking führt, wird die Funktion verlassen und kommt erst garnicht bis zum Debug. Und wenn die Funktion mit einem Block verlassen wird, kommt im nächten Debug auch der Grund der Blockierung mit.
Aktuell suche ich nach einem geeigeten Indikator/Schwellenwert der uns anzeigt bis wohin Rekalibrierung noch sinnvoll ist und wann ein neues Training notwendig ist weil Rekal keinen Nutzen mehr bringt.

[300P]

Hallo Heiko,

- Anmerkung zum 'blocking' bei der Rekalibrierung:

Könnte es evtl auch sein, das die Sommerzeit bzw. diese -1 h Umstellung eventuell auch noch seinen Beitrag bei der Drift-Analyse bzw. zu dem 'blocking' am Ende beiträgt ? 
 

[DS_Starter]

Für die Driftanalyse wird ein Fenster der letzen 96 Stunden betrachtet. Eine Vergrößerung oder Verkleinerung dieses Fensters hätte direkten Einfluß auf die Driftanalyse.
Die 96 h sind sicherlich ein Wert der nicht in jedem Fall optimal ist. So könnte man das Fenster verkürzen wenn Stress erkennbar ist oder vergrößern bei einem stabilen Modell, also eine Art adaptiven Fenster. Ein größeres Fenster wäre robuster gegen Einzelausreißer.

[Mikel2906]

Hallo Heiko,

vielen Dank für deine Info vom 10. Mai 2026, 14:22:55. Es fehlt der contotal-Wert.

Ich lese die Werte von meinem Stromzähler mit Tasmota und einem Schreib-Lesekopf ab. Das Komische an der ganzen Sache ist, dass das nur nachts passiert.
Ich habe auch die Zeitabstände für die Leseintervalle erhöht, um Lesefehler zu vermeiden. Hast du eine Idee, was ich ändern kann?

Viele Grüße
Michael

2026.05.12 02:31:51 1: PV_Prognose DEBUG> collect Energy Meter data - device: Smartmeter =>
2026.05.12 02:31:51 1: PV_Prognose DEBUG> gcon: 0 W, gfeedin: 8 W, contotal: 0 Wh, feedtotal: 11353700 Wh


2026.05.12 02:33:00 1: PV_Prognose DEBUG> collect Energy Meter data - device: Smartmeter =>
2026.05.12 02:33:00 1: PV_Prognose DEBUG> gcon: 0 W, gfeedin: 3 W, contotal: 17516900 Wh, feedtotal: 11353700 Wh
2026.05.12 02:33:00 1: PV_Prognose DEBUG> write to pvHistory - day: 12, hod: 3, GridConsumption (gcons): 17516900 Wh

[DS_Starter]

Hallo Michael,

schön ist das nicht. Es macht zumindest auf mich den Eindruck eine sehr unzuverlässige Datenermittlung zu nutzen. Mit welchem Modul liest du denn den Lesekopf aus? Möglicherweise kannst du in dem entsprechenden Forum Hilfe bekommen deine Datensammlung zu stabilisieren. Ich selbst nutze keine Leseköpfe.

Man könnte zwar mit einem userReading einen Rückgang auf 0 vermeiden, aber wenn contotal oder feedtotal nicht regelmäßig hochzählen bekommst du nie reale Einspeise- / Bezugswerte pro Stunde geliefert was wiederum Einfluß auf davon abhängige Größen hat.

Vllt. kann noch jemand etwas beisteuern und Michael raten?

LG,
Heiko