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.

[klaus.schauer]

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.

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?

Geht natürlich über

Code Auswählen Erweitern

set ... attrKeyVal consumerXX comforttemp=...


Code Auswählen Erweitern

comforttemp=<device>:<reading>
Wäre dennoch irgendwie praktischer. Jetzt sehe ich zweimal täglich, dass die cfg geändert wurde. Ist aber ein Komfortproblem, zugegeben.

[DS_Starter]

Ich habe comforttemp nun so erweitert, dass in dem Schlüssel alternativ eine Device:Reading Kombi angegeben werden kann:

comforttemp    
Solltemperatur (Komforttemperatur) in den Innenräumen in °C (Pflichtangabe).
Der Wert kann fest gesetzt oder durch eine <Device>:<Reading>-Kombination geliefert werden:
<Device>:<Reading> - die Device/Reading Kombination liefert die Temperatur
Wertebereich: -40..40

Update liegt im contrib.

@Klaus,

Wäre dennoch irgendwie praktischer. Jetzt sehe ich zweimal täglich, dass die cfg geändert wurde. Ist aber ein Komfortproblem, zugegeben.

Die Änderung ist über das rote Fragezeichen nur sichtbar, wenn man im global Device explizit autosave=0 gesetzt hat. Sonst erfolgt die Änderung völlig transparent ohne diese Signalisierung.

LG,
Heiko

[PSI69]

Moin Heiko!

Danke für die Anpassung für comforttemp - gefällt mir besser, als über ein notify darauf zu reagieren - und das 'Fragezeichen' entfällt...
Eine weitere Überlegung zur Wärmepumpe: im Urlaubsmodus wird bei mir - zusätzlich zur Absenkung der Raumtemperatur - kein Warmwasser erzeugt & die Kühlfunktion ist deaktiviert (wobei die vom Energiebedarf ja eher 'geschenkt' ist). Ich denke, den Urlaubsmodus - in welcher Form auch immer - SolarForecast zu signalisieren, wird nicht verkehrt sein. Der eine oder andere wird ja ähnliche Anpassungen bei Abwesenheit vornehmen, nicht nur auf die Heizung bezogen. Das komplette Verbrauchsverhalten ist ja anders bei Abwesenheit.

Habe ich hier etwas verpasst/übersehen und gibt es das schon?

Viele Grüße,
Peter

[DS_Starter]

Moin,

das ist schon eingebaut. Es gibt zwei Stellen:

- setupEnvironment->presence für die temporäre Anwesenheit/Abwesenheit wie gewohnt
- für Feiertage/Urlaub werden die im global holiday2we eingetragenen Devices ausgewertet. Ist im Wiki etwas versteckt beschrieben.

LG,
Heiko

[300P]

Hilfestellung und zur Info für diejenigen unter euch die
- Besitzer einer Wärmepumpe von Buderus oder Bosch sind
- per MQTT-Modul auf ihre WP mittels BBQKees-EMS-Modul zugreifen
- diese in SF als Consumer erstmalig einbinden möchten:


Einstellung innerhalb EMS-Modul:
(siehe die 2 passenden Screenshot)



Beispiel-Einstellung im MQTT-Modul (Gerätename anpassen ?!?)

Code Auswählen Erweitern

