Modul für DWD Open Data

RomanticBoy83 · 30 März 2018, 22:27:52

Hallo, ich möchte mal eine Idee in den Raum werfen.
Ich hatte den aktuellen opendata Server (MOSMIX und CAP) in php implementiert. Für beide habe ich die Geo-Koordinaten als Ausgang genutzt. Die Stationen habe ich aus dem aktuellen Stationskatalog(PDF) geparst und die nähste gesucht. Das ist noch ziehmlich einfach und müste eigentlich nur einmalig gemacht werden.
Aber achtung:

es gibt Stationen, welche nur AktuelleDaten haben
es gibt Stationen, welche nur Vorhersagen haben,
und es gibt Stationen, welche garkeine Daten haben.

Da man in Fhem ja generell nur für einen Ort Wetter beziehen möchte, ist diese Arbeit nur einmalig zu machen und kann dann mit den spezifischen *.csv sehr schnell gehändelt werden.

Die Warnungen habe ich immer als komplettes ZIP-File genutzt. Darin sind alle Warnungen in einzelnen CAP-Files. Da sich die ZIP unregelmäßig ändert, speicherte ich mir das File-Datum vom FTP-Server. Hat sich das geändert, dann ging die Arbeit von vorne los.
Die richtigen Warnungen und Vorwarnungen habe ich dann mit Hilfe von "haversin" herausgefiltert. Erst das gesamte polygon des CAP-Files gecheckt, und dann alle auschließenden Polygone noch einmal abgezogen.
Für die Warnungen fällt mir auch nix anderes ein wenn es wirklich für jeden eine allgemeingültige Lösung sein soll.

Meine Hilfe würde ich hiermit auch gerne anbieten wenn irgendetwas benötigt wird (PS: ich bin in PERL leider nicht sehr fitt und benötige manchmal noch etwas Zeit)

jensb · 31 März 2018, 11:24:05

Hallo RomanticBoy83,

danke für dein Angebot.

Es gibt ein paar Dinge zu beachten, wenn man für FHEM entwickelt, u.a. dass nicht alle User leistungsfähige Hardware haben, dass es mehr Anwendungsvarianten gibt, als man sich als Entwickler oft vorstellt und dass man nach Mögichkeit nur Perl Core Module verwenden sollte, da es User gibt, denen das Nachinstallieren von Perl Modulen schwer fällt. Wichtig ist außerdem, dass ein einzelner Vorgang besser nur wenige Millisekunden dauert, damit der FHEM Kern nicht blockiert wird und andere Ereignisse verarbeiten kann. Auch das Mischen von Softwaretechnologien ist in Perl nicht üblich.

Aktuell läuft bei mir die Entwicklung für die Wetterwarnungen auf CAP Basis. Dabei werde ich keine eigenen Optimierungen durchführen, sondern die Protokollspezifikationen CAP 1.2 des DWD umsetzen. Download, Unzip und XML-Dekodierung sind bereits fertig. Die Geometriedaten habe ich bisher explizit nicht dekodiert, da sie einen Großteil der Datenmenge ausmachen und sehr stark auf die Performance und den Speicherbedarf drücken. Werde das aber später als Option zugängig machen. Aktuell verarbeite ich "nur" die statischen Warnmeldungen, wobei die interne Struktur bereits für die Verarbeitung der Differenzmeldungen vorbereitet ist.

ZitatDa man in Fhem ja generell nur für einen Ort Wetter beziehen möchte, ...

Geht mir auch so, aber das trifft halt nicht auf alle User zu. Würde es auch toll finden, wenn man "einfach" einen Teilbegriff oder Koordinaten eingeben könnte und eine Suchfunktion die möglichen Stationen und Warnzellen ermittelt, anzeigt und anbietet, sie in die Konfiguration zu übernehmen. Mir fehlt allerdings die Freizeit, diese Komfortfunktion umzusetzen. Selbst brauche ich das nicht mehr, denn wenn man einmal seine IDs zusammen hat, bleibt man ja dabei. Wenn du die Entwicklung dieser Funktion übernehmen möchtest, würde ich sie in das Modul integrieren.

