Photovoltaik Eigenverbrauch,Bilanz,Prognose (Kostal Plenticore; KSEM; BYD HV)

Begonnen von ch.eick, 07 Oktober 2020, 16:09:12

Vorheriges Thema - Nächstes Thema

ch.eick

Hallo zusammen,
ich habe gerade problemlos auf die aktuellste Firmware beim Plenticore und KSEM umgestellt.
Im Modbus des Plenticore werden jetzt einige Speicher Informationen wieder richtig angezeigt, dazu gibt es Informationen in den Release Notes.

VG   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

vw2audi

Hallo zusammen,

ich habe das folgende Setting:
Kostal PLENTICORE plus 8.5 mit BYD HV Speicher (ohne webgui) und einem KSEM.

Ich habe das Wiki studiert und mich an das Einrichten der konfiguration gemacht.
Das Device WR_1 funktioniert ohne Probleme und liefert mir auch alle Werte.

Bei dem Modul WR_1_API gibt es ein paar ungereimtheiten. Die Eigenverbrauchsquote kommt mir sehr komisch vor:
heute -20800% !?

Hat jemand eine Idee, wo ich nach dem Fehler suchen kann / muss?

Danke Gruß
Christian

Fhem auf Raspberry PI3, sonoff: RFBridge, PIR, Basic, POW, Dual.... , FS20: FHT 80TF-2 (3x); FS20-Piri2 (1x)
S300TH (1x); FS20-ST (6x); FS20-SU (3x); FS20 WS1 (2x); Fritz: DECT200 (3x), Z-Wave: diverse Schalter.... , HomeMatic: Heizungsregler

ch.eick

Zitat von: vw2audi am 01 März 2023, 14:22:45
Hallo zusammen,

ich habe das folgende Setting:
Kostal PLENTICORE plus 8.5 mit BYD HV Speicher (ohne webgui) und einem KSEM.

Ich habe das Wiki studiert und mich an das Einrichten der konfiguration gemacht.
Das Device WR_1 funktioniert ohne Probleme und liefert mir auch alle Werte.

Bei dem Modul WR_1_API gibt es ein paar ungereimtheiten. Die Eigenverbrauchsquote kommt mir sehr komisch vor:
heute -20800% !?

Hat jemand eine Idee, wo ich nach dem Fehler suchen kann / muss?
Hallo Christian,
aufgrund der Berechnung für den Hausverbrauch sind die Devices auch für einen Schwarm ausgelegt. Im Schwarm wird der Hausverbrauch momentan noch durch den Plenticore falsch berechnet. Du müsstest bitte auch noch den KSEM einbinden, denn von dort werden noch Messwerte benötigt.
Sobald Kostal den Modbus des KSEM komplettiert hat werde ich das mit dem Hausverbrauch nochmals umbauen, aber auch dafür muss der KSEM eingebunden werden.

Zusätzlich müsstest Du auch noch die initialen Zählerständes des KSEM für den anfang des Jahres/Monats/Tages im WR_1_API Device setzen, die dann später über das PV_Schedule Device aktualisiert werden. Hier mal Beispiele von mir:

Einspeisung:
SW_Meter_init_FeedInGrid_Day 29294     <<< Das wäre heute Morgen
SW_Meter_init_FeedInGrid_Month 29294   <<< Hier der Stand vom 01 des Monats ( was heute der selbe Stand ist )
SW_Meter_init_FeedInGrid_Year 29054    <<< Und das ist der Stand vom 01.01 , bzw. von der Inberiebnahme

Bezug:
SW_Meter_init_Grid_Day 9440
SW_Meter_init_Grid_Month 9440
SW_Meter_init_Grid_Year 8706


VG Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Mumpitz

Hallo Christian

Seit ich das neue Extern Control übernommen habe bekomme ich regelmässig Fehlermeldungen.

Heute nun, als die Kommando Wiederholung anschlagen sollte um das regelmässige Nachladen auf 100% zu vermeiden kam folgende Meldung:

warning
condition c07: Use of uninitialized value $type in concatenation (.) or string at ./FHEM/98_HTTPMOD.pm line 812

Die Meldung erscheint alle 3 Minuten.

