Modul für DWD Open Data

[jensb]

Habe den Weblink im 1. Post ist aktualisiert.

• Die Darstellung der Icons 1 und 2 ist nun zeitabhängig. Für das 1. Icon werden als Ersatz für aktuelle Werte die zeitlich nächsten Vorhersagewerte angezeigt, das 2. Icon zeigt einen mindesten 6 Stunden späteren Wert an, der ggf. auch nach Mitternacht liegen kann.
• Temperatur mit Farben: kleiner 3 °C blau, größer 25 °C orange
• Niederschlagsmenge mit Farbe: größer 50 % blau
• Windstärke mit Hintergrundfarbe: oberhalb von Brise in 3 Orangetönen

Wenn jemand die Umschaltpunkte konfigurierbar machen möchte, dann bitten einen Patch bereit stellen. Sonstige Vorschläge, wie man die Hervorhebung markanter Werte besser gestalten könnte sind willkommen.

Grüße,
Jens

[Intruder1956]

Hallo Jens,
das bekomme ich jetzt im Log

Code Auswählen Erweitern

2018.03.18 19:30:00 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/99_Utils.pm line 21.
2018.03.18 19:30:00 3: eval: { DWDOD_AsHtmlH("DWD") }

und so wie auf dem Bild sieht es aus

Gruß Werner

[jensb]

Hallo Werner,

der Screenshot sieht meiner Meinung nach so aus wie er sollte.

Kommt die Perl-Warnung bei jedem Bildaufbau oder war das eine einmalige Sache? Was steht in deiner 99_Utils.pm in Zeile 21?

Grüße,
Jens

[Intruder1956]

ok, ich dachte da fehlt etwas siehe Montag und das gelbe, aber wenn es so gewollt ist. ok

Zeile 21 gehört zu DebianMail 

Code Auswählen Erweitern

my $attach = shift;

Zeile 6

Code Auswählen Erweitern

use DWDODweblink;

Gruß Werner

[jensb]

Hallo Werner,

wenn in deiner 99_Utils.pm in Zeile 21 "my $attach = shift;" steht, dann hat die Perl-Warnung nichts mit dem DWD-Modul zu tun, auch wenn in der nächsten Logzeile etwas über den DWD-Weblink ausgegeben wird. Vermutlich gibt es in Zeile 21 nichts zu shiften, deshalb beschwert sich Perl hier. Du müsstest prüfen, wer die Daten vor Zeile 22 übergibt und warum keine da sind.

Dein Screenshot zeigt aber etwas anderes: Die neue Farblogik erschwert die Lesbarkeit erheblich, wenn man einen dunklen Hintergrund verwendet und die Schriftfarbe weiß ist. Statt blau müssten man wahrscheinlich hellblau verwenden usw. Werde versuchen eine Konfigurationsoption zur Verfügung zu stellen, damit man umschalten kann. Ein Autodetekt der Hintergrundfarbe mit CSS dürfte schwierig sein und JavaScript möchte ich hierfür nicht verwenden. Bis dahin ggf. wieder die vorherige Version verwenden.

Grüße,
Jens

[Albatros_]

Hallo JensB,

zunächst vielen Dank für das Modul und die Zeit die du investiert hast. Ich habe das Modul heute erfolgreich in Betrieb genommen.
Ich habe aber noch eine Frage zu den Daten die ich bekomme. Und zwar würde ich unter fc0 = heute (22.03) erwarten und fc1 = morgen (23.03), fc2 = übermorgen (24.03) und so weiter.
In meinen Daten fehlt aber der 25.03.    d.h. fc2 = 24.03 und fc3 = 26.03
Anbei die genutzte Definition und die Daten die ich bekomme:

defmod Wetter_DWD DWD_OpenData
attr Wetter_DWD forecastResolution 3
attr Wetter_DWD forecastStation 10776
attr Wetter_DWD forecastWW2Text 1
attr Wetter_DWD room WebWetter

fc0_date 2018-03-22
fc1_date 2018-03-23
fc2_date 2018-03-24
fc3_date 2018-03-26
fc4_date 2018-03-27

Viele Grüße
Albatros_

[jensb]

Hallo Albatros,

gut dass dir das aufgefallen ist.

fc3_0_time ist außerdem 02:00 statt wie bisher 01:00. Das wäre insofern richtig, da am Sonntag die Sommerzeit beginnt. Allerdings dürfte deshalb nicht ein ganzer Tag fehlen. Möglicherweise tritt dieser Effekt nur rund um die Sommerzeitumstellung auf. Meiner Ansicht nach ist "nur" das Datum falsch bestimmt, die übrigen Daten sind richtig (Vergleich mit den Rohdaten).