defmod MQTT_EMSwp MQTT2_DEVICE MQTT_EMSwp
attr MQTT_EMSwp DbLogExclude BSSID,IODev,IPv4_address,IPv4_gateway,IPv4_nameserver,IPv6_address,MAC,SSID,apicalls,\
apifails,attrTemplateVersion,boiler_data_auxheaterdelay,boiler_data_auxheaterlevel,\
boiler_data_auxheateroff,boiler_data_auxheateronly,\
boiler_data_auxheatersource,boiler_data_auxheatrmode,boiler_data_auxlimitstart,\
boiler_data_auxmaxlimit,boiler_data_burn2workmin,\
boiler_data_burnstarts,boiler_data_burnworkmin,boiler_data_dhw_alternatingop,boiler_data_dhw_altopprio,\
boiler_data_dhw_altopprioheat,boiler_data_dhw_comfdiff,boiler_data_dhw_comfort1,\
boiler_data_dhw_comfstop,boiler_data_dhw_disinfecting,boiler_data_dhw_disinfectiontemp,\
boiler_data_dhw_ecodiff,boiler_data_dhw_ecoplusdiff,\
boiler_data_dhw_ecoplusoff,boiler_data_dhw_ecoplusstop,boiler_data_dhw_ecostop,\
boiler_data_dhw_flowtempoffset,boiler_data_dhw_hystoff,boiler_data_dhw_hyston,boiler_data_dhw_maxheat,\
boiler_data_dhw_onetime,boiler_data_dhw_recharging,boiler_data_dhw_seltemp,\
boiler_data_dhw_seltemplow,boiler_data_dhw_seltempsingle,boiler_data_dhw_tempecoplus,\
boiler_data_dhw_workm,bootTime,boot_time,bus_status,connected,freemem,heartbeat_.*,mqttcount,mqttfails,\
mqttreconnects,network,rssi,rxfails,rxreceived,txfails,txreads,txwrites,uptime,uptime_sec,wifistrength,wifireconnects,\
thermostat_data_datetime
attr MQTT_EMSwp autocreate 1
attr MQTT_EMSwp bridgeRegexp heartbeat:.* { json2nameValue($EVENT) }
attr MQTT_EMSwp comment
Autorisierung / Token: \
The bearer Access Token (JWT) is used to authenticate HTTP requests and can be obtained from the \
WebUI's Settings->Security->Manage Users page and then clicking on the key icon for the user that has admin privileges (is Admin set). \
The token is generated using a combination of the username and a secret key which is the super user (su) password found in the WebUI's Settings->Security->Security Settings page. \
This 152 character long string must be included in the HTTP header as "Authorization: Bearer {ACCESS_TOKEN}". Note the token has no expiry date.\
\
<bearer Acts Token> "dieser WLW186-7 MB AR E" = {ACCESS_TOKEN}\
Beispiele :\
#############\
# Most GETs do not need authentication\
% curl http://ems-esp.local/api/thermostat/seltemp\
\
# POSTs (with -d) need authentication tokens\
% curl http://ems-esp.local/api/thermostat/seltemp \\
  -H 'Content-Type: application/json' \\
  -H 'Authorization: Bearer <bearer Acts Token>' \\
  -d '{ "value" : 22.5 }'\
\
# GET with authentication using query parameter with token\
% curl http://ems-esp.local/api/system/publish\?access_token\="ey.......0"\
\
# GET to restart EMS-ESP\
curl http://ems-esp.local/api/system/restart -H 'Authorization: Bearer ey....0'\
\
# This example will get the system info, via a GET request\
curl -X GET ${emsesp_url}/api/system/info\
\
# This example will execute a read command on product ID 8 and type ID 1\
curl -X POST \\
    -H "Authorization: Bearer ${<bearer Acts Token>}" \\
    -H "Content-Type: application/json" \\
    -d '{"data":"8 1"}' \\
    ${emsesp_url}/api/system/read\
\
# This example will export all values to a json file, including custom entities, sensors and schedules\
curl -X POST \\
    -H "Authorization: Bearer ${<bearer Acts Token>}" \\
    -H "Content-Type: application/json" \\
    -d '{"action":"export", "param":"allvalues"}' \\
    ${emsesp_url}/rest/action
