Modul für DWD Open Data

[DS_Starter]

Das Entpacken ist schon immer ein eigener Schritt nach HttpUtils_BlockingGet gewesen.

Dann passt es doch. Meiner Meinung nach kannst du das gepackte File mit HttpUtils_BlockingGet holen und so wie es ist speichern. Wäre das Gleiche wie mit LWP. Danach kann man es entpacken oder sonstwas damit machen.
Müßte man natürlich mal testen. Jedenfalls bräuchten wir dann kein LWP wenn das funktioniert.

[jensb]

Bin bei dir, der Download geht dann doch mit HttpUtils_BlockingGet .

[jensb]

KMZ File download -> HttpUtils_BlockingGet -> Variable -> unzip -> TEMP-File -> Variable funktioniert

Das bewirkt natürlich so erst mal nichts Neues, außer dass es über eine Datei läuft. Aber jetzt kann man die Datei auch zeilenweise filtern, statt sie komplett zu laden.

[jensb]

Habe mich für ein Datei mit festem Namen im TEMP-Verzeichnis entschieden, denn sonst bleiben große Dateien übrig, wenn mal was schief geht. Hier ist das Ergebnis:

2024.03.02 22:44:49.700 5: DWD: GetForecast START (PID 20640)
2024.03.02 22:44:49.725 5: DWD: GetForecast END
2024.03.02 22:44:49.739 5: DWD: IsDocumentUpdated BEFORE
2024.03.02 22:44:50.029 5: DWD: IsDocumentUpdated docSize:37936832/0 docTime:2024-03-02 21:22:17Z/2024-03-02 21:22:17Z
2024.03.02 22:44:50.030 5: DWD: IsDocumentUpdated AFTER
2024.03.02 22:44:50.030 5: DWD: GetForecastStart 2024-03-02 21:22:17Z 1709414537 1709414537 16200 1
2024.03.02 22:44:50.030 5: DWD: GetForecastStart START (PID 18827)
2024.03.02 22:44:51.400 5: DWD: GetForecastDataDiskless: data received, unzipping ...
2024.03.02 22:45:16.505 5: DWD: GetForecastDataDiskless: unzipped 666223134 bytes, filtering ...
2024.03.02 22:45:19.882 5: DWD: GetForecastDataDiskless: filtered 130164 bytes
2024.03.02 22:45:19.882 5: DWD: ProcessForecast START ...

Download 38 MB:   1,4 s
Unzip      666 MB: 25,1 s
Filter        130 kB:   3,4 s

[DS_Starter]

Sieht doch gut aus. 

[jensb]

Sehe ich auch so. Das unzippen dauert zwar, aber das ist bei der Datenmenge und der CPU-Leistung eines Pi 4 nicht anders zu erwarten. Der RAM-Bedarf ist dafür minimal und damit kann man das auch auf Systemen mit kleinem RAM nutzten.

Die Last wird vom RAM auf die Disk verlagert. Wer eine SD-Card verwendet, sollte besser ein tmpfs für /tmp verwenden, wenn genug RAM da ist - denn der Datendurchsatz geht auf die Lebensdauer. Vielleicht ist es auch erforderlich, dass ein Attribut für das TEMP-Verzeichnis eingeführt wird, denn der eine oder andere hat vielleicht eine HDD mit Platz.

Werde diese Version auf jeden Fall bis morgen bei mir laufen lassen, bevor ich sie einchecke.

Der nächste Schritt wäre die Unterstützung von mehreren Stationen, möglichst basierend auf einem einzigen Download/Unzip. Bei den Alerts geht das jetzt schon mit mehreren FHEM-Modulen, die einen gemeinsamen Cache nutzten. Vielleicht kann man das bei den Forecast so ähnlich machen.

Hier noch eine Frage an die User der Alpha-Versionen:

Für das Download- und Verarbeitungs-Timeout (Unzip + Filter + Dekodierung) muss eine obere Grenze festgelegt werden. Aktuell sind beim Download max. 60 s und für die Verarbeitung max. 30 s vorgesehen.

Braucht jemand mehr? Wenn ja, wieviel?

[DS_Starter]

Morgen Jens,

ich selbst habe mit den Zeitlimits kein Thema, aber ein User aus dem SolarForecast Umfeld hatte wegen seiner begrenzten Internetanbindung ein Problem mit zu kleinem Timeout.
Ich habe einen Link zu diesem Beitrag gepostet. Vllt. meldet er sich.

LG

[erwin]

