Modul für DWD Open Data

[DS_Starter]

Hallo Jens,

ich habe deine Version  1.17.1 vom LWP befreit. Läuft bei mir unverändert stabil.
Läuft jetzt alles mit HttpUtils_BlockingGet. Meine Änderungen sind mit "# Heiko" gekennzeichnet.
Es gibt eine neue Funktion GetHeadersBGT. Zum Vergleich habe ich die GetHeaders noch drin gelassen.

LG,
Heiko

[Ingo298]

das war es, vielen dank habe buster auf 64bit kernel umgestellt und jetzt geht es

[stefanru]

Ah 32 Bit, ja klar da hilft alles nichts
Super das es gefunden wurde.

[jensb]

Hallo Heiko,

fc_dwdDocTime muss in UTC sein, sonst gibt es Ärger bei der Sommerzeitumstellung (z.B. keine Updates obwohl es welche gibt). Habe ein Z angehängt, damit man das sofort unterscheiden kann.

... ich habe eine Möglichkeit gefunden, LWP wieder loszuwerden und den Header mit HttpUtils_BlockingGet zu lesen ...

GetHeadersBGT sieht gut aus, werde ich in die übernächsten Version integrieren, Danke.

Inzwischen ist meine Version 1.17.2 im Dauertest, die die Update-Prüfung auch bei den Alerts macht. Sie wird auch das Attribut forecastDataPrescision mit forecastRefresh ablösen, womit man die Möglichkeit hat zwischen 1 bis 6 h Updaterate zu wählen.

Übers Wochenende werde ich mich an die RAM-Optimierung für MOSMIX S machen. Mein Pi läuft zwar mit 64 Bit, aber er hat nur 2 GB und Swappen ist nicht die Lösung.

Ein Ansatz, der insbesondere wenn man sich für mehrere Stationen interessiert relevant ist, wäre die heruntergeladene Datei im tmp-Verzeichnis zu belassen, so dass man die Daten nicht mehrfach herunterladen muss. Das wäre aber schon der übernächste Schritt.

Grüße,
Jens

[DS_Starter]

Hallo Jens,

fc_dwdDocTime muss in UTC sein, sonst gibt es Ärger bei der Sommerzeitumstellung (z.B. keine Updates obwohl es welche gibt). Habe ein Z angehängt, damit man das sofort unterscheiden kann.

Ach ja, die Zeitumstellung...
Dann schlage ich vor ein verstecktes .fc_dwdDocTimeUTC für den logischen Vergleich mitzuführen, das lesbare Reading im Sinne der Einheitlichkeit wie die anderen Zeitreadings auch in Localtime auszugeben.

...Reading forecastDataPrescision mit forecastRefresh

Du meinst sicher das Attribut 

Es geht wirklich super voran, danke für dein Engagement. 

Grüße,
Heiko

[jensb]

Du meinst sicher das Attribut

Klar, korrigiert.

[jensb]

Es gibt eine weitere Alpha-Version 1.17.2 des DWD_OpenData-Moduls in meinem Contrib-Verzeichnis:

Wesentliche Änderungen im Vergleich zu 1.17.1:

• Kein Alert-Download, wenn sich das Dokument auf dem DWD-Server nicht geändert hat. Das erspart in der Praxis leider nur selten den Download, da der DWD das Dokument auch aktualisiert, wenn sich nichts geändert hat (Lebenszeichen).
• Attribut forecastDataPrescision durch Attribut forecastRefresh ersetzt. So kann die Updaterate zwischen 1 bis 6 h frei gewählt werden. Bei 6 h kommt MOSMIX L zum Einsatz, sonst MOSMIX S. Damit kann man das Downloadvolumen verringern, wenn es nicht ganz so aktuell sein muss.

Hinweise:

• Diese Version ist nur eine Zwischenschritt und daher eher etwas für Experimentierfreudige. Sie löst noch nicht das bekannte RAM-Ressourcenproblem bei MOSMIX S. Optimierung geplant.
• Diese Version benötigt das Perl-Modul LWP::UserAgent. Das ist kein Perl Core Modul, sollte aber im Normalfall vorhanden sein.
• Diese Version verwendet 2 unterschiedliche Methoden, um auf den DWD-Server zuzugreifen. Das könnte zu Problemen führen, wenn man einen Proxy verwendet, vor allem einen Proxy mit Authentifizierung. Vereinfachung geplant.

[DS_Starter]

Hallo Jens,

habe deine V 1.17.2 genommen und melde falls mir etwas auffallen sollte.

Grüße,
Heiko

[jensb]

Hallo Heiko,

versuche mich gerade am RAM-Sparen, aber das heißt erst mal modularisieren. HttpUtils_BlockingGet liefert direkt in den Speicher und das muss erst mal in ein TEMP-File. Dazu werde ich LWP:UserAgent verwenden. Anschließend kann man das TEMP-File zeilenweise lesen, filtern und den benötigten Teil wie bisher verarbeiten.

Grüße,
Jens

[DS_Starter]

HttpUtils_BlockingGet liefert direkt in den Speicher

Ja, aber das File ist doch gezippt und "nur" 35MB groß. Das sollte doch auch mit HttpUtils_BlockingGet kein Problem für den Speicher sein um das File als zip-File zu speichern. Du wolltest doch sowieso auf das Entpacken verzichten, oder?
Dann könntest du doch auf LWP verzichten m.M. nach.

Grüße,
Heiko

[jensb]

Die aktuelle MOSMIX S Datei auf dem DWD-Server ist zwar "nur" ~40 MB groß, aber ich kenne keine Möglichkeit, auf das Entpacken zu verzichten, und dann sind wir bei ~700 MB.

Habe mir die Beschreibung von IO::Uncompress::Unzip angesehen. Es gibt eine getline()-Funktion, aber es bleibt unklar, ob man damit verhindern kann, dass die 700 MB im RAM liegen.

Erst wenn man an den Inhalt des Zips kommt, kann man vor der Weiterverarbeitung die Daten der relevanten Station herausschneiden, wie das mumpitzstuff vorgeschlagen hat.

[DS_Starter]

Die aktuelle MOSMIX S Datei auf dem DWD-Server ist zwar "nur" ~40 MB groß, aber ich kenne keine Möglichkeit, auf das Entpacken zu verzichten, und dann sind wir bei ~700 MB.

Ok ... nur das Entpacken ist unabhängig davon ob du das gepackte File via LWP oder HttpUtils_BlockingGet abholst oder nicht?
Aber vllt. übersehe ich ja etwas...

 

[jensb]

In der Beschreibung von HttpUtils_BlockingGet steht das der Dateiinhalt als String zurückgeliefert wird und der wäre dann bei ~700 MB.

Eine Option den Stream gleich in eine Datei zu schicken sehe ich bei HttpUtils_BlockingGet nicht.

[DS_Starter]

In der Beschreibung von HttpUtils_BlockingGet steht das der Dateiinhalt als String zurückgeliefert wird und der wäre dann bei ~700 MB.

HttpUtils_BlockingGet entpackt aber nichts. Hast du das File mal mit HttpUtils_BlockingGet abgeholt und gespeichrt? Es gibt ja auch noch in HttpUtils das GetHttpFile oder GetFileFromURL als FHEM Alternative.

[jensb]

Das Entpacken ist schon immer ein eigener Schritt nach HttpUtils_BlockingGet gewesen. Die Varianten GetHttpFile und GetFileFromURL habe ich mir auch angesehen, aber die verwenden wiederum HttpUtils_BlockingGet und damit ist dann nichts gewonnen.