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.

[PSI69]

Als Workaround kannst du dafür ein userReading angeben welches immer '0' als Wert hat.

Juhu!
... aus zwei HA Python Modulen habe ich mir weitere Werte zusammen geklaubt, die über die Waterkotte API bezogen werden können.
Einzige Schwierigkeit - die Werte werden teilweise als Hex Paare geliefert - daraus muss erst jeweils ein integer/float erstellt werden; aber - passt nun für mich!

Mein Consumer ist nun wie folgt definiert:
Waterkotte
type=heatpump
power=3000
icon=sani_earth_source_heat_pump
swstate=state:heating|cooling|water|measure:ready
asynchron=1
auto=0
pcurr=geo_power_comp_el:kW
etotal=main_energy_cons_total:kWh
noshow=9
comforttemp=main_temp_room_soll

Ich hoffe die comforttemp als reading passt - zumindest wurde diese cfg so akzeptiert. In der Anlagenconfig konnte ich dann auf 'v1_heatpump_active_pv' umstellen.

Und nun freue ich mich 'wie Sau' dass das so geklappt hat!

Viele Grüße Peter

[DS_Starter]

Hallo Peter,

Ich hoffe die comforttemp als reading passt - zumindest wurde diese cfg so akzeptiert.

Uii, das muß ich natürlich unterbinden.    Das ist nämlich ein numerischer Wert im Berich -40 .. 40.
In der contrib-Version ist es bereits nicht mehr möglich einen falschen Wert einzutragen.
Setze z.B. einfach comforttemp=22.5, dann würde es passen.

[PSI69]

Uii, das muß ich natürlich unterbinden.    Das ist nämlich ein numerischer Wert im Berich -40 .. 40.

Ähm, schade, weil: in meinem Fall ist das direkt die Vorgabe Temperatur, mit der die Heizung arbeitet. Im Urlaubsmodus erfolgt hier auch eine Absenkung, bzw. diese ist darüber sichtbar. D.h. die geänderte Vorgabe würde dann auch direkt auf SolarForecast durchgreifen.
Wäre das nicht sinnvoll die andere Vorgabe zusammen mit den Verbrauchswerten zu haben?
Gruß Peter

[DS_Starter]

Das ist kein Problem. Ich kann diese comforttemp auch noch umbauen damit Device:Reading Kombi angegben werden kann.
Aktuell geht es schon mit einem:

Code Auswählen Erweitern

set ... attrKeyVal consumerXX comforttemp=...

Diesen Befehl kannst du z.B. mit einem norify/DOIF absetzen.
Mit attrKeyVal können auch alle anderen key=value Paare der zusammengesetzten Attribute dynamisch geändert werden.