Im FHEM Log erscheint folgendes:
2023.03.04 15:17:33 3: eval: BYD_ExternControl_neu: warning in condition c07
2023.03.04 15:17:33 1: PERL WARNING: Use of uninitialized value $type in concatenation (.) or string at ./FHEM/98_HTTPMOD.pm line 812.
2023.03.04 15:17:33 3: eval: BYD_ExternControl_neu: warning in condition c07
2023.03.04 15:17:33 1: PERL WARNING: Use of uninitialized value $type in concatenation (.) or string at ./FHEM/98_HTTPMOD.pm line 805.
2023.03.04 15:15:01 3: BYD_ExternControl_neu cmd_12 : Battery_ExternControl_MaxSocRel auf 95 % reduziert


Weisst du was die Ursache sein könnte?
Wie kann ich überprüfen ob der MaxSocRel auch beim WR ankommt?

ch.eick

Schau mal, ob in dem Block eine Variable nicht gesetzt ist.
Ich bin momentan krank, Sorry.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

zwölfgang

Hallo zusammen,
für alle Interessierten mit einem BYD HVS Speicher, es gibt einen super Beitrag von MiniBlister und MadMax. Es gibt ein Modul 23_BYDBox das ich bei mir installiert habe und gut funktioniert. Die Version 26524 2023-01-17 12:00 aus Beitrag 102 habe ich installiert.
Hier der Link dazu:
https://forum.fhem.de/index.php/topic,121643.90.html

Der Beitrag Nr 7 von MadMax ist auch noch zu beachten.
https://forum.fhem.de/index.php/topic,121643.0.html

VG Wolfgang

ch.eick

KI Prognose Teil 1 - DWD und Astro Daten sammeln

Hallo zusammen,
ich möchte Euch schon mal auf die Neuerungen in der Prognose etwas einstimmen.
Dank Peter ist der Ansatz der KI nun eingezogen und meine Ergebnisse, von bisherigen Tests, sehen schon ziemlich gut aus.

Der Grundgedanke ist, dass die Prognose keinerlei technischen Informationen über den Aufbau der PV-Anlage benötigt. Einzig allen der Ertrag der Anlage wird dabei in Bezug zu den Wetterdaten des jeweiligen Standortes gesetz, wobei die KI daraus Rückschlüsse zieht, wie bei ähnlichen Bedingungen der ertrag werden könnte. Je mehr vergleichbare Daten dazu zur Verfügung stehen, umso besser wird die Prognose.

In der momentan implementierten Prognose besteht darüber hinaus ein Problem, das man momentan erzeugte Leistung eigentlich mit der zu erwartenden Energieprognose vergleicht.
Beim neuen Ansatz wird nun versucht das mit zu korrigieren, was auch im Diagramm durch die Stufen Darstellung verdeutlicht wird.

Die KI Prognose arbeitet nun über den Yield, den der Plenticore jede Stunde aktualisiert. Bei diesem Yield ist nun jedoch ein weiteres Problem, da der hybrid Wechselrichter natürlich auf der AC Seite den Yield angibt und somit das Laden des Speichers nicht aktuell mit zählt. Die Speicher Entladung wird später dann wiederum mit gerechnet, was die AC Yield Kurve dann sehr merkwürdig aussehen lässt. An dieser Problematik wurde auch bereits gearbeitet und das wird dann später nochmal erwähnt.

Im Diagramm sieht man nun in blau den korrigierten Yield unter Berücksichtigung des Speichers und in diesem Beispiel Fall für eien gesamten Schwarm (ich habe zwei WR). Jede Stufe im Diagramm ist dann nun der Ertrag (Yield) der entsprechenden Stunde in kWh.
Zur Orientierung sieht man in gelb die AC Leistung in kW, gezeichnet aus den minütlichen Messwerten.
Die rosa Stufen sind dann nun endlich die Ertrags Prognose Werte aus der KI in kWh.

Solltet Ihr später mit in diese Richtung gehen wollen, so macht es Sinn schon jetzt die Wetterdaten für Euren Standort zu sammeln, da diese die Grundlage bilden und im Anschluss mit dem korrigierten Ertrag in Verbindung gebracht werden. Alle im comment angegebenen DWD Werte werden später von der KI ausgewertet und müssen somit in der DbLog vorliegen. Je mehr DWD Daten von den letzten Jahren vorliegen, umso besser kann die KI Rückschlüsse ziehen. Sollten diese nicht da sein, so lernt das ganze langsam dazu.

