Tägliche Regenmenge aus DWD-Radolan Daten einlesen

[alkazaa]

Die neue sub rain_since_midnight() ist soweit fertig, aber Integration ins 98_CDCOpenData.pm hab ich mich nicht getraut. Anbei daher nur eine aktualisierte 99_myDWDUtils.pm mit der rain_since_midnight Routine.

rain_since_midnight liefert die aufsummierten Regenmengen aus den 'hourly' Radolan Dateien nur für den aktuellen Tag, an dem sie aufgerufen wird. Ausgewertet werden die Dateien, die für 00:50, 01:50 usw. an dem Tag veröffentlicht wurden.

Beste Grüße
Franz

Edit:
Fehler in 99_myDWDUtils.pm korrigiert (s. Variable $most_recent_filetime)

[JoWiemann]

Hallo,

aktueller Stand für das Modul:

- rain_since_midnight habe ich integriert und teste gerade
- Ausführung per CRON Systematik, siehe auch Modul jsonmod ist in der Mache
. neues Attribut für das Ablegen der tmp DWD Daten in ein selbst vorgegebenes Verzeichnis
- neues Attribut um Funktionen, aktuell rain_since_midnight und tägliche Regenmenge, Ab-/Anwählen zu können

Grüße Jörg

[alkazaa]

Hallo Jörg,

ich hänge eine Variante von "sub CDCOpenData_Readout_Run_FTP" an, in welcher der Name der benötigten Datei (raa01-sf_10000-YYMMDD2350-dwd---bin für das Datum 20YY-MM-DD) auf weniger komplizierte Weise ermittelt wird. Da der CDC OpenData Server Daten seit 2006 bereit stellt und die Dateinamenskonvention seitdem nicht geändert wurde, scheint mir das relativ risikolos.

Mit diesem Dateinamen wird zunächst im temp_radolan_data Verzeichnis geschaut, ob's die Datei schon gibt und  ggf. die ganze ftp-Kommunikation unnötig ist.
Vorteil:
Wer an historischen Daten interessiert ist, z.B. für eigene "amateur-meteorologische" Zwecke, kann sich händisch aus den *.tar.gz Dateien des CDC Servers die entsprechenden historischen Daten ins temp_radolan_data Verzeichnis laden und danach mit 98_CDCOpenData.pm und zusätzlichem perl-scripting diese Daten in eine dbLog Datenbank bringen. Damit stehen dann viele Möglichkeiten für weitere Auswertung und Visualisierung zur Verfügung.

Details und Anleitungen für ein solches Vorgehen würde ich dann im FHEM-Wiki hinterlegen. Begonnen damit habe ich schon.

-Franz

[JoWiemann]

Hallo Jörg,

ich hänge eine Variante von "sub CDCOpenData_Readout_Run_FTP" an, in welcher der Name der benötigten Datei (raa01-sf_10000-YYMMDD2350-dwd---bin für das Datum 20YY-MM-DD) auf weniger komplizierte Weise ermittelt wird. Da der CDC OpenData Server Daten seit 2006 bereit stellt und die Dateinamenskonvention seitdem nicht geändert wurde, scheint mir das relativ risikolos.

Hallo,

anbei eine Version, in der ich die Änderungen von Franz eingebaut habe.

Außerdem die neuen Attribute:

tmpRadolanData => Festlegen eines eigenen TMP Verzeichnisses
disableMidNight:0,1 => abholen der Regenmenge seit Mitternacht abschalten
disableDayRain:0,1  => abholen der Tages Regenmenge abschalten

Das Ganze ist noch nicht ganz rund. Das get ... rainsincemidnight-bydate funktioniert noch nicht.

Die commandRef ist noch nicht angepasst und es gibt noch viele Log Einträge.

Bitte Fhem neu starten. Ein reload reicht nicht aus.

Grüße Jörg

[alkazaa]

Danke Jörg. Das war ja flott!

Ich habe noch einen Fehler korrigiert, und zwar war in Zeile 825-836 nicht $tmpDir genutzt, sondern das alte hard-coded 'tmp_radolan_data':

Code Auswählen Erweitern

     if (defined $retr_fh) {
       CDCOpenData_Log $name, 3, "Trying to load new local file /$tmpDir/$localname " . $retr_fh
     } else {
       CDCOpenData_Log $name, 3, "ERROR: ftp /$remotename not found";
       $ftp->quit;
       $returnStr .= "ERROR: ftp /$remotename not found";
       return $returnStr;
     }

     # use it to gunzip the remote file:
     gunzip $retr_fh => "$tmpDir/" . $localname, AutoClose => 1 ;
     CDCOpenData_Log $name, 3, "INFO: Loaded new local file /$tmpDir/$localname";

Das Ganze ist noch nicht ganz rund. Das get ... rainsincemidnight-bydate funktioniert noch nicht.

rainsincemidnight-bydate macht mMn keinen Sinn: die Funktion sollte nur die Regenmengen liefern, die seit dem letzten 'daily-rain' report zur Zeit des Aufrufs der Funktion gefallen sind. Für ne Bewässerungssteuerung ist das hilfreich. Für zurückliegende Tage kriegt man ja die Gesamtmenge ohnehin geliefert.

Gruß
Franz

[JoWiemann]

Hallo,

anbei eine neue Version. Fehler korrigiert.

@Franz,

ausgehend, dass die Dateinamen Datum/Uhrzeit in MEZ/MESZ beinhalten habe ich alles auf timelocal angepasst. Es gab da ein paar Umwandlungen in gmt und andere im local. Dadurch wurden bei rain since midnight noch die beiden letzten Dateien des Vortages verarbeitet.

Das get ... rainsincemidnight-bydate ist nur noch ein get ... rainsincemidnight. Die Rückgabewerte aller get habe ich auf location:Datum Uhrzeit:Regenmenge angepasst. Mehrere Locationen werden durch | getrennt.

Grüße Jörg

[alkazaa]

Hallo und Danke!

Es funktioniert alles soweit, bis auf dies:

Dadurch wurden bei rain since midnight noch die beiden letzten Dateien des Vortages verarbeitet.

Die letzten beiden Dateien des Vortags sind richtig, denn die im Dateinamen enthaltenen Zeitstempel sind GMT Zeiten.
Beispiel: Als ich heute um ca. 15:48 ein 'set update' machte, standen danach im temp_radolan Verzeichnis diese Dateien:

Code Auswählen Erweitern

raa01-rw_10000-2309200050-dwd---bin
raa01-rw_10000-2309200150-dwd---bin
raa01-rw_10000-2309200250-dwd---bin
raa01-rw_10000-2309200350-dwd---bin
raa01-rw_10000-2309200450-dwd---bin
raa01-rw_10000-2309200550-dwd---bin
raa01-rw_10000-2309200650-dwd---bin
raa01-rw_10000-2309200750-dwd---bin
raa01-rw_10000-2309200850-dwd---bin
raa01-rw_10000-2309200950-dwd---bin
raa01-rw_10000-2309201050-dwd---bin
raa01-rw_10000-2309201150-dwd---bin
raa01-rw_10000-2309201250-dwd---binIn MESZ sind das die Dateien von 02:50 bis 14:50 (2 Stunden weiter als GMT). Es fehlen also die Dateien

Code Auswählen Erweitern

raa01-rw_10000-2309192250-dwd---bin  für MESZ 00:50
raa01-rw_10000-2309192350-dwd---bin  für MESZ 01:50
Diese Besonderheit der GMT-basierten Zeiten in den Radolan Daten hat ja leider die ganze GMT<->local Gymnastik erforderlich gemacht.

Man siehts auch an der für die daily-rain Daten zutändigen Datei

Code Auswählen Erweitern

raa01-sf_10000-2309192150-dwd---bin  für MESZ 23:50 vom Vortag im temp-radolan Verzeichnis.

Grüße
Franz

[JoWiemann]

Hallo und Danke!

Es funktioniert alles soweit, bis auf dies:

Dadurch wurden bei rain since midnight noch die beiden letzten Dateien des Vortages verarbeitet.

Die letzten beiden Dateien des Vortags sind richtig, denn die im Dateinamen enthaltenen Zeitstempel sind GMT Zeiten.

Grüße
Franz

Ok, dann mache ich Rolle rückwärts.

[alkazaa]

Hallo,
es läuft, aber noch nicht ganz rund. Nach einer device definition (locations anonymisiert) mit z.B.

Code Auswählen Erweitern