Werde versuchen, mir das vor Sonntag anzusehen.

Grüße,
Jens

[jensb]

Leider ist nicht nur das Datum falsch. Es kommt am Tag der Sommerzeitumstellung zu einem Versatz von 1 Tag, die Daten vom Montag überschreiben die vom Sonntag usw.

Ab Sonntag wird dann wieder für ein 1 Jahr Ruhe sein. Bei der nächsten Sommerzeitumstellung im Herbst wird der Effekt nicht auftreten, da dann der Sonntag mehr statt weniger als 24 Stunden lang ist.

Werde trotzdem nach einer Lösung suchen.

Grüße,
Jens

[jensb]

Habe im 1. Post das Modul DWD_OpenData aktualisiert. Die neue Version löst das von @Albatros_ gemeldete Problem, dass die Daten vom Tag der Sommerzeitumstellung vom Folgetag überschrieben werden.

Grüße,
Jens

[Albatros_]

Hallo jensb,

das ging fix Vielen Dank für das Update.
Ich habe es eben ausprobiert und kann den Bugfix bestätigen. Es funktioniert jetzt wie erwartet.

Grüße
Albatros_

[jensb]

Habe den Weblink im 1. Post aktualisiert, um eine einfache Anpassung des Farbkontrasts für dunklen Hintergrund mit weißer Schrift zu ermöglichen. Das "normale" Blau ist dann oft schlecht erkennbar. Statt dessen sollte ein helles Blau verwendet werden. Dazu die Zeilen 52 bis 54 so ändern:

Code Auswählen Erweitern

use constant DWDOD_COLOR_FREEZE => "skyblue";    # light background -> blue, dark background -> skyblue
use constant DWDOD_COLOR_WARM   => "orange";
use constant DWDOD_COLOR_RAIN   => "skyblue";    # light background -> blue, dark background -> skyblue

Habe versucht ein Möglichkeit zu finden, den dunklen Hintergrund per CSS und ohne JavaScript automatisch zu erkennen, konnte aber nichts passendes finden. Am geeignetsten erschienen mir dafür ein CSS Attribute Selector, aber es tat sich nichts, als ich versuchsweise

Code Auswählen Erweitern

.weatherTemperature[background="black"]  {
  color: red;
}

eingefügt hatte. Falls jemand für die Automatik einen Vorschlag hat, würde ich ihn integrieren.

Wem die Farbumschaltung für Temperatur und Niederschlag nicht zusagt, kann sie auch deaktivieren. Dazu die Zeilen 50 bis 52 so ändern:

Code Auswählen Erweitern

use constant DWDOD_TEMP_FREEZE  => -100; # < blue
use constant DWDOD_TEMP_WARM    =>  100; # > orange
use constant DWDOD_PRECIP_RAIN  =>  100; # > blue

Grüße,
Jens

P.S. Im Weblink vom 24.03. ist ein Test-Logging mit Loglevel 3. Wen es stört: entweder Zeile 471 auskommentieren oder die Version von heute verwenden.

[jensb]

Hatte ja bereits angekündigt, dass ich das OpenData Modul gern um Wetterwarnungen erweitern möchte. Nach einem Studium der DWD-Dokumentation würde ich aktuell die JSON-Schnittstelle bevorzugen. Sie ist deutlich einfacher im Handling, die Daten sind unkomprimiert und kompakt. Räumlich wird nach Landkreisen unterschieden. Ein typischer Datensatz sieht so aus:

"108326000":[{"regionName":"Schwarzwald-Baar-Kreis","start":1522011600000,"end":1522044000000,"level":2,"type":5,"state":"Baden-Württemberg","description":"Es tritt leichter Frost zwischen 0 °C und -2 °C auf.","headline":"Amtliche WARNUNG vor FROST","event":"FROST","instruction":"","stateShort":"BW","altitudeStart":null,"altitudeEnd":null}]

Alternativ gibt es die CAP-Schnittstelle über den OpenData Server (in aktualisierter Form im Vergleich zu den CAP-Daten des ehemaligen DWD GDS Servers). Beispiel:

<identifier>2.49.0.1.276.0.DWD.PVW.1521976500000.253035fa-0a5c-4520-97c2-e4d8acafd08f</identifier>
<sender>CAP@dwd.de</sender>
<sent>2018-03-25T11:15:00+00:00</sent>
<status>Actual</status>
<msgType>Alert</msgType>
<source>PVW</source>
<scope>Public</scope>
<info>
<language>de-DE</language>
<category>Met</category>
<event>FROST</event>
<responseType>None</responseType>
<urgency>Immediate</urgency>
<severity>Minor</severity>
<certainty>Observed</certainty>
<eventCode>
<valueName>PROFILE_VERSION</valueName>
<value>2.1</value>
</eventCode>
<eventCode>
<valueName>LICENSE</valueName>
<value>Geobasisdaten: Copyright Bundesamt für Kartographie und Geodäsie, Frankfurt am Main, 2013</value>
</eventCode>
<eventCode>
<valueName>II</valueName>
<value>22</value>
</eventCode>
<eventCode>
<valueName>GROUP</valueName>
<value>FROST</value>
</eventCode>
<eventCode>
<valueName>AREA_COLOR</valueName>
<value>255 255 0</value>
</eventCode>
<effective>2018-03-25T11:15:00+00:00</effective>
<onset>2018-03-25T20:00:00+00:00</onset>
<expires>2018-03-26T06:00:00+00:00</expires>
<senderName>DWD / Nationales Warnzentrum Offenbach</senderName>
<headline>Amtliche WARNUNG vor FROST</headline>
<description>Es tritt oberhalb 600 m leichter Frost zwischen 0 °C und -2 °C auf.</description>
<instruction/>
<web>http://www.wettergefahren.de</web>
<contact>Deutscher Wetterdienst</contact>
<parameter>
<valueName>Lufttemperatur</valueName>
<value>0 bis -2 [°C]</value>
</parameter>
<area>
<areaDesc>Kreis Osterode am Harz</areaDesc>
<polygon>51.6506261111564,...</polygon>
<geocode>
<valueName>EXCLUDE_POLYGON</valueName>
<value>51.60142744568194, ....</value>
</geocode>
<geocode>
<valueName>WARNCELLID</valueName>
<value>103156000</value>
</geocode>
<altitude>1968.50394</altitude>
<ceiling>9842.5197</ceiling>
</area>
...

Wie man an der URL sieht, stammen die JSON-Daten nicht vom OpenData Server sondern vom DWD Server. Die wesentlichen Nachteile der JSON-Schnittstelle gegenüber der CAP-Schnittstelle sind für mich:

• kein Polygoninformationen, die die räumliche Ausdehnung des Warngebiets über Koordinaten definieren
• keine Unterstützung von Gemeinden als Alternative zu Landkreisen
• keine Unterstützung von englischen Texten

Diese Punkte sind für mich nicht relevant. Bitte nennt mir eure Gründe, die gegen eine Implementierung der JSON-Schnittstelle und für CAP sprechen.

Grüße,
Jens

[spooy99]

Hallo und danke für die Arbeit an dem Modul!

Mangels Anwendungsidee sind für mich die Polygone und die englischen Texte nicht relevant. Der Abruf der gemeindebezogenen Daten hingegen wäre für mich sehr wichtig/interessant. Wegen vielfältiger Topographie hat mein Landkreis häufiger Warnmeldungen, welche z.B. wegen der Höhenlage für mich nicht zutreffend sind. Um also unnötiger Alarmierung - und entsprechender Abstumpfung - vorzubeugen hatte ich mich sehr über die Ankündigung des DWD für lokalere Warnungen gefreut.

Danke!
spooy

[potash]

Hallo jensb,

vielen Dank für die Arbeit am Modul. Funktioniert prima bei mir!
Hinsichtlich der Warnungen würde ich die ortsbezogenen Version bevorzugen.
Ich freue mich aber auf jeden Fall, wenn wieder DWD Warnungen empfangen werden können.

Viele Grüße!

Heiko

[jensb]

Danke für die bisherigen Rückmeldungen. Dass ein lokaler(er) Ortsbezug in bestimmten Fällen hilfreich ist, leuchtet ein. Der lässt sich aber nur mit CAP umsetzen.

Hier noch etwas zum technischen Hintergrund:

Das Hauptproblem von CAP ist den ehemaligen Nutzern des GDS-Moduls möglicherweise noch bekannt. Die Dateigrößen der Zustandsdateien betragen trotz Komprimierung oft mehrere Megabyte. Das Herunterladen, Dekomprimieren und Verarbeiten solcher Datenmengen ist für die typische FHEM-Hardware echter Stress und führt dann zu spürbaren Verarbeitungspausen. Ein regelmäßiges Abfragen der Zustandsdateien kommt also nicht in Frage.

Um bei CAP mehr Performance zu erreichen, muss man auf jeden Fall die Differenzdateiverarbeitung implementieren. Meist alle 10 Minuten gibt es einen neuen Änderungsdatensatz vom DWD, der bei typischer Wetterdynamik nur alle paar Stunden überhaupt Daten enthält. Ganz ohne die Zustandsdateien geht es trotzdem nicht, denn die braucht man zumindest einmal beim Start für die Initialisierung oder wenn man ein Differenzupdate verpasst hat.

Grüße,
Jens