Hier wäre dann mein aktuelles DWD_Forecast Device
defmod DWD_Forecast DWD_OpenData
attr DWD_Forecast DbLogExclude .*
attr DWD_Forecast DbLogInclude fc.*_.*_Rad1h,fc.*_.*_TTT,fc.*_.*_FF,fc.*_.*_Neff,fc.*_.*_R101,fc.*_.*_RRS1c,fc.*_.*_DD,fc.*_.*_N,fc.*_.*_VV,fc.*_.*_SunD1
attr DWD_Forecast comment Version 2022.08.20 12:00\
TTT     : Temperature 2m above surface [°C]\
FF      : Windspeed\
Neff    : Effective cloud cover [%]\
R101    : Probability of precipitation > 0.1 mm during the last hour [%]\
R600    : Probability of precipitation > 0.0mm during the last 6 hours [%]\
RRs1c    : Snow-Rain-Equivalent during the last 3 hours [kg/m2]\
Rad1h    : Global Irradiance [kJ/m2]\
          kJ/m² Umrechnung *0,277778 in kWh/m²\
ww    : Significant Weather\
wwM    : Probability for fog within the last hour [%]
attr DWD_Forecast event-on-update-reading fc.*_.*_[Rad1h|TTT|FF|Neff|R101|RRS1c|DD|N|VV|SunD1].*
attr DWD_Forecast forecastDays 1
attr DWD_Forecast forecastProperties Rad1h,TTT,FF,Neff,R600,R101,wwM,ww,RRS1c,DD,N,VV,SunD1
attr DWD_Forecast forecastResolution 1
attr DWD_Forecast forecastStation P0178
attr DWD_Forecast group PV Leistungsprognose
attr DWD_Forecast icon weather_rain_fog
attr DWD_Forecast room Informationen->Wetter,Strom->Photovoltaik
attr DWD_Forecast sortby 07
attr DWD_Forecast verbose 0

EDIT: 20230317
Ich habe mal noch ein Bild von heute angehängt, die KI scheint echt schnell zu lernen. Grün ist die alte Prognose und rosa die KI Prognose. Blau ist der erreichte yield für die Stunde, was recht gut zum KI Ergebnis passt.

EDIT: 20230602
Da die KI Prognose ja auch die Astro Daten für den Sonnenstand benötigt und dieser im Astro Device nicht als fc[0|1] vorliegt habe ich das Astro Device etwas modifiziert. In den userreadings werden dort die fc[0|1] Sonnenstände jetzt abgefragt und als readings eingetragen. Dies geschieht sobald es einen Event von ObsDate gibt, der einmal täglich kommen sollte. Somit beachtet auch die Änderung bei event-on-update-reading und beim DbLogInclude.