attr MQTT_EMSwp disable 0
attr MQTT_EMSwp event-min-interval .*:600
attr MQTT_EMSwp event-on-change-reading .*
attr MQTT_EMSwp icon air_water_heating_pump
attr MQTT_EMSwp model ems-esp_heater_device
attr MQTT_EMSwp readingList MQTT_EMSwp:ems-esp/heartbeat:.* { json2nameValue($EVENT) }\
MQTT_EMSwp:ems-esp/status:.* status\
MQTT_EMSwp:ems-esp/info:.* { json2nameValue($EVENT) }\
MQTT_EMSwp:ems-esp/heating_active:.* heating_active\
MQTT_EMSwp:ems-esp/tapwater_active:.* tapwater_active\
MQTT_EMSwp:ems-esp/boiler_data:.* { json2nameValue($EVENT, 'boiler_data_', $JSONMAP) }\
MQTT_EMSwp:ems-esp/thermostat_data:.* { json2nameValue($EVENT, 'thermostat_data_', $JSONMAP) }\
MQTT_EMSwp:ems-esp/mixer_data:.* { json2nameValue($EVENT, 'mixer_data_', $JSONMAP) }
attr MQTT_EMSwp room EnergieWP,MQTT2_DEVICE
attr MQTT_EMSwp setList restart:noArg heartbeat:.* { json2nameValue($EVENT) }
attr MQTT_EMSwp stateFormat T=>>   Out: boiler_data_outdoortemp ModeCirc: thermostat_data_dhw_circmode WW: boiler_data_dhw_curtemp Circ: boiler_data_dhw_circ VL: boiler_data_curflowtemp RL: boiler_data_rettemp HC1-Flow: mixer_data_hc1_flowtemphc   P.-Status HK1: mixer_data_hc1_pumpstatus P.-Status HK2: mixer_data_hc2_pumpstatus  HP_Power_Current: boiler_data_hpcurrpower   HP_Power_Reduction: boiler_data_powerreduction
attr MQTT_EMSwp userReadings user_WP_JAZ_overall {\
 if ((ReadingsNum($name,"boiler_data_metertotal",0) > 0) && (ReadingsNum($name,"boiler_data_nrgtotal",0) > 0))\
 { \
(sprintf("%.2f", (ReadingsNum($name,"boiler_data_nrgtotal",0)/ReadingsNum($name,"boiler_data_metertotal",0))));;;;\
 }\
},\
\
user_WP_JAZ_year \
{\
if ((ReadingsNum("Dum.Energy","WPGridConsumptionYear",0) > 0) && (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalYear",0) > 0))\
 { \
(sprintf("%.2f", (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalYear",0)/ReadingsNum("Dum.Energy","WPGridConsumptionYear",1))));;;;\
 }\
},\
\
user_WP_JAZ_month {\
if ((ReadingsNum("Dum.Energy","WPGridConsumptionMonth",0) > 0)&& (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalMonth",0) > 0))\
 { \
(sprintf("%.2f", (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalMonth",0)/ReadingsNum("Dum.Energy","WPGridConsumptionMonth",1))));;;;\
 }\
},\
\
user_WP_JAZ_day {\
 if ((ReadingsNum("Dum.Energy","WPGridConsumptionDay",0) > 0) && (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalDay",0) > 0))\
 { \
  (sprintf("%.2f", (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalDay",0)/ReadingsNum("Dum.Energy","WPGridConsumptionDay",1))));;;;\
 }\
}, \
\
user_WP_JAZ_hour {\
 if ((ReadingsNum("Dum.Energy","WPGridConsumptionHour",0) > 0) && (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalhour",0) > 0))\
 { \
  (sprintf("%.2f", (ReadingsNum("Dum.Energy","WPboiler_data_nrgtotalhour",0)/ReadingsNum("Dum.Energy","WPGridConsumptionHour",1))));;;;\
 }\
}, \


Definierung des Heatpump-"consumerXX" in SF

Code Auswählen Erweitern

SMA_Elgris_EM2 ###>>>  EM-Gesamt der WP
type=heatpump
power=2500          ####>>> ich untertriebe hier extra - es werden bis zu 3500 verbraucht
icon=sani_heating_heatpump@orange ##> oder ein anderes icon nach Wahl
pcurr=Bezug_Wirkleistung:W    ## aus dem EM
etotal=Bezug_Wirkleistung_Zaehler:kWh   ## aus dem EM
noshow=0  
switchdev=MQTT_EMSwp    ### wenn man selber schaltent eingreifen möchte
swstate=boiler_data_hpactivity:heating|cooling|hot.*:off
comforttemp=MQTT_EMSwp:thermostat_data_hc1_comforttemp

Eintrag in "SetupEnviroment"

Code Auswählen Erweitern

outsideTemp=MQTT_EMSwp:boiler_data_outdoortemp
presence=Forecast:user_presence:present


zusätzliche "UserReadings" in SF definieren:

Code Auswählen Erweitern


user_presence {if(ReadingsVal("Handy_01","state","") eq "present") {return "present"} elsif (ReadingsVal("Handy_02","state","") eq "present") {return "present"} else {return 0}},


So oder ähnlich in attr aiControl zusätzlich einstellen (Versuch macht klug)

Code Auswählen Erweitern

aiConActivate=1
aiConAlpha=0.9
aiConTrainStart=30:3
aiConActFunc=GAUSSIAN_SYMMETRIC
aiConHiddenLayers=64-32
aiConLearnRate=0.001
aiConMomentum=0.6
aiConShuffleMode=1
aiConShufflePeriod=20
aiConSteepness=1.0
aiConTrainAlgo=INCREMENTAL
aiConProfile=v1_heatpump_active_pv
aiConBitFailLimit=0.18


[DS_Starter]

Hallo zusammen,

@300P, wäre deine Info nicht etwas für das Wiki als Unterpunkt in diesem Bereich? Sonst gehen solche wertvollen Beiträge/Informationen leicht unter.

Die aktuell im contrib vorhandene Version 2.2.0 werde ich vermutlich heute Abend einchecken. Die kommenden Tage/kommende Woche nehme ich mir wieder FHEM-frei 
Danach geht es weiter mit den EV Einbindungen. Falls wider Erwarten irgendwelche Probleme mit der 2.2.0 auftreten sollten, könnt ihr über den FHEM restore Befehl die Version vor dem Update wieder herstellen.
Heute Abend kann ich noch etwas unterstützen bei Bedarf, aber dann kommt etwas Auszeit wobei ich sicherlich ab und zu mal mitlese. 

LG,
Heiko