76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[grappa24]

mal was zur "Ablenkung" vom EV-Thema:
CO-Abweichung fortlaufend: 3 %, gestern: 4,7 %

Code Auswählen Erweitern

letztes KI-Training: 16.02.2026 04:00:26 / Laufzeit in Sekunden: 2364
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 129.21 ms
Verbrauchernummer Wärmepumpe:  -

=== Modellparameter ===

Normierungsgrenzen: PV=11990 Wh, Hausverbrauch: Min=0 Wh / Max=6468 Wh
Trainingsdaten: 9003 Datensätze (Training=7202, Validation=1801)
Architektur: Inputs=69, Hidden Layers=50-25, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.5, BitFail-Limit=0.34
Aktivierungen: Hidden=SIGMOID, Steepness=1.1, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_common_active_pv
Zufallsgenerator: Mode=2, Period=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 455 (max. 15000)
Training MSE: 0.001790
Validation MSE: 0.001659
Validation MSE Average: 0.002098
Validation MSE Standard Deviation: 0.000179
Validation Bit_Fail: 1
Model Bias: 79 Wh
Model Slope: 0.9
Trainingsbewertung: ok

=== Fehlermaße der Prognosen ===

MAE: 148.61 Wh
MedAE: 69.67 Wh
RMSE: 198.20 Wh
RMSE relative: 47 %
RMSE Rating: acceptable
MAPE: 22.74 %
MdAPE: 14.65 %
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: -

[DS_Starter]

Man sieht ziemlich deutlich, dass zwischen 11 und 17 Uhr der Verbrauch relativ unvorhersehbar ist (Gründe müsstest du kennen?), aber durch die eingebaute Trendfolge zwischen benachbarten Stunden wieder ausgeglichen wird. Dadurch korreliert der Verbrauch wieder mit der Tagesprognose.
Mit einem tieferen Netz (80-40-20) erreicht man evtl. eine stärkere Differenzierung, aber ich denke das wird mit der Hardware schlecht funktionieren. Die Abfrage dauert jetzt schon über 100ms.
Ich denke das funktioniert schon ganz gut.   

[dieter114]

Ob du eventuell nicht einfach per API (z.B. evcc-API-Schnittstelle oder MQTT etc. zugreifst, damit du nicht das Rad neu komplett erfinden musst ?

Das läuft schon länger prima.
Hier bitte: https://wiki.fhem.de/wiki/Solaranlage_Komplettbeispiel_Fronius_BYD#Autoladen_%C3%BCber_evcc

Beispiel des MQTT2 Device:

Code Auswählen Erweitern

defmod MQTT2_evcc1 MQTT2_DEVICE evcc1
attr MQTT2_evcc1 DbLogExclude .*
attr MQTT2_evcc1 DbLogInclude loadpoints_1_chargePower
attr MQTT2_evcc1 alias Wally
attr MQTT2_evcc1 autocreate 1
attr MQTT2_evcc1 comment Achtung: EVCC greift per Modbus auf Fronius zu Port 502 Adr. 200
attr MQTT2_evcc1 event-on-change-reading .*
attr MQTT2_evcc1 event-on-update-reading .*
attr MQTT2_evcc1 icon wallbox
attr MQTT2_evcc1 readingList evcc1:evcc/loadpoints/1/chargePower:.* loadpoints_1_chargePower\
Es kommen allerdings unglaublich viele Readings wenn nichts eingegrenzt wird.

LG WDS

[Wolle02]

MQTT ist auch mit der openWB gut zu machen. Ich habe sie bei mir sowieso über MQTT angebunden und bekomme die relevanten Topics schön als Reading präsentiert. Ready for SF 

[DS_Starter]

Wenn ich eure Beiträge so lese werden wir die Daten sehr gut über das etablierte key=<Device>:<Reading> Verfahren einbinden können und bleiben so flexibel.

Bezüglich der Consumerarchitektur gefällt mir die in #5150 diskutierte Variante 2 immer besser. D.h. man würde einen EV als consumerXX definieren (das Wallbox/MQTT-Device als Stellvertreterdevice). Sobald ein "identity"-Key als "true" erkannt wird, aktiviert sich der consumerXX (das entsprechende EV) und stellt seine Daten im SF-System bereit, d.h. sie können verarbeitet und gespeichert werden. Wird ein anderer EV angeschlossen und somit eine andere "identity" erkannt, aktiviert sich ein anderer consumerXX sofern definiert.

Der "identity"-Key wird so flexibel über <Device>:<Reading> konfigurierbar gestaltet, dass der User alle möglichen Varianten (Name, MAC, RFID ... whatever) zur Identifikation des Fahrzeuges heranziehen und ggf. kombinieren kann.