defmod Astro Astro
attr Astro DbLogExclude .*
attr Astro DbLogInclude SunAlt,SunAz,fc.*_.*
attr Astro alias Astro
attr Astro event-on-change-reading SunAlt,SunAz,ObsSeason,ObsSeasonN,.*Twilight.*
attr Astro event-on-update-reading ObsDate.*,fc.*_.*
attr Astro group ASC Environment
attr Astro icon telescope
attr Astro interval 600
attr Astro recomputeAt NewDay,SunRise,SunSet,AstroTwilightEvening,AstroTwilightMorning,CivilTwilightEvening,CivilTwilightMorning,CustomTwilightEvening,CustomTwilightMorning
attr Astro room Informationen->Wetter,Rollos
attr Astro sortby 08
attr Astro userReadings fc0_6_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 06:00:00",localtime))},\
fc0_7_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 07:00:00",localtime))},\
fc0_8_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 08:00:00",localtime))},\
fc0_9_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 09:00:00",localtime))},\
fc0_10_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 10:00:00",localtime))},\
fc0_11_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 11:00:00",localtime))},\
fc0_12_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 12:00:00",localtime))},\
fc0_13_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 13:00:00",localtime))},\
fc0_14_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 14:00:00",localtime))},\
fc0_15_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 15:00:00",localtime))},\
fc0_16_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 16:00:00",localtime))},\
fc0_17_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 17:00:00",localtime))},\
fc0_18_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 18:00:00",localtime))},\
fc0_19_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 19:00:00",localtime))},\
fc0_20_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 20:00:00",localtime))},\
fc0_21_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 21:00:00",localtime))},\
fc0_6_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 06:00:00",localtime))},\
fc0_7_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 07:00:00",localtime))},\
fc0_8_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 08:00:00",localtime))},\
fc0_9_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 09:00:00",localtime))},\
fc0_10_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 10:00:00",localtime))},\
fc0_11_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 11:00:00",localtime))},\
fc0_12_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 12:00:00",localtime))},\
fc0_13_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 13:00:00",localtime))},\
fc0_14_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 14:00:00",localtime))},\
fc0_15_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 15:00:00",localtime))},\
fc0_16_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 16:00:00",localtime))},\
fc0_17_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 17:00:00",localtime))},\
fc0_18_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 18:00:00",localtime))},\
fc0_19_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 19:00:00",localtime))},\
fc0_20_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 20:00:00",localtime))},\
fc0_21_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 21:00:00",localtime))},\
\
fc1_6_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 06:00:00",localtime(time+1*24*60*60)))},\
fc1_7_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 07:00:00",localtime(time+1*24*60*60)))},\
fc1_8_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 08:00:00",localtime(time+1*24*60*60)))},\
fc1_9_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 09:00:00",localtime(time+1*24*60*60)))},\
fc1_10_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 10:00:00",localtime(time+1*24*60*60)))},\
fc1_11_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 11:00:00",localtime(time+1*24*60*60)))},\
fc1_12_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 12:00:00",localtime(time+1*24*60*60)))},\
fc1_13_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 13:00:00",localtime(time+1*24*60*60)))},\
fc1_14_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 14:00:00",localtime(time+1*24*60*60)))},\
fc1_15_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 15:00:00",localtime(time+1*24*60*60)))},\
fc1_16_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 16:00:00",localtime(time+1*24*60*60)))},\
fc1_17_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 17:00:00",localtime(time+1*24*60*60)))},\
fc1_18_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 18:00:00",localtime(time+1*24*60*60)))},\
fc1_19_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 19:00:00",localtime(time+1*24*60*60)))},\
fc1_20_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 20:00:00",localtime(time+1*24*60*60)))},\
fc1_21_SunAlt:ObsDate.* {Astro_Get(undef,"Astro","text","SunAlt",POSIX::strftime("%Y-%m-%d 21:00:00",localtime(time+1*24*60*60)))},\
fc1_6_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 06:00:00",localtime(time+1*24*60*60)))},\
fc1_7_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 07:00:00",localtime(time+1*24*60*60)))},\
fc1_8_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 08:00:00",localtime(time+1*24*60*60)))},\
fc1_9_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 09:00:00",localtime(time+1*24*60*60)))},\
fc1_10_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 10:00:00",localtime(time+1*24*60*60)))},\
fc1_11_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 11:00:00",localtime(time+1*24*60*60)))},\
fc1_12_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 12:00:00",localtime(time+1*24*60*60)))},\
fc1_13_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 13:00:00",localtime(time+1*24*60*60)))},\
fc1_14_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 14:00:00",localtime(time+1*24*60*60)))},\
fc1_15_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 15:00:00",localtime(time+1*24*60*60)))},\
fc1_16_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 16:00:00",localtime(time+1*24*60*60)))},\
fc1_17_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 17:00:00",localtime(time+1*24*60*60)))},\
fc1_18_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 18:00:00",localtime(time+1*24*60*60)))},\
fc1_19_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 19:00:00",localtime(time+1*24*60*60)))},\
fc1_20_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 20:00:00",localtime(time+1*24*60*60)))},\
fc1_21_SunAz:ObsDate.* {Astro_Get(undef,"Astro","text","SunAz",POSIX::strftime("%Y-%m-%d 21:00:00",localtime(time+1*24*60*60)))}
attr Astro verbose 0

VG  Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

KI Prognose Teil 2 - Vorbereitung der Daten

