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

Zitat von: Mumpitz am 01 Januar 2021, 20:13:07
Habe es bei mir eingebaut und das Hilfs DOIF vorerst disabled. Sobald die Batterie zum erstenmal voll ist werde ich berichten ob es geklappt hat!
Du kannst es ja eher testen, wenn Du den Schwellwert in DOIF änderst ;-)

Alles Gute
  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

Zitat von: ch.eick am 01 Januar 2021, 22:30:11
Du kannst es ja eher testen, wenn Du den Schwellwert in DOIF änderst ;-)

Alles Gute
  Christian

Ich bin eher der Typ des Live Testers und warte gespannt auf den Tag wo der Speicher wieder voll wird... :-)

Habe mir vorhin überlegt das wir durch die Schaltung ja im Herbst und Winter den Speicher schonen. So zumindest die Theorie. Ob es so ist werden wir wohl erst bei der Pensionierung erfahren :-)

Nun, was könnten wir im Frühling und Sonmer optimieren?
Meinen Akku Kenntnissen zur Folge hat es der Speicher ja ungern, wenn er auf 100% geladen wird. Das würde bedeuten, dass wir die maximale Kapazität begrenzen sollten auf 80-90%. Aber nur, wenn das Wetter am Tag darauf mitspielen wird. Was hältst du davon?

ch.eick

Zitat von: Mumpitz am 01 Januar 2021, 22:52:52
Habe mir vorhin überlegt das wir durch die Schaltung ja im Herbst und Winter den Speicher schonen. So zumindest die Theorie. Ob es so ist werden wir wohl erst bei der Pensionierung erfahren :-)
Ich bin auch mal gespannt, wie fitt der Speicher nach 15 Jahren sein wird.

Zitat
Nun, was könnten wir im Frühling und Sonmer optimieren?
Meinen Akku Kenntnissen zur Folge hat es der Speicher ja ungern, wenn er auf 100% geladen wird. Das würde bedeuten, dass wir die maximale Kapazität begrenzen sollten auf 80-90%. Aber nur, wenn das Wetter am Tag darauf mitspielen wird. Was hältst du davon?
Das hatte ich auch bereits angedacht, das Problem ist nur, dass dafür der Speicher weg konfiguriert werden muss und später wieder dazu. Das ist etwas unschön und ich hatte die Hoffnung, das da von Kostal noch eine FW Änderung kommen würde. Das, was gekommen ist, ist eine Zeitsteuerung bei der man man folgendes konfigurieren kann.


Intelligente Batteriesteuerung aktivieren   <<< zuerst deaktivieren
Zeitgesteuerte Batterienutzung      <<<< dann aktivieren

## Dann bestehen folgende Möglichkeiten
- Keine Einschränkung
- Batterieladung gesperrt, -entladung bei Hausbedarf erlaubt
  Das wäre dann die Option für den Sommer ab 90% Soc

- Batterieentladung gesperrt, -ladung bei Energieüberschuss erlaubt
  Hier wäre die Option, die wir bereits dynamisch nachgebaut haben


Die Zeitsteuerung wäre gut für Deine Tarif Zeiten zu nutzen. Um jedoch dynamisch zu reagieren finde ich das recht umständlich, man müsste jedesmal die Zeitsteuerung umprogrammieren und könnte nur im Zeitraster reagieren. Das war der Grund, warum ich mich für die jetzige Variante entschieden hatte.
Einen MaxSoc gibt es wohl noch nicht, genau so wenig wie eine vorgewählte Ladeleistung.

Ich möchte hier jedoch keine erneute Diskussion über die FW vom Plenticore starten. Das wurde bereits in diversen Threads im Photovoltaikforum besprochen.

Über folgende Einstellung kann man die Batterie weg konfigurieren:
Achtung, bitte zuerst den eigenen Batterie Typ auslesen und merken. Die Zuordnung der Ziffern zum Batterie Typ dann bitte hier melden, damit ich es im Wiki eintragen kann.

get PV_Anlage_1_API 22_Battery_InternControl
set PV_Anlage_1_API 22_7_Battery_Type 0

Mit diesem Eingriff übernimmt man jedoch auch die Verantwortung für die Batterieladung! Vergisst man die Batterie wieder zu aktivieren kann es z.B. zu einer Tiefentladung kommen.

