76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Gibt es denn einen Weg, SF so zu konfigurieren oder Datenbestände (rück)zusetzen, sodass die Verbrauchsdaten des vorherigen Tages nicht mehr herangezogen werden und nur noch die für geplanten Verbraucher berücksichtigt werden?

Ich habe schon darüber nachgedacht, aber keine Variante gefunden.
Gesetzt den Fall, alle historischen Daten wären 0 oder nicht vorhanden, gäbe es einen prognostizierten Grundverbrauch von 0.
Man hat aber im Haushalt üblicherweise nur einen kleinen Teil der Verbraucher in SF registriert. Das würde bedeuten eine ausschließlich auf Einbeziehung der Planungsdaten und Excludes der registrierten Verbraucher wäre völlig daneben und unbrauchbar.

Wenn sowas unbedingt gewünscht ist, müsste ich einen komplett neuen/ergänzenden Codeblock für diesen Fall schreiben. Dann würde ich aber auch gern den use Case dahinter verstehen weshalb dies sinnvoll ist.

Edit:

@Heiko: Der meiner Frage zugrunde liegende Anwendungsfall ist für Dich nachvollziehbar, richtig?

Eigentlich nicht 

[Parallix]

...

@Heiko: Der meiner Frage zugrunde liegende Anwendungsfall ist für Dich nachvollziehbar, richtig?

Eigentlich nicht 

Kein Thema! Dann erläutere ich ihn eben.

Anmerkung: Der (ohne KI besser anzuwickelnde) Anwendungsfall entsteht durch ein hochgradig volatiles Nutzungsverhalten, dass sich nicht auf Basis früherer Nutzungen prognostizieren lässt.

Hier die Beschreibung des  Anwendungsfalls:

Der Hausspeicher soll so geladen werden, dass man mit diesem unter Zugrundelegung eines durchschnittlichen Grundverbrauchs (ohne Netzbezug) durch die Nacht kommt. Vorgenannter Grundverbrauch lässt sich durch einen ,,must"-Consumer modellieren.

Wenn ein EV an der Wallbox angesteckt ist (ermittelbar via Reading), soll dieses immer dann so geladen werden, dass hierdurch das o.g. Ziel auch weiterhin erreicht werden kann. Hierzu wird der Ladevorgang auf mehrere Tage mit jeweils durchgehenden Teilladungen aufgeteilt. Während vorgenannter Teilladungen können die Ladeleistungen variieren, minimal jedoch nicht unter P_CHG_MIN und nicht über P_CHG_MAX liegen. Es existiert keine Möglichkeit den Ladezustand des EVs via FHEM zu ermitteln. Lediglich die vollständige Aufladung bis zum am EV einstellbaren TargetSOC_EV kann (via Reading) festgestellt werden.

Der Start und das Ende des EV-Ladevorgangs soll so erfolgen, dass die tägliche Energiemenge möglicher  Umladungen ( BESS → BEV)  stets unter einem max. Wert E_BTV_MAX ĺiegt. Hierdurch können die Umladeverluste minimiert werden. Um sicherzustellen, dass das Fahrzeug nach einer via Reading angegebenen Zeit Time2TargetSOC_EV auf den TargetSOC_EV gebracht ist, wird  E_BTV_MAX bis zum Zieltag sukzessive bis zu einem Limit E_BTV_MAX_LIMIT erhöht. Die jeweilige Einstellung von E_BTV_MAX lässt sich durch einen über ,,must"-Consumer mit täglich variierdender Leistung und Ladedauer modellieren. Kann der TargetSOC_EV zum Zielzeitpunkt nicht erreicht werden, so erfolgt eine rechtzeitig eingeleitete Netzladung.

[DS_Starter]

Der Hausspeicher soll so geladen werden, dass man mit diesem unter Zugrundelegung eines durchschnittlichen Grundverbrauchs (ohne Netzbezug) durch die Nacht kommt. Vorgenannter Grundverbrauch lässt sich durch einen ,,must"-Consumer modellieren.

Das war das fehlende Puzzleteil. Insgesamt ist das schon ein "very advanced" Scenario was du umsetzen möchtest.
Ich werde mal schauen, ob ich einen geeigneten Code implementieren kann, der bei consForecastLastDays=0 sämtliche historischen Daten ignoriert und nur die Power-Anteile der geplanten Verbraucher berücksichtigt.   

[Parallix]

Der Hausspeicher soll so geladen werden, dass man mit diesem unter Zugrundelegung eines durchschnittlichen Grundverbrauchs (ohne Netzbezug) durch die Nacht kommt. Vorgenannter Grundverbrauch lässt sich durch einen ,,must"-Consumer modellieren.

Das war das fehlende Puzzleteil. Insgesamt ist das schon ein "very advanced" Scenario was du umsetzen möchtest.

Ja, in der Tat. Was den Ladecontroller angeht, so bin ich da schon recht weit gekommen, bis ich feststellen musste, dass in SF die Logik (aktuell ) nicht ganz so funktioniert, wie ich es mir (auf Basis der Online-Hilfe und des Wikis) vorgestellt habe.

Ich werde mal schauen, ob ich einen geeigneten Code implementieren kann, der bei consForecastLastDays=0 sämtliche historischen Daten ignoriert und nur die Power-Anteile der geplanten Verbraucher berücksichtigt.   

Das wäre galaktisch!

[grappa24]

Wie bekomme ich denn das m.M.n übertriebene "Folgeverhalten" besser geregelt

Code Auswählen Erweitern

letztes KI-Training: 25.01.2026 02:46:18 / Laufzeit in Sekunden: 11337
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 108.8 ms
Verbrauchernummer Wärmepumpe:  -

=== Modellparameter ===

Normierungsgrenzen: PV=11990 Wh, Hausverbrauch: Min=0 Wh / Max=6468 Wh
Trainingsdaten: 8471 Datensätze (Training=6776, Validierung=1695)
Architektur: Inputs=69, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.5, BitFail-Limit=0.34
Aktivierungen: Hidden=SIGMOID, Steilheit=0.9, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_common_active_pv
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 2445 (von max. 15000)
Training MSE: 0.001336
Validation MSE: 0.001799
Validation MSE Average: 0.002191
Validation MSE Standard Deviation: 0.000353
Validation Bit_Fail: 2
Model Bias: 73 Wh
Model Slope: 0.8
Trainingsbewertung: ok

=== Fehlermaße der Prognosen ===

MAE: 147.46 Wh
MedAE: 71.41 Wh
RMSE: 193.47 Wh
RMSE relative: 46 %
RMSE Rating: acceptable
MAPE: 22.36 %
MdAPE: 15.32 %
R²: 0.86

=== Rauschen ===

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

=== Drift-Kennzahlen ===

Drift Score: -
Drift RMSE ratio: -
Drift Slope: -
Drift Bias: -
Drift Bewertung: -