Aktuell suche ich noch eine Definition, wie man anhand der Warnzellen-ID feststellen kann, ob es sich um eine Gemeinde- oder Landkreis-Warnzelle handelt. Das einzige was ich sicher sagen kann ist, dass eine Warnzelle, die mit 8 beginnt eine Gemeinde-Warnzelle ist. Allerdings ist mir nicht klar, ob der Umkehrschluss gilt. Habe z.B. Wanrzellen gefunden, die mit 5 beginnen und in beiden Katalogen zu finden sind. Kennt jemand hierfür eine Regel?

Grüße,
Jens

RomanticBoy83 · 31 März 2018, 12:28:51

Die Anforderungen an eine Entwicklung für die Gemeinschaft sind mir schon klar - erste Erfahrungen habe ich bereits hier im Forum in Form meiner Abfallmodule für Berlin geteilt. Ich bin also nicht ganz neu in der Entwicklung und sollte - hoffentlich - ein paar Grundzüge bereits mitbringen.

ZitatWenn du die Entwicklung dieser Funktion übernehmen möchtest, würde ich sie in das Modul integrieren

Meine Idee wäre den Stationskatalog via Knopfdruck einzulesen und sich aus diesem dann z.B. via Dropdown seine Daten zusammensuchen kann.
1) Der Stationskatalog hat über 5000Stationen (Ich habe diese zum ersten Start einmalig in eine Datenbank geschafft und hole mir dann von dort die Infos)
2) Die Stationen könnten in Fhem zusätzlich sortiert werden um unterschiedliche Dropdowns zu füllen

Stationen ohne Daten gleich verwerfen
HatAktuelleDaten, welche man auf dem FTP-Server in [weather/weather_reports/poi/] findet. Hier ist Achtung geboten, nicht alle Stationen bringen den WW(Wetterbedingung) z.B. Berlin-Alexanderplatz
HatVorhersagen, welche man auf dem FTP-Server in [weather/local_forecasts/poi/] findet.

3) Für die CAP's sehe ich wie bereits erläutert keine Möglichkeit die neuen Formate allgemeingültig für genau den Punkt zu filtern. Die neuen CAP-Files (wieweit diese für dich neu sind kann ich nicht beurteilen) sind derweil unter [test/weather/alerts/cap/] zu finden und werden voraussichtlich am 17.04. die alten ablösen. Quelle:https://www.dwd.de/DE/leistungen/opendata/neuigkeiten/opendata_feb2018_02.html

Suche die Warnungen, für welche du im Polygon liegst
Sortiere die gefundenen Warnungen aus, für welche du in einem exludePolygon liegst
optional hatte ich damals gedacht - Breche die Prüfung gleich ab, wenn du bereits mit der ersten Polygonkante extrem weit weg bist. Hatte ich nie implementiert, würde aber mit einer Rechnung zur Entfernung der ersten Kante alle anderen Rechnungen zu diesem Polygon überspringen. Man müsste dann mal einen Schwellwert bestimmen(maximale Größe eines Polygons). Dies ist aber auch nicht sehr einfach, da eine Warnung für gesamt Deutschland ebenfalls vorliegen könnte.

aus meiner Erinnerung bei den ersten Recherchen
Hallo, soweit mir bekannt - werden diese Regeln nun aufgelöst. Mit den neuen CAP-Formaten sind nur noch die Polygone ausschlaggebend. Man wollte wohl weg von den statischen Gemeinden, weil man mittlerweile kleinere Zellen beim DWD abbilden kann, welche jedoch nicht mehr einer amtlichen Gemeinde zugeordnet werden. Bei den Gemeinden/Landkreisen stützte sich der DWD auf offizielle Angaben/Bezeichnungen/Geokoordinaten vom GEO-Amt. Dieses Polygon einer Gemeinde erhält zusätzlich ausgeschlossene Polygone, für welche Bereiche der Gemeinde diese Warnung nicht gilt. Als Vergleich dazu hatte ich Garmisch-Partenkirchen gerne genommen. Dort ist ein enormer Höhenunterschied in einer Gemeinde vorhanden, welcher sehr wahrscheinlich zu unterschiedlichen Warnmeldungen führen wird.