Moin,
hier kommt nun der zweite Teil der neuen KI Prognose.
In diesem Teil geht es darum die Daten aus der FHEM History so aufzubereiten, dass sie für die KI Prognose verwendbar wird. Das Daten Model der FHEM History ist in der Form nicht für diese Verarbeitung brauchbar und wird deshalb in eine neu Tabelle überführt. Bei der Gelegenheit wird einiges noch aufbereitet und insbesondere der yield des Plenticore mit Speicher korrigiert.

Im Anhang befindet sich eine MySQL Procedure, die in der Datanbank hinterlegt wird. Dazu verwende ich z.B. die MySQL Workbench, wo dann die Procedure unter "Stored Precedures" auftaucht. Dies ermöglicht, dass man im FHEM DbRep Device nur diese eine Procedure aufrufen kann und nicht jedes einzelne SELECT zur Datenbank in einer separaten Session übermittelt werden muss.

dwd_load in einzelnen Schritten
  • Löschen der bisherigen dwdfull Tabelle
  • Anlegen einer neuen dwnfull Tabelle
  • Füllen der Tabelle mit den älteren rad1h Werten
  • Ergänzen der rad1h Werte für den nächsten Tag
  • Nun erfolgen alle weiteren DWD Daten in weiteren Spalten der dwdfull Tabelle
    • TTT      : Temperature 2m above surface [°C]
    • FF      : Windspeed
    • Neff    : Effective cloud cover [%]
    • R101    : Probability of precipitation > 0.1 mm during the last hour [%]
    • R600    : Probability of precipitation > 0.0mm during the last 6 hours [%]
    • RRs1c  : Snow-Rain-Equivalent during the last 3 hours [kg/m2]
    • Rad1h  : Global Irradiance [kJ/m2]
                  kJ/m² Umrechnung *0,277778 in kWh/m²
    • ww      : Significant Weather
    • wwM    : Probability for fog within the last hour [%]
  • Zum Schluss wird noch der yield der kompletten PV-Anlage ergänzt
    • Begonnen wird mit dem AC yield, der stundenweise aus dem Zähler "SW_Yield_Daily" berechnet wird
        dieser ist jedoch wegen des DC seitigen Speichers nicht korrekt, da in einem Graphen die PV-Leistung erst nach dem entladen zugerechnet wird
    • Nun wird der DC yield des Speichers berücksichtigt, was über diese Werte geschieht
      • Battery_Total_DC_ChargeEnergy_DCsideToBattery
      • Battery_Total_DC_DischargeEnergy_DCsideFromBattery
    • Die Ermittlung einer stunden basierten Tabelle ist etwas komplexer und bedarf diverser SELECT mit JOIN (Im MySQL gibt es kein full JOIN)
  • Der letzte Schritt ist dann die Möglichkeit einer Rückmeldung aus der MySQL Procedure ins FHEM
  • Über den Parameter show/none wird der Prozedure die Art der Rückmeldung mitgeteilt
    • none wäre der Default und gibt als Ergebnis das aktuelle Datum der Datenbank zurück
    • show würde den Inhalt der dwnfull Tabelle an FHEM zurück liefern, was jedoch einige hundert Zeilen sein werden
  • Die Procedure selectiert nur die entscheidenden Daten für die jeweilige KI Prognose, um das Datenvolumen gering zu halten,
    denn es macht ja keinen Sinn, die Winter mit den Sommer Daten zu vergleichen
  • Hierbei werden deshalb folgende Zeiträume jeweils selectiert
    • Die letzten 30 Tage ab dem aktuellen Datum
    • Vom letzten Jahr 30 Tage vor dem Datum
    • Vom letzten Jahr 30 Tage nach dem Datum
    • Vom vorletzten Jahr 30 Tage vor dem Datum
    • Vom vorletzten Jahr 30 Tage nach dem Datum
    • Die Forecast Daten für den nächsten Tag,
      an dieser Stelle wäre es natürlich auch denkbar noch weiter in die Zukunft zu gehen,
      was mir jedoch zu spekulativ ist und nach meiner Meinung bisher für keine Entscheidung von Wichtigkeit wäre
  • Die Laufzeit dieser Procedure beträgt auf meinem RPI4 in einem Oracle MySQL Docker Container ca. 50-70 Sekunden,
    deshalb musste ich bei mir den Timeout der MySQL Workbench für eine Session von 60 Sekunden auf z.B 90 Sekunden erhöhen
  • In einem Interface Eurer Wahl zur Datenbank könnt Ihr die Procedure zum Testen dann aufrufen und das Ergebnis testen.