defmod myCDC CDCOpenData
attr myCDC INTERVAL 3500
attr myCDC event-on-change-reading .*
attr myCDC locations C:x1,y1 S:x2,y2 B:x3,y3 T:x4,y4ergeben sich die readings wie im angehängten Bild 1. Für die meisten locations taucht _since_midnight-amount-of-rain korrekt auf, für manche (in diesem Beispiel für Ort C) taucht aber nur C_since_midnight-amount-of-rain-time mit einem timestamp als Wert auf. Es scheint zufällig zu sein, bei welcher location das passiert. Eine Ausführung von 'get rainSinceMidnight' z.B. kann das dann auch so ändern wie in Bild 2 gezeigt. Scheint alles irgendwie zufällig zu passieren.

Gruß
Franz

[enno]

Moin,

gleiches Problem bei mir. Ich habe allerdings die Location in Global definiert.

Ich bekomme nur folgende Readings: Home_day_rain-amount-of-rain, Home_day_rain-amount-of-rain-time, Home_since_midnight-amount-of-rain-time


Gruss
  Enno

[JoWiemann]

Hallo,
es läuft, aber noch nicht ganz rund. Nach einer device definition (locations anonymisiert) mit z.B.

Code Auswählen Erweitern

defmod myCDC CDCOpenData
attr myCDC INTERVAL 3500
attr myCDC event-on-change-reading .*
attr myCDC locations C:x1,y1 S:x2,y2 B:x3,y3 T:x4,y4ergeben sich die readings wie im angehängten Bild 1. Für die meisten locations taucht _since_midnight-amount-of-rain korrekt auf, für manche (in diesem Beispiel für Ort C) taucht aber nur C_since_midnight-amount-of-rain-time mit einem timestamp als Wert auf. Es scheint zufällig zu sein, bei welcher location das passiert. Eine Ausführung von 'get rainSinceMidnight' z.B. kann das dann auch so ändern wie in Bild 2 gezeigt. Scheint alles irgendwie zufällig zu passieren.

Gruß
Franz

Hallo Franz,

das Phänomen habe ich auch. Ich schreibe ins Log den Rückgabestring für die Überführung ins Reading. Schau bitte, ob der String auffällig ist.

Bin aktuell die nächsten Tage wandern. Wird also erst ab 03.10 wieder was.

Grüße Jörg

[alkazaa]

Hallo Jörg,

Was das merkwürdige Verhalten angeht: mir fiel beim Blick ins log auf, dass jedesmal alle readings mit 'since_midnight' im Namen gelöscht werden, und auch jedesmal wieder neu angelegt. Die Reihenfolge, in der das passiert, ist aber jedesmal eine andere.
Als workaround habe ich die Zeilen 1020-1021, in denen das Löschen passiert, auskommentiert. Dann scheint es zu funktionieren. Ich hoffe, es hat keine Nebenwirkungen.
Was war überhaupt der Grund, die since_midnight readings immer wieder zu löschen?

Aber keine Eile mit der Antwort bitte, sondern erstmal viel Spaß beim Wandern! Und natürlich das passende "indian summer" Wetter dazu!

Gruß
Franz

[JoWiemann]

Was war überhaupt der Grund, die since_midnight readings immer wieder zu löschen?

Hallo Franz,

aus meiner Sicht ist _since_midnight nur für den aktuellen Tag sinnvoll. Wird es nicht gelöscht kommen unendlich viele Readings dazu. Auch bei den _day_rain Readings möchte ich eine Begrenzung auf x Tage, kann über eine Attribut gesteuert werden, begrenzen.

Anbei erst einmal eine neue Version, in der das komische Verhalten nicht mehr aufkommt. Das Problem war das Leerzeichen im Reading Namen. Ist nicht zulässig. Außerdem habe ich das Attribut cronTime einegführt. Wird dieses, basierend auf den Regeln von Cron, gesetzt, dann ist INTERVALL deaktiviert und es gilt die Cron Regel.

Grüße Jörg

[alkazaa]

aus meiner Sicht ist _since_midnight nur für den aktuellen Tag sinnvoll. Wird es nicht gelöscht kommen unendlich viele Readings dazu

OK, klar. Ich hatte das datetimeInReadingName Attribut nicht auf dem Schirm...
Ich habe übrigens noch ein weiteres Gimmick in Arbeit, lasse Dich also noch nicht in Ruhe

-Franz

[JoWiemann]

Ich habe übrigens noch ein weiteres Gimmick in Arbeit, lasse Dich also noch nicht in Ruhe

Hallo Franz,

da bin ich mal gespannt. Ich fände auch die aktuellen Daten zur Umweltstrahlung interessant.

Grüße Jörg