jensb · 31 März 2018, 14:31:54

Die Änderungsaussagen des DWD sind in Bezug auf das FHEM Open Data Modul anders zu interpretieren, als das deine Hinweise vermuten lassen:

ZitatFalls Sie bereits die CAP-Versorgung über unseren OpenData-Server nutzen, betreffen Sie die Änderungen in der Struktur nicht mehr. Sie haben quasi schon die ,,halbe Miete" und müssen sich nur noch um die Gebietsänderungen kümmern.

ZitatKreis- und Gemeindereformen, sowie geänderte Kundenanforderungen machen jährlich eine Anpassung der DWD-Gebietsaufteilungen notwendig.

Berücksicht werden muss von Anwenderseite also "nur", dass sich zum 17.04.2018 einige Warnzellen-Zuordnungen ändern. Es bleibt bei der bisherigen Unterscheidung von Gemeinden und Landkreisen. Die Nutzung der Polygone ist optional. Deshalb werde ich die Polygone nicht als primären Filter nutzen, da das zusätzliche Rechenleistung benötigt.

Zu 1)
Nicht jeder User hat eine Datenbank, RAM geht auch. Zum Start ist OK. Dropdown auf die Rohdaten ist wegen der vielen Stationen unpraktikabel, deshalb vorab filtern.

Zu 2)
Da bisher keine aktuellen Daten verarbeitet werden noch ohne praktische Relevanz, sollte aber mit vorbereitet werden.

Zu 3)
Den Warnzellen-Katalog gibt es hier. Ein CSV-Parser ist bereits im Modul für die Vorhersagedaten im Einsatz. Das Vorgehen könnte ansonsten wie für 1) erfolgen.

Grüße,
Jens

jensb · 03 April 2018, 21:18:46

Das DWD Open Data Modul kann nun neben der Wettervorhersage auch Wetterwarnungen abrufen.

Den Prototyp gibt es hier. Er braucht noch etwas Feinschliff, u.a. für die gemischte Abfrage von Gemeinde- und Landkreis-Warnzellen. Zur Nutzung der neuen Funktion wird zusätzlich das Perl-Modul XML::LibXML benötigt. Details stehen in der Modulhilfe.

Ähnlichkeiten der Readings für die Wetterwarnungen mit denen des abgelösten GDS-Moduls sind kein Zufall sondern dem DWD Common Alerting Protocol (CAP) geschuldet. Die Performance der neuen Implementierung ist aber besser geworden. Download, Dekomprimieren und Dekodieren dauern nach wie vor typischerweise zwischen 2 und 15 Sekunden. Aber dadurch, dass nun das Update des Wetterwarnungs-Caches durch einen parallelen Prozess vorbereitet wird und FHEM anschließend den neuen Cache-Zustand binär innerhalb von wenigen Millisekunden lädt und die Readings erzeugt, wird FHEM nicht blockiert und bleibt frei für andere Dinge. Ob das so für alle FHEM-Systeme gilt, muss sich noch zeigen.

Auch für den Weblink wird es demnächst eine neue Version geben, die ein Warnsymbol anzeigt, wenn Wetterwarnungen vorliegen. Tipp man auf das Symbol, wird die Warnbeschreibung angezeigt.

Grüße,
Jens

Maista · 04 April 2018, 16:40:07

Hallo Jens
Danke für die Arbeit.
Bin beim Kurzurlaub.
Danach werde ich es testen.

Gruss Gerd

moskito · 04 April 2018, 16:51:24

Hi Jens,

hab die neueste Modulversion bei mir am laufen, und aktuelle Warnungen ohne Probleme reinbekommen.

Gruß
Danny

jensb · 05 April 2018, 21:45:15

In der Installationsbeschreibung des Prototyps mit Wetterwarnungen ist ein Fehler. Zur Installation von XML::LibXML ist z.B. auf einem Raspberry folgendes erforderlich:

Code Auswählen

sudo apt-get install libxml-libxml-perl

Die überarbeitete Version gibt es in den nächsten Tagen.

Grüße,
Jens

Guenni1404 · 07 April 2018, 12:50:03

Hallo,

ich wollte das Modul gerne testen.
Bekomme aber auf meinem RP3 immer die Meldung "FHEM TZ environment variable undefined, see commandref for details how to fix"
Habe mit "sudo dpkg-reconfigure tzdata" die Zeitzone nochmals gesetzt.
Bei der Eingabe von "{ $ENV{TZ} }" in FHEM bekomme ich eine leere Antwort.

Kann mir jemand sagen wie ich FHEM richtig einstelle damit ich die Zeitzone bekomme?
In der commandref habe ich nichts gefunde (oder ich war blin).

JoWiemann · 07 April 2018, 13:21:20

Zitat von: Guenni1404 am 07 April 2018, 12:50:03
Hallo,

ich wollte das Modul gerne testen.
Bekomme aber auf meinem RP3 immer die Meldung "FHEM TZ environment variable undefined, see commandref for details how to fix"
Habe mit "sudo dpkg-reconfigure tzdata" die Zeitzone nochmals gesetzt.
Bei der Eingabe von "{ $ENV{TZ} }" in FHEM bekomme ich eine leere Antwort.

Kann mir jemand sagen wie ich FHEM richtig einstelle damit ich die Zeitzone bekomme?
In der commandref habe ich nichts gefunde (oder ich war blin).

Ich habe folgendes gefunden:

https://forum.fhem.de/index.php/topic,66084.msg576949.html#msg576949

oder im Terminal:

The only annoying thing is that you have to put it into your profile and the easiest way to do this is to type the following:

Code Auswählen


echo "TZ='Europe/Berlin'; export TZ" >.profile

Grüße Jörg

Guenni1404 · 07 April 2018, 16:13:25

Zitat von: JoWiemann am 07 April 2018, 13:21:20
Code Auswählen Erweitern
echo "TZ='Europe/Berlin'; export TZ" >.profile

Habe ich gemacht.
Bei der Eingabe von

Code Auswählen


echo $TZ

erhalte ich die Ausgabe "Europe/Berlin"

In FHEM erhalte ich weiterhin die Fehlermeldung.
Irgendwie kann FHEM anscheinend die Variable nicht auslesen.

JoWiemann · 07 April 2018, 16:59:13

Der RPi muss mit sudo shutdown - r now neu gestartet werden.

Grüße Jörg

Guenni1404 · 07 April 2018, 17:31:53

Schade, nach dem Restart des RPi ist es wieder weg.
Im .profile ist der Eintrag noch da

Code Auswählen


TZ='Europe/Berlin'; export TZ

Habe jetzt zum testen im Modul die Variable manuell auf "Europe/Berlin" gesetzt. Funktioniert jetzt erst mal bis ich es auf dem RPi hinbekomme.

jensb · 07 April 2018, 19:52:54

@Guenni1404

Für das TZ-Problem ist die Lösung in der Modulhilfe beschrieben:

ZitatIf nothing is displayed or you see an unexpected timezone, fix it by adding export TZ=`cat /etc/timezone` or something similar to your FHEM start script, restart FHEM and check again.

.profile hilft nicht, da FHEM als Service vom init-Prozess gestartet wird. Also bitte das FHEM-Skript wie beschrieben erweitern. Wer ein systemd-Linux verwendet findet die Lösung in diesem Beitrag.

Grüße,
Jens

jensb · 07 April 2018, 20:08:26

Im 1. Post sind das Modul und der Weblink aktualisiert, beide unterstützen nun Wetterwarnungen.

Wer den Wetterwarnung-Prototyp verwendet, sollte beachten, dass aus "get updateAlerts" nun "get updateAlertsCache {districts|communeUnions|All}" geworden ist. Man kann jetzt nämlich bei Bedarf beides cachen und dann in beliebiger Reihenfolge mit "get alerts <warncell id>" Gemeinde- und Landkreis-Warnzellen abfragen.

Grüße,
Jens