Re: Timeout Limits
Ich habe aktuell auch kein Problem, aber - nachdem das alles via Blocking-call gemacht wird, könnte man den Usern mehr Spielraum geben..., Die defaults dürften für aktuelle Systeme passen!
PS: ich teste (erstmalig) Docker, muss forschen wie ich da ein tmpfs anlege.....
l.g.erwin

[Ingo298]

Die Last wird vom RAM auf die Disk verlagert. Wer eine SD-Card verwendet, sollte besser ein tmpfs für /tmp verwenden, wenn genug RAM da ist - denn der Datendurchsatz geht auf die Lebensdauer. Vielleicht ist es auch erforderlich, dass ein Attribut für das TEMP-Verzeichnis eingeführt wird, denn der eine oder andere hat vielleicht eine HDD mit Platz.

Hallo Jens,

wieviel MB ist dan bei tmpfs einzurichten? Ich habe ein Pi4 mit 8GB RAM

[kask]

Hallo Jens,

wieviel MB ist dan bei tmpfs einzurichten? Ich habe ein Pi4 mit 8GB RAM

Ich denke, so wie ich das verstehe, wird der download stream direkt entpackt und ins temp geschoben. Also 700MB minigens.

KMZ File download -> HttpUtils_BlockingGet -> Variable -> unzip -> TEMP-File -> Variable funktioniert

Wobei die 700MB recht viel wären meines erachtens.
Und passt nicht zu:

Der RAM-Bedarf ist dafür minimal und damit kann man das auch auf Systemen mit kleinem RAM nutzten.

Ok, ohne den Schnickschnack verleibt sich das ganze um die 3GB alles zusamen bei mir rein (inkl. Swap).

Was mich da etwas irritiert ist:

2024.03.02 22:45:16.505 5: DWD: GetForecastDataDiskless: unzipped 666223134 bytes, filtering ...
2024.03.02 22:45:19.882 5: DWD: GetForecastDataDiskless: filtered 130164 bytes

Entweder ist es im ram oder schon im Temp und wird dann geshrinkt. Dauert ja 3377ms.
Ertes würde bei einem 4Gb Raspberry 17% Ram abknapsen. Und letzteres würde die sd-karte/ssd/hdd penetrieren.
Da wären die 17% aber doch besser wie 75% wie es vorher waren.

Ja, was ist es jetzt?

[stefanru]

Hi,
sorry für die späte Antwort, ja 60s Download hätte bei 6MBit/s bei 70 MB auch knapp werden können.
Ich würde für den Download bis zu 120 erlauben.

Ich habe aber seit ein paar Tagen Glasfaser

Gruß,
Stefan

[jensb]

Ja, was ist es jetzt?

Es wird wohl keine Antwort geben, die bei jedem passt, dafür sind die Voraussetzungen einfach zu unterschiedlich. Mir war wichtig, dass man nicht unbedingt 4 GB RAM haben muss, damit es überhaupt funktioniert.

Um es noch mal klar zu stellen: Die stündliche Abfrage der Vorhersagedaten benötigt nicht 6x soviel wie die bisherige, sondern mehr als 10000x soviel (Datenvolumen, Rechenleistung, ~2.9 kB/h vs. ~39 MB/h)!

Reine RAM-Verarbeitung vs. Verarbeitung über tmpfs ist natürlich ein Verschiebebahnhof. Um es noch einmal klar zu stellen: tmpfs ist nur dann relevant, wenn man eine SD-Karte hat. Eine magnetische Festplatte hat mit dem Durchsatz überhaupt kein Problem und eine SSD sollte das auch nicht jucken. Sowohl bei SD-Karte als auch bei SSD kann man sich mit Overprovisioning sehr viel Luft verschaffen, ohne dass man sich um die Lebensdauer Sorgen machen muss. tmpfs ist einfach "nice to have" wenn man doch genug RAM dafür über hat. Es beschleunigt ggf. auch andere Systemabläufe.

Danke für die Rückmeldungen zum Download-Timeout. Werde versuchen 120 s als obere Grenze zu ermöglichen. Es gibt trotz BlockingCall nicht die Möglichkeit, hier eine freie Wahl zu lassen, denn das Modul ist sowohl für Vorhersagen (1 ... 6 h) als auch für Wetterwarnungen zuständig (15 min). Also muss alles innerhalb von 15 min erfolgen und es soll ja auch möglich sein z.B. 3 Module gleichzeitig arbeiten zu lassen. Also bleibt bei 3 Modulen für jedes weniger als 5 min. Nur wenn man die Recourcenanforderungen hochsetzt und z.B. 3 statt 2 Cores ansetzt, könnte man noch mehr parallel abwickeln. Aber nicht jeder kann oder will dafür seine Hardware aufrüsten.