Mit diesem Hintergrund empfehle ich also die Nutzung der Zeitsteuerung, die vom Hersteller bereit gestellt wurde, auch wenn ich mir etwas anderes wünschen würde.
Die Einstellung lässt sich bereits abfragen, jedoch habe ich es noch nicht über die API gesetzt. Auch wird die Rückmeldung noch nicht in einem reading aufbereitet.

attr PV_Anlage_1_API showBody 1
get PV_Anlage_1_API 23_Battery_TimeControl

[{"id":"Battery:TimeControl:ConfFri","value":"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"},
{"id":"Battery:TimeControl:ConfMon","value":"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"},
{"id":"Battery:TimeControl:ConfSat","value":"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"},
{"id":"Battery:TimeControl:ConfSun","value":"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"},
{"id":"Battery:TimeControl:ConfThu","value":"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"},
{"id":"Battery:TimeControl:ConfTue","value":"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"},
{"id":"Battery:TimeControl:ConfWed","value":"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"},
{"id":"Battery:TimeControl:Enable","value":"0"}]

Wenn jemand eine sinnvolle Verwendung erarbeitet, würde ich das gerne mit einbauen. Die verwendete Theorie würde mir reichen um die Logik dann umzusetzen.
Also her mit den Ideen ;-)

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 Freunde der gepflegten Diskussion

Ich nehme an bei euch ist der Ertrag im Moment echt beschissen. Ich habe in diesem Jahr knapp 2kWh per kWp. Unterirdisch ... Nichtsdestotrotz soll es weitergehen...

Folgende Idee zum aufräumen der Logs:
Dank Christian haben wir ja wunderbare Bezeichnungen, welche sich ideal anbieten mittels Wildcards zum aufräumen. Mache ich einen Denkfehler in meiner Theorie? Falls nein würde ich die entsprechenden DbRep Devices mal erstellen, hier einstellen und anschliessend fürs Wiki aufbereiten:

1. DbRep Device:
Alle Readings im PV_Anlage_1_API welche auf %_Day lauten können alle Werte bis auf den höchsten pro Tag gelöscht werden

2. DbRep Device:
Alle Readings im PV_Anlage_1_API welche auf %_Month lauten können alle Werte bis auf den höchsten pro Monat gelöscht werden

3. DbRep Device:
Alle Readings im PV_Anlage_1_API welche auf %_Year lauten können alle Werte bis auf den höchsten pro Jahr gelöscht werden

Anschliessend ein DOIF, welches monatlich am 2ten Tag des Monat die obigen 3 DbRep's ausführt. Ich würde vorschlagen dies dann das in das DB_Service_Schedule zu überführen.

Was haltet ihr von dieser Idee?

ch.eick

EDIT: 2021.01.09

Hi Mumpitz,

ich habe bereits auch einiges erstellt.

LogDBRep_Statistic_EnergyFeedInGrid_Year_diff_Week
LogDBRep_Statistic_EnergyHomePvSum_Year_diff_Week
LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month
LogDBRep_Statistic_Yield_Month_max_Month
LogDBRep_Statistic_Yield_Year_diff_Week
LogDBRep_delete_PV_Forecast
LogDBRep_delete_Statistic_EnergyHomeBat_Day_max_Day
LogDBRep_delete_Statistic_EnergyHomePvSum_Day_max_Day
LogDBRep_delete_Statistic_TotalConsumption_Day_max_Day

Somit müssten Deine Vorschläge bereits teilweise erledigt sein.

Ich stell das dann mal ins Wiki. <<< erledigt.

Um keine Werte durch Wildcards zu verlieren verwende ich momentan für jedes reading ein einzelnes DbRep. Gelöscht ist leider manchmal sehr schnell :-)

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

So, heute morgen hatte ich etwas Zeit, das erste DbRep Device für die regelmässige Löschung der Tageswerte, bis auf den höchsten, zu löschen:

defmod LogDBRep_Statistic_Day_max_Day DbRep DBLogging
attr LogDBRep_Statistic_Day_max_Day DbLogExclude .*
attr LogDBRep_Statistic_Day_max_Day aggregation day
attr LogDBRep_Statistic_Day_max_Day allowDeletion 1
attr LogDBRep_Statistic_Day_max_Day comment Version 2021.01.10\
Dieses DbRep device löscht alle Werte des PV_Anlage_1_API Reading welche Day im Namen haben bis auf den höchsten Wert pro Tag.
attr LogDBRep_Statistic_Day_max_Day device PV_Anlage_1_API
attr LogDBRep_Statistic_Day_max_Day reading %_Day
attr LogDBRep_Statistic_Day_max_Day showproctime 1
attr LogDBRep_Statistic_Day_max_Day devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr LogDBRep_Statistic_Day_max_Day room Log
attr LogDBRep_Statistic_Day_max_Day sortby 05
attr LogDBRep_Statistic_Day_max_Day timestamp_begin previous_year_begin
attr LogDBRep_Statistic_Day_max_Day timestamp_end previous_month_end


Nach der erstmaligen Ausführung könnte man dies mit einem monatlichen DOIF, jeweils am zweiten Tag des Monats, ausführen. Dabei könnte man
attr LogDBRep_Statistic_Day_max_Day timestamp_begin previous_year_begin

durch
attr LogDBRep_Statistic_Day_max_Day timestamp_begin previous_month_begin
ersetzen.

Ich selber habe es bei mir noch nicht ausgeführt. Was haltet ihr davon? Meiner Meinung nach sollten keine Werte gelöscht werden, welche wir irgendwo benötigen, oder?

ch.eick

Zitat von: Mumpitz am 10 Januar 2021, 12:33:17
So, heute morgen hatte ich etwas Zeit, das erste DbRep Device für die regelmässige Löschung der Tageswerte, bis auf den höchsten, zu löschen:

Ich selber habe es bei mir noch nicht ausgeführt. Was haltet ihr davon? Meiner Meinung nach sollten keine Werte gelöscht werden, welche wir irgendwo benötigen, oder?
Bei den Tages Werten sollte das so okay sein, es sei denn Du möchtest eventuell noch den Durchschnitts Wert. Das ist der Grund, warum ich da eher selektiv vor gehe, weg ist weg :-)

Für die Monats und Jahres Werte solltest Du eventuell berücksichtigen, das diese Werte Tages, Wochen oder Monatsweise steigen und auch wieder sinken können.
Dies gilt insbesondere für die Autarkie und den Eigenverbrauch, der ja sogar innerhalb des Tages schwankt und somit nicht als maxValue zu verwenden wäre.
Aus den Monat oder Jahr Werten bilde ich dann auch noch Werte für die Woche.

Mein Resümee ist, also besser nochmal darüber diskutieren, ansonsten hätte ich das bereits einfach ins Wiki eingetragen, aber mir fehlt noch die Erfahrung, was ich brauche.

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

Zitat von: ch.eick am 10 Januar 2021, 14:13:08
Dies gilt insbesondere für die Autarkie und den Eigenverbrauch, der ja sogar innerhalb des Tages schwankt und somit nicht als maxValue zu verwenden wäre.

ok, den Autarky_Day ist nun berücksichtigt:
defmod LogDBRep_Statistic_Day_max_Day DbRep DBLogging
attr LogDBRep_Statistic_Day_max_Day DbLogExclude .*
attr LogDBRep_Statistic_Day_max_Day aggregation day
attr LogDBRep_Statistic_Day_max_Day allowDeletion 1
attr LogDBRep_Statistic_Day_max_Day comment Version 2021.01.10\
Dieses DbRep device löscht alle Werte des PV_Anlage_1_API Reading welche Day im Namen haben bis auf den höchsten Wert pro Tag.
attr LogDBRep_Statistic_Day_max_Day device PV_Anlage_1_API
attr LogDBRep_Statistic_Day_max_Day reading %_Day EXCLUDE=Statistic_Autarky_Day,Statistic_OwnConsumptionRate_Day
attr LogDBRep_Statistic_Day_max_Day showproctime 1
attr LogDBRep_Statistic_Day_max_Day devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr LogDBRep_Statistic_Day_max_Day room Log
attr LogDBRep_Statistic_Day_max_Day sortby 05
attr LogDBRep_Statistic_Day_max_Day timestamp_begin previous_year_begin
attr LogDBRep_Statistic_Day_max_Day timestamp_end previous_month_end


Brauchst du für die Bestimmung der Mittelwerte wirklich die einzelnen Stände für jeden Zeitpunkt des Tages? Würde nicht der Mittelwert aller Tages Maximal Werte reichen?

Mumpitz

Ich schon wieder. Jetzt noch etwas zum Thema Forecast. Heute war bei uns endlich mal wieder ein Tag, bei welchem die Sonne durchgehend auf die Module brannte. Daher habe ich nun noch eine Frage zum Forecast. Die Berechnung gestern hat für den heutigen Tag 19677 Wh ergeben. Tatsächlich waren es 10900 Wh. Also fast die Hälfte daneben. Beim Diagramm sieht es ähnlich aus. Obwohl die Sonne nie durch Wolken getrübt wurde, erreicht die Produktion nie die Werte aus dem Forecast. Ich habe die entsprechende Grafik angehängt. An welchen Werten in der Config würdest du schrauben?

setstate WR_Plenticore_config 2020-12-15 15:49:14 forecast_cloudk 25
setstate WR_Plenticore_config 2020-11-07 16:53:44 forecast_cloudk_base 0
setstate WR_Plenticore_config 2020-12-26 22:24:59 forecast_factor 1.5
setstate WR_Plenticore_config 2020-11-07 16:53:57 forecast_raink 20
setstate WR_Plenticore_config 2020-11-07 16:54:11 forecast_raink_base 0
setstate WR_Plenticore_config 2020-11-07 16:48:53 forecast_tempk 48
setstate WR_Plenticore_config 2020-11-07 16:50:47 forecast_tempk_base 25
setstate WR_Plenticore_config 2020-09-10 21:23:35 module_1_count 16
setstate WR_Plenticore_config 2020-09-10 21:32:30 module_1_direction -90
setstate WR_Plenticore_config 2020-09-10 21:32:42 module_1_name East
setstate WR_Plenticore_config 2020-09-10 21:37:19 module_1_plain 29
setstate WR_Plenticore_config 2020-09-10 21:32:04 module_1_power 330
setstate WR_Plenticore_config 2020-09-10 21:24:07 module_2_count 16
setstate WR_Plenticore_config 2020-09-10 21:33:04 module_2_direction 90
setstate WR_Plenticore_config 2020-09-10 21:33:29 module_2_name West
setstate WR_Plenticore_config 2020-09-10 21:37:27 module_2_plain 29
setstate WR_Plenticore_config 2020-09-10 21:33:56 module_2_power 330

ch.eick

Zitat von: Mumpitz am 10 Januar 2021, 20:17:02
Ich schon wieder. Jetzt noch etwas zum Thema Forecast. Heute war bei uns endlich mal wieder ein Tag, bei welchem die Sonne durchgehend auf die Module brannte. Daher habe ich nun noch eine Frage zum Forecast. Die Berechnung gestern hat für den heutigen Tag 19677 Wh ergeben. Tatsächlich waren es 10900 Wh. Also fast die Hälfte daneben. Beim Diagramm sieht es ähnlich aus. Obwohl die Sonne nie durch Wolken getrübt wurde, erreicht die Produktion nie die Werte aus dem Forecast. Ich habe die entsprechende Grafik angehängt. An welchen Werten in der Config würdest du schrauben?

Moin Mumpitz,
als erstes sieht Dein Wert für SolarRadiationPrognose merkwürdig aus, wurden vom DWD so sehr unterschiedliche Werte geliefert? Ab 11:45 ist da ja ein richtiger Sprung drin.

Dann hast u den allgemeinen Korrektur Faktor gesetzt, der Dir die Prognose um 1,5 verstärkt. Setz den mal wieder auf 1

setstate WR_Plenticore_config 2020-12-26 22:24:59 forecast_factor 1.5


Wenn Du einen festen Faktor erkennen kannst, dann könnte man dort etwas eintragen, oder diesen auch pro Jahreszeit verändern, dafür müsste man das ganze aber auch längere Zeit auswerten.

Gruß
    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

plin

