Modul für DWD Open Data

[Tutti_Bomovski]

Wie ist denn eine automatische Aktualisierung der Warnungen (Alerts) und der Vorhersage (Forecast) möglich?
Ich muss doch nicht manuell updaten oder?

[sinus61]

Passiert doch Automatisch, Alerts alle 15 min, Forecast einmal pro Stunde. Bei Dir nicht?

[Tutti_Bomovski]

Passiert doch Automatisch, Alerts alle 15 min, Forecast einmal pro Stunde. Bei Dir nicht?

wenn ich das richtig mitbekommen habe, dann nicht...
Ich werde das aber noch mal beobachten.

[jensb]

@Tutti_Bomovski

wenn ich das richtig mitbekommen habe, dann nicht...

Eine automatische Aktualisierung wird nur durchgeführt, wenn die Attribute alertArea und forecastStation gesetzt sind.

Grüße,
Jens

[Tutti_Bomovski]

@Tutti_BomovskiEine automatische Aktualisierung wird nur durchgeführt, wenn die Attribute alertArea und forecastStation gesetzt sind.

Grüße,
Jens

Danke für die Information! Aktualisierung erfolgt.
Wie bereits in einem anderen Beitrag https://forum.fhem.de/index.php/topic,98363.msg917058.html#msg917058 beschrieben würde ich jetzt nur noch gerne aufgrund der Warnmeldungen auch Infos per Telegram versenden.

[jensb]

Auf GitHub gibt es eine neue Version des DWD_OpenData-Moduls mit folgenden Änderungen:

• neue Vorhersage-Readings SunRise und SunSet
• SunUp wird nun auf Basis der theoretischen Sichtbarkeit der Sonnenoberkante (ca. -0.9° + Standort-Höhenanteil) und nicht mehr nach der Nautischen Dämmung (-12° Elevation) bestimmt - der Tag beginnt damit wieder etwas später

Die beiden neuen Readings waren für mich die logische Erweiterung der zuvor eingeführten Sonnenpostions-Readings. Der Aufwand war jedoch sehr viel größer als von mir zunächst angenommen. Das lag an mehreren Komponenten:

Beim Sonnenpositions-Code aus dem Twilight-Modul ist mir die "wahre" Herkunft des Algorithmus nicht klar geworden, weshalb ich diesen Codeanteil ersetzt habe. Der neue Code hat einen in Astronomiekreisen bekannten Schöpfer.

Dann bin ich davon ausgegangen, dass man aus dem Sonnenpostions-Algorithmus die Zeiten für Sonnenaufgang und Sonnenuntergang ermitteln kann, z.B. durch Differenzierung, Nullstellenbestimmung o.ä. Doch Astronomen ticken da anders - es gibt für die Berechnung dieser Zeiten sogar diverse Ansätze. Der von mir gewählte iterative Algorithmus (Stundenwinkeldifferenzminimierung) stammt von unseren seefahrenden Nachbarn und ist komplexer als der für den Sonnenstand und deshalb hat die Implementierung und Validierung etwas gedauert. Die Sonnenauf- und -untergangszeiten wichen unabhängig vom gewählten Standort bei den von mir durchgeführten Stichproben meist um weniger als 2 Minuten von denen der National Oceanic and Atmospheric Administration ab. Nicht funktionieren dürfte der Code für die Polarregionen - hierfür müssten noch die Sonderfälle "Sonne geht nie auf bzw. unter" erkannt und verarbeitet werden.

Nicht gefallen tut mir, dass im DWD_OpenData-Modul die vermutlich vierte Sonnenparameterberechung von FHEM steckt - die anderen mir bekannten stecken in SUNRISE_EL, Astro und Twilight. Nur SUNRISE_EL ist so aufgebaut, dass man es aus anderen Modulen aufrufen kann und es hat die meisten Gemeinsamkeiten mit dem von mir gewählten Ansatz, verzichtet aber auf die von mir implementierte Genauigkeitsoptimierung, den Betrachter-Zeitzonenbezug und ein paar andere Details. Astro und Twilight sind wie das DWD_OpenData-Modul keine Funktionsmodule (lassen sich also nicht ohne weiteres in anderen Modulen), wobei Astro einen anderen wissenschaftlichen Ansatz als SUNRISE_EL und DWD_OpenData verwendet und Twilight die Daten gar nicht selbst berechnet sondern von einem Webdienst übernimmt. Wer sich mit der Theorie einmal auseinander gesetzt hat, den dürfte es nicht wundern, dass keine der 4 Ansätze die gleichen Werte liefern. Welcher Algorithmus der "wahre" ist, muss jeder selbst entscheiden. Meiner Ansicht nach würde es sich anbieten, SUNRISE_EL zu erweitern und den Code aus dem DWD_OpenData-Modul wieder zu entfernen.