call dwd_load(curdate(),'none');

select * from dwdfull
-- WHERE TIMESTAMP > curdate()
order by TIMESTAMP desc
LIMIT 1000;

Sollte nun der Test der Procedure eine gefüllte Tabelle anzeigen, so kann nun die Integration ins FHEM erfolgen. Hierzu wird dann ein DbRep Device angelegt, dass später zyklisch jede Stunde ausgeführt wird.
Achtung, bei diesem Device kommt im weiteren Fortschritt noch ein weiteres Attribut zum Aufruf des Python KI Prognose Skriptes hinzu. Im Kommentar wird dies bereits im Syntax erwähnt.
defmod LogDBRep_PV_KI_Prognose DbRep LogDB
attr LogDBRep_PV_KI_Prognose DbLogExclude .*
attr LogDBRep_PV_KI_Prognose allowDeletion 0
attr LogDBRep_PV_KI_Prognose comment Version 2023.02.23 12:00\
\
Hier wird die Vorbereitung für die KI PV-Leistungsprognose durchgeführt\
\
sqlCmd call dwd_load(curdate(),'none');;\
[none|show] zum Anzeigen des Ergebnisses\
\
executeAfterProc:\
<absoluter Skript Name> <DbLog IP-Adresse> <FHEM IP-Adresse> <DbRep Name> <Wechselricher Name> <Prefix Reading Name>
attr LogDBRep_PV_KI_Prognose executeAfterProc "/opt/fhem/python/bin/PV_KI_Prognose.py 192.168.178.XXX 192.168.178.YYY LogDBRep_PV_KI_Prognose WR_1 Solar_yield_fc"
attr LogDBRep_PV_KI_Prognose room System
attr LogDBRep_PV_KI_Prognose verbose 3
Auch hier sollte nun getestet werden, indem man beim set das sqlCmd ausführt. Der MySQL Procedur Aufruf ist ebenfalls im Kommentar zu finden.

Als Ergebnis sollte soetwas zurück kommen. Nachdem das erschienen ist kann man den obigen Test mit dem SELECT der dwdfull Tabelle nochmals wiederholen.
SqlResultRow_1 NOW()
SqlResultRow_2 2023-03-17 11:01:03
sqlCmd call dwd_load(curdate(),'none');
sqlResultNumRows 1

Im nächsten Teil dieser Reihe kommt dann die Python KI Prognose.
Bitte beachtet auch, dass dies noch im Entwicklungsstatus ist und es immer mal wieder noch Änderungen geben wird.

VG Christian

P.S. Um den Thread nicht zu sehr mit diesem Thema zu fluten könnt Ihr mir Eure Probleme und Fragen besser als PN schicken, ich pflege das dann in den entsprechenden Posts ein und verbesser diese dann. Aus den Posts wird dann später das Wiki weiter gepflegt :-)
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

KI Prognose Teil 3 - Python KI Prognose Skript

Für die Verwendung der KI Prognose werden die folgenden Python Packages noch benötigt. Die Basis wäre hierbei der FHEM Docker Container.
Momentan habe ich das erstmal manuell im Container gemacht:
  • sudo apt-get install python3-pandas
  • sudo apt-get install python3-pymysql
  • sudo apt-get install python3-sqlalchemy
  • sudo apt-get install python3-sklearn python3-sklearn-lib
  • pip3 install fhem
Für Docker sollte das im .yml File dann so aussehen:
  • -e PIP_PKGS="pandas pymysql sqlalchemy sklearn sklearn-lib"
  • ob das mit dem "pip3 install fhem" so geht habe ich nicht getestet

Die Python Skripte liegen bei mir im Ordner
  • ./python/bin
  • ./python/bin/PV_KI_Prognose.py (Das Skript ist im Anhang)

Das PV_KI_Prognose.py wir mit folgenden Paramerter aufgerufen:
     <absoluter Skript Name> <DbLog IP-Adresse> <FHEM IP-Adresse> <DbRep Name> <Wechselricher Name> <Prefix Reading Name>