Zitat von: ch.eick am 11 Januar 2021, 08:46:48
Wenn Du einen festen Faktor erkennen kannst, dann könnte man dort etwas eintragen, oder diesen auch pro Jahreszeit verändern, dafür müsste man das ganze aber auch längere Zeit auswerten.
Kennt sich jemand mit KI aus? Wenn man auf Basis der eigenen Aufzeichnungen (Forecast Rad1h, Sonne, Bedeckung, ... , Ist-Werte) die KI die Abhängigkeiten und Faktoren ermitteln lässt wäre das die Gold-Lösung.

Andererseits gilt der Spruch: erstens kommt es anders und zweitens als man denkt

VG Peter
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

ch.eick

Zitat von: plin am 11 Januar 2021, 09:58:00
Kennt sich jemand mit KI aus? Wenn man auf Basis der eigenen Aufzeichnungen (Forecast Rad1h, Sonne, Bedeckung, ... , Ist-Werte) die KI die Abhängigkeiten und Faktoren ermitteln lässt wäre das die Gold-Lösung.

Andererseits gilt der Spruch: erstens kommt es anders und zweitens als man denkt
Ich wollte es einfach halten und hatte mich für den Faktor entschieden ;-) Bisher brauchte ich diesen jedoch noch nie und hatte ihn auf 1 gelassen. Der Sinn dahinter war einfach, dass man eine Möglichkeit hat den Forecast etwas anzuheben oder zu verringern, wenn man feststellt, dass er immer insgesamt zu hoch/niedrig ist.

@Mumpitz versuch einfach mal 1 und beobachte es. Du verwendest ja, nach meiner Erinnerung, auch die Gesamtsumme des Forecast vom ganzen Tag, was bei einem ein Stunden Rhythmus einen ungefähren kWh Wert liefert. Da steckt natürlich nochmals eine Ungenauigkeit drin! Für das fine Tuning sollte man sich auf die Optik verlassen und schauen, dass die Kurven so gut es geht beieinander liegen. Wenn man dann zufrieden ist, könnte man die Tagessumme als Trigger verwenden.

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

Zitat von: plin am 11 Januar 2021, 09:58:00
Wenn man auf Basis der eigenen Aufzeichnungen (Forecast Rad1h, Sonne, Bedeckung, ... , Ist-Werte) die KI die Abhängigkeiten und Faktoren ermitteln lässt wäre das die Gold-Lösung.
Hallo Peter,

hast Du eventuell noch eine Prognose für Schnee gefunden. Und eventuell einen Sittt Bum Faktor, wenn der Schnee, je nach Dachneigung , mit einem Bum, die PV Module wieder frei gibt? :-)
Das fände ich noch eine Änderung im Solar_forecast() für würdig.

Gruß
    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

plin

Zitat von: ch.eick am 11 Januar 2021, 12:36:45
hast Du eventuell noch eine Prognose für Schnee gefunden. Und eventuell einen Sittt Bum Faktor, wenn der Schnee, je nach Dachneigung , mit einem Bum, die PV Module wieder frei gibt? :-)
Das fände ich noch eine Änderung im Solar_forecast() für würdig.
Ich stecke noch bei Rad1h, R600, Neff, coud, ChOfRain, Sun etc. fest. Selbst das sind schon zu viele Faktoren.
Ich glaube egal was man ansetzt und als Faktor mit einbaut, man liegt immer falsch - zumindest wenn es sich um Stundenprofile handelt. Den Tagesertrag könnte man vielleicht noch auf Basis statistischer Auswerungen ermitteln, aber es gibt halt viele Einflussfaktoren. KI wäre dann der faule Weg. Ich denke nicht selbst drüber nach sondern die KI sagt's mir einfach.

P.S. DWD MOSMIX:
Schnee-Regen-Äquivalent (1-stündig)  letzte 1 Stunde    RRS1c
Schnee-Regen-Äquivalent (3-stündig)  letzte 3 Stunden   RRS3c
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

ch.eick

Zitat von: plin am 11 Januar 2021, 13:31:25
P.S. DWD MOSMIX:
Schnee-Regen-Äquivalent (1-stündig)  letzte 1 Stunde    RRS1c
Schnee-Regen-Äquivalent (3-stündig)  letzte 3 Stunden   RRS3c
Dann frage ich mal diese Werte ab und füge es eventuell in die Prognose mit ein.

EDIT: Für heute steht alles auf 0 :-)
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