Wie immer sind Rückmeldungen gewünscht.

Grüße,
Jens

[sinus61]

Hab es gerade probiert, funktioniert alles. Da ich eh gerade Twilight überall ausbaue und da wo es brauche SUNRISE_EL nutze ist es zumindest interessant einen Vergleichswert zu haben. SUNRISE_EL ist ja auch praktisch weil man es überall in FHEM nutzen kann und auch leicht einen Offset mitgeben kann da man für bestimmte Anwendungen vielleicht etwas früher oder später etwas ausführen will.

Twilight war ansonsten wegen der Kombination mit den Wetterdaten interessant, aber das hat nur mit Yahoo einigermaßen funktioniert, mit externen Werten eher schlecht. Hier setze ich jetzt auf eine eigene Helligkeitsmessung.

Ansonsten weichen ja die Angaben aus SUNRISE_EL, Twilight und jetzt dem DWD Modul schon alle etwas voneinander ab, eben so wenn man sich verschiedene Webdienste zum Vergleich anschaut.

Immerhin, wenn ich einfach "heute sonnenuntergang" oder "heute sonnenaufgang" in die Googlesuche eingebe liefert Google mir für meinen Standort exakt die Angaben die auch aus dem DWD Modul kommen.

[mi.ke]

Moin,

erstmal, vielen Dank für das Modul !

Ich nutze z.Z. ausschliesslich die Unwetterwarnungen. Das funktioniert auch sehr gut.

Nach den Sturmwarnungen heute ging der a_count zeitweilen auf 3 hoch.
Das Problem ist dann aufgekommen, dass die Gewichtung, welche Meldung ist a_0_.* und welche a_1_.* etc. nach a_?_onset sortiert ist und nicht nach a_?_severity. Die rote (jüngste) Meldung wurde also als a_3_.* angezeigt.

Was schön wäre, wenn das Modul die Readings a_[0-9]_.* z.B. nach "a_1_severity" sortiert oder alternativ, die neuste und schwerwiegenste Meldung ohne Nummerierung also a_.* anzeigt.

Vielleicht gibt es auch schon eine bestehende Möglichkeit, die ich übersehen oder in der DWD Open Data-Doku nicht gefunden habe.

Oder anders gefragt, wie macht Ihr das, oder geht das z.Z. einfach nicht?

Vielen Dank und Grüße

Cheers
mi.ke

[curt]

Hallo @mi.ke

schau Dir -falls Du das nicht kennst- mal bitte das hier an:
https://forum.fhem.de/index.php?topic=97204.new;topicseen#new

[mi.ke]

schau Dir -falls Du das nicht kennst- mal bitte das hier an:
https://forum.fhem.de/index.php?topic=97204.new;topicseen#new

Das hat leider überhaupt nichts mit meiner Frage zu tun.
Ich nutze weder FTUI  noch will ich Icons darstellen.

[Nitaro]

Guten Morgen zusammen,

ich habe im wiki gelesen, dass bei Wetterwarnungen die Warnzellen beginnend mit 1,2,5,8,9 beginnend unterstützt werden.
Meine Warnzellen ID, beginnend mit 8 oder anderen, werden nicht mehr unterstützt da die Zellen aufgesplittet wurden und nun
mit 7 beginnen. Ist es möglich auch diese "funktionsfähig" zu bekommen ?

Gruß
Nitaro

[mi.ke]

ich habe im wiki gelesen, dass bei Wetterwarnungen die Warnzellen beginnend mit 1,2,5,8,9 beginnend unterstützt werden.
Meine Warnzellen ID, beginnend mit 8 oder anderen, werden nicht mehr unterstützt da die Zellen aufgesplittet wurden und nun
mit 7 beginnen. Ist es möglich auch diese "funktionsfähig" zu bekommen ?

Schon versucht Deine 7er ID in "alertArea" einzutragen?

cheers
mi.ke

[Nitaro]

Schon versucht Deine 7er ID in "alertArea" einzutragen?

Jup, bekomme ich immer

Code Auswählen Erweitern

alerts cache update in progress, please wait and try again

Gebe ich dann wieder die eines anderen Kreises an, bekomme ich direkt aktualisierte Readings.

[mi.ke]

Gebe ich dann wieder die eines anderen Kreises an, bekomme ich direkt aktualisierte Readings.

Du kannst nur Daten abrufen, die von DWD bereitgestellt werden.
Da hilft nix, Du musst Dir eine andere ID wählen, die bei Dir räumlich am nähsten ist.

[Nitaro]

Du kannst nur Daten abrufen, die von DWD bereitgestellt werden.
Da hilft nix, Du musst Dir eine andere ID wählen, die bei Dir räumlich am nähsten ist.

Ok, danke.