Grüße,
Jens

[Prof. Dr. Peter Henning]

Also, ich habe keine Probleme damit, das Modul in einer meiner FHEM-Nebeninstallationen zu betreiben: RPI 2, wohlgemerkt...

Ist euch eigentlich klar, um was es sich bei dem Dateiformat handelt?

Die Keyhole Markup Language ist eine militärische Anwendung, um Daten aller Art mit einer Geolokation zu verknüpfen. Benannt nach den US-amerikanischen Keyhole-Spionagesatelliten. Das kmz-Format ist nicht einfach nur gezipptes KML, sondern kann weitere strukturierte Daten beinhalten - z.B. COLLADA-Files, also 3D-Modelle. Das wird u.a. in Google Earth verwendet.

2006 habe ich mal in einem Projekt ein Geoinfomationssystem entwickelt, bei dem wir auch nach KMZ exportieren konnten. Ich fände es interessant, die DWD-Daten tatsächlich raumbezogen darzustellen.

LG

pah

[mumpitzstuff]

Code Auswählen Erweitern

use strict;
use warnings;
use IO::Uncompress::Unzip qw(unzip $UnzipError);
use Time::HiRes qw(gettimeofday);


# dieser Teil würde durch den Download erledigt werden
open my $fh_zip, '<:raw', 'MOSMIX_S_LATEST_240.kmz' or die "Could not open file for reading: $!";
my $fileContent = do { local $/; <$fh_zip> };
close $fh_zip;

my $t0 = gettimeofday();

#open(my $fh_xml, '<', 'MOSMIX_S.kml');

my $z = new IO::Uncompress::Unzip(\$fileContent) or die "unzip failed: $UnzipError\n";

my $line;
#my $lineOrg;
my $collect = 0;
my $collectString = '';

while ($line = $z->getline())
{
    #$lineOrg = <$fh_xml>;
   
    # nur ein check ob alles in Ordnung ist
    #if ($line ne $lineOrg)
    #{
    #    print 'Org: '.$lineOrg;
    #    print 'New: '.$line;
    #    last;
    #}
   
    if (index($line, '<dwd:Issuer>') != -1)
    {   
        print $line;
    }
    elsif (index($line, '<dwd:IssueTime>') != -1)
    {
        print $line;
    }
    elsif (index($line, '<dwd:ForecastTimeSteps>') != -1)
    {
       $collect = 1;
    }
    elsif (index($line, '</dwd:ForecastTimeSteps>') != -1)
    {
       $collect = 0;
       print $collectString.$line;
       $collectString = '';
    }
    elsif (index($line, '<dwd:FormatCfg>') != -1)
    {
       $collect = 1;
    }
    elsif (index($line, '</dwd:FormatCfg>') != -1)
    {
       $collect = 0;
       print $collectString.$line;
       $collectString = '';
    }
    elsif (index($line, '<kml:Placemark>') != -1)
    {
       #print 'Collection started: '.$line;
       $collect = 1;
    }
    elsif (($collect == 1) && (index($line, '</kml:Placemark>') != -1))
    {
       $collect = 0;
       print $collectString.$line;
       last;
    }
    elsif (index($line, '<kml:name>') != -1)
    {
        # Beispielstation (relativ weit hinten)
        if (index($line, '<kml:name>06770</kml:name>') == -1)
        {
            print 'Filtered: '.$line;
            $collect = 0;
            $collectString = '';
        }
        else
        {
            print 'Station gefunden!'."\r\n";
        }
    }   
 
    if ($collect == 1)
    {
        $collectString .= $line;
    }   
}

$z->close();

#close($fh_xml);

print "benchmark1: ".(gettimeofday() - $t0)."\n\n";

Der Code braucht weder RAM noch schreddert er die SD Karte. Erkaufen tut man es sich mit einer erhöhten Laufzeit. Auf meinem Desktop PC brauche ich etwa 10s und ein PI ist wahrscheinlich x-fach langsamer.

Um das Script mal auszuprobieren braucht man das zip File. Bei mir heisst es:
MOSMIX_S_LATEST_240.kmz  (zip file)

Habt ihr andere Files, müsst ihr das im Script entsprechend ändern.

[jensb]

@mumpitzstuff

Hatte die Frage nach IO::Uncompress::Unzip::getline weiter unten schon gestellt, aber es nicht selbst testen können. Mir wurde aus der Beschreibung nicht klar, wo entpackt wird (RAM/Disk) bzw. ob als Ganzes entpackt wird.

Wenn das so ohne relevante RAM-Belastung funktioniert, würde ich es bevorzugen.

Grüße,
Jens