z.B. /opt/fhem/python/bin/PV_KI_Prognose.py 192.168.178.XXX 192.168.178.YYY LogDBRep_PV_KI_Prognose WR_1 Solar_yield_fc

  • Zum Test kann dies auch in "" in der FHEM Kommandozeile eingegeben werden, zuvor muss jedoch die MySQL Prozedur aufgerufen worden sein, damit die benötigte Tabelle mit den Daten erstellt worden ist.
  • Nach dem Testen kommt dieser Aufruf dann in das LogDBRep_PV_KI_Prognose Device und wird somit mit dem MySQL Prozeduraufruf synchronisiert.
    Bitte das LogDBRep_PV_KI_Prognose Device aus dem vorherigen Post verwenden (es wurde mit diesem Update aktualisiert!).
    Damit dann alles automatisch gestartet wird muss nun noch im PV_Schedule Device ein Eintrag eingefügt werden.
  • Achtung, im weiteren Thread Verlauf wurde jetzt auch schon ein WR_ctl Device eingeführt, was dann auch die Forecast Daten beinhaltet.
  • Für das WR_1 und WR_1_API Device gibt es auch ein Update für das stateFormat, damit es in Verbindung mit dem WR_ctl Device nicht alles doppelt anzeigt
< snip >
################################################################################################################
## 2 PV Prognose vom aktuellen Tag aktualisieren
##     zwischen 5 und 21 Uhr zur vollen Stunde
DOELSEIF
 ([05:00-21:00] and [:00])
## Das ist die bisherige Prognose, die noch weiterhin verwendet wird.
   ({Solar_forecast("LogDB","LogDBRep_PV_Forecast_SQL","WR_1","Solar_Calculation_fc","DWD_Forecast",0)})

## An dieser Stelle wird nun die PV_KI_Prognose gestartet, die dann im WR_1 Device für eine Übergangszeit
## zusätzliche readings erstellt. Nach einer Testphase wird das dann geändert.
   (set LogDBRep_PV_KI_Prognose sqlCmd call dwd_load(curdate(),'none') )

< snip >


Für die Netzwerkverbindung aus dem KI Python Skript werden die Zugansdaten im Filesystem abgelegt, damit sie nicht mit dem Skript ausversehen weiter gegeben werden.
  • ./python/pwd_fhem.json
  • ./python/pwd_sql.json
Die Verbindungsdaten werden in den Dateien wie folgt abgelegt:
fhem@raspberrypi:~/python$ cat pwd_[fhem|sql].json
{"username": "<Euer Username>",
 "password": "<Euer Passwort>"}
FHEM und die Datenbank müssen nicht auf dem selben Rechner installiert werden. Die IP-Adressen werden dem Skript beim Aufruf mitgegeben.

Es ist nicht erforderlich die neuen readings mit DbLogInclude aus dem WR_1 Device in die datenbank zu loggen, da dies bereits durch das PV_KI_Prognose Skript direkt geschieht, um einen passenden TIMESTAMP pro Stunde zu bekommen.

Wenn im LogDBRep_PV_KI_Prognose der verbose Level auf >= 3 steht kommen diverse Meldungen im Log:
2023.04.07 16:01:21.586 3: DbRep LogDBRep_PV_KI_Prognose - execute command after sqlCmd: '"/opt/fhem/python/bin/PV_KI_Prognose.py 192.168.178.XXX 192.168.178.YYY LogDBRep_PV_KI_Prognose WR_1 Solar_yield_fc"'

### Wer die Meldung weg bekommt, kann Lob und Anerkennung erwarten :-)
/usr/lib/python3/dist-packages/sklearn/externals/joblib.py:1: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  import imp

PV_KI_Prognose  running - start
PV_KI_Prognose  running - connected to 192.168.178.XXX
PV_KI_Prognose  running - dwdfull read from DbLog 192.168.178.YYY
PV_KI_Prognose  running - RandomForestRegressor loading
PV_KI_Prognose  running - RandomForestRegressor loaded
PV_KI_Prognose  running - RandomForestRegressor trained
PV_KI_Prognose  running - RandomForestRegressor fitted with yield
PV_KI_Prognose  running - old forecast deleted
PV_KI_Prognose  running - start forecast
Solar_yield_fc0_06  06 77
Solar_yield_fc0_07  07 448
Solar_yield_fc0_08  08 1133
Solar_yield_fc0_09  09 2073
Solar_yield_fc0_10  10 2921
Solar_yield_fc0_11  11 3637
Solar_yield_fc0_12  12 4168
Solar_yield_fc0_13  13 4348
Solar_yield_fc0_14  14 4348
Solar_yield_fc0_15  15 4080
Solar_yield_fc0_16  16 3557
Solar_yield_fc0_17  17 2877
Solar_yield_fc0_18  18 1787
Solar_yield_fc0_19  19 610
Solar_yield_fc0_20  20 103
PV_KI_Prognose  running - forecast written to FHEM
PV_KI_Prognose  running - old forecast deleted
PV_KI_Prognose  running - start forecast
Solar_yield_fc1_06  06 124
Solar_yield_fc1_07  07 1294
Solar_yield_fc1_08  08 3669
Solar_yield_fc1_09  09 5376
Solar_yield_fc1_10  10 6706
Solar_yield_fc1_11  11 8224
Solar_yield_fc1_12  12 8766
Solar_yield_fc1_13  13 8786
Solar_yield_fc1_14  14 8627
Solar_yield_fc1_15  15 7247
Solar_yield_fc1_16  16 5457
Solar_yield_fc1_17  17 4150
Solar_yield_fc1_18  18 2550
Solar_yield_fc1_19  19 900
Solar_yield_fc1_20  20 101
PV_KI_Prognose  running - forecast written to FHEM
--------------------------------------------
max       off/at 8792 12:00
Middayhigh_start 00:00
Middayhigh_stop  00:00
4h               12301
rest             13014
morning          10289
afternoon        25878
day              36167
--------------------------------------------
PV_KI_Prognose  done

20230602: Das PV_KI_Prognose.py Skript wurde aktualisiert.
20230704: Das PV_KI_Prognose.py Skript wurde aktualisiert.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

KI Prognose Teil 4 - Grafana Visualisierung

Dieser Post ist bereits ein Platzhalter in diesem Thread, damit alle Teile der KI Prognose zusammen hängend sind, bevor sie ins Wiki kommen.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Update: 20220328
Bisher haben sich 4 Mitstreiter gemeldet, bei denen auch bereits die dwd_load() Procedur läuft und die dwdfull Tabelle erstellt wird.
Falls es da noch Fragen gibt bitte per PN melden.
Am Ki Python Skript schreibe ich noch fleißig weiter, damit der nächste Schritt gemacht werden kann.


Update: 20220324
"KI Prognose Teil 2" hat sich die MySQL Prozedur geändert, da es eine inkompatibilität zu MariaDB gegeben hat.
Auch das "DROP PROCEDURE" ist nun direkt mit in dem Skript vorhanden und muss dann mit ausgeführt werden.



Moin,
im "KI Prognose Teil 2" hat sich die MySQL Prozedur geändert.
Die Änderung betrifft den Yield Bereich, da es bei längerem Laden des Speichers zu eine fehlerhaften Auswertung gekommen ist.
Bitte ladet die Procedur neu herunter, bevor diese gespeichert werden kann muss natürlich die bisherige vorher gelöscht werden.
DROP PROCEDURE IF EXISTS dwd_load;

VG  Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Moin zusammen,
Kostal scheint wohl an den ModBus Registern gebastelt zu haben, was jedoch unsere Implementierung nicht betroffen hat.
Kostal: Modbus Wert für Batterie Kapazität wird nicht mehr ausgelesen
Vor diversen WR updates wurde mal einige Speicher Registern ergänzt und bei dem älteren 529 scheint nun nichts mehr zu kommen.
Ihr könntet das ja mal checken und in dem anderen thread ergänzen.

VG  Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Moin,
heute hat die KI Prognose sogar den Einbruch beim Ertrag von 13:00 bis 14:00 Uhr getroffen :-)
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Mumpitz

Zitat von: ch.eick am 06 April 2023, 16:16:27Moin,
heute hat die KI Prognose sogar den Einbruch beim Ertrag von 13:00 bis 14:00 Uhr getroffen :-)


Ja dann warte ich gespannt auf deine Umsetzung  ;D

plin

Nachdem ich das Einspeiselimit rausgenommen habe lernt meine KI gerade was heutzutage alles geht.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB