Modul für DWD Open Data

Begonnen von jensb, 21 Januar 2018, 14:38:48

Vorheriges Thema - Nächstes Thema

somansch

Zitat von: jensb am 17 Dezember 2018, 22:33:16
Hallo Andreas,

deinen Vorschlag mit dem Filter für bestimmte Warnungen finde ich gut. Dazu den CAP Event Code zu verwenden ist auch eindeutig (siehe Abschnitt 3.1.1), wobei der genaue Event-Text auch von den Eigenschaften Urgency und Certainty abhängt, sich aber immer auf das gleiche Wetter- bzw. Gesundheitsphänomen bezieht.

Ein Anwender müsste sich entweder gegen bestimmte bereits empfangene Warnungen entscheiden oder sich dieses Dokument ansehen, um die richtigen Event-Codes zur Verfügung zu haben.

Es ist ja bald Weihnachten. Wenn ich die Zeit finde, werde ich es einbauen.

Grüße,
Jens

Hallo Jens,

wollte mal nachfragen, ob du über Weihnachten daran gebastelt hast  ;D.

Danke und Gruß
Andreas

somansch

Hallo Jens,

ich habe noch eine zweite (wichtigere) Baustelle. Wie du ja weißt, gibt es viel Interesse in der FTUI Gemeinde, die DWD Daten zu nutzen. Aus diesem Grund habe ich das dortige "Weather_Widget" überarbeitet: https://forum.fhem.de/index.php/topic,96954.0.html

Dieses Widget übersetzt den Wettercode in ein Wettersymbol (im Moment gibt es vier Symbolsätze zur Auswahl). Neben DWD wird auch Proplanta, DarkSky und OpenWeather unterstützt. Letztere Wettermodule liefern einen Wettercode in Abhängigkeit von Tag/Nacht. Leider gibt es diese Unterscheidung nicht beim DWD. Ich habe jedoch gesehen, dass du auch eine Unterscheidung im Weblink hast.

Könntest du bitte ein zusätzliches Reading für den Wettercode erzeugen?

Optimal wäre neben dem existierende "fcx_x_ww" ein zusätzliches Reading "fcx_x_ww_daytime". D.h. als Beispiel "fcx_x_ww" hat den Wert 63, "fcx_x_ww_daytime" bekommt entweder 63d (für Tag) oder 63n (für Nacht). Die Unterscheidung wird an Hand von "fcx_x_time" getroffen. Der Sonnenauf- und -untergang muss nicht noch extra berücksichtigt werden  ;).

Für Rückfragen, gern per PN.

Vielen Dank vorab
Andreas

jensb

Es geht zwar momentan mehr um die FTUI-Umsetzung, aber wer den Weblink mit FHEMWEB nutzt, sollte das Update auf GitHub ausprobieren. Folgendes ist neu:


  • kein Text mehr für die Bewölkungs-Wettercodes 0 ... 3 (da eher verwirrend als hilfreich)
  • Untersützung für forcecastResolution=1
  • Bugfix für max. Windgeschwindigkeit von "heute"

Auch für das DWD_OpenData-Modul selbst gibt es auf GitHub schon seit letztem Jahr eine neue Version. Da habe ich wohl nicht deutlich genug darauf hingewiesen. Wenn ich ein paar Rückmeldungen bekäme, würde ich es über FHEM zur Verfügung stellen. Hier ist folgendes geändert:


  • vorhandene Vorhersage-Readings werden gelöscht, wenn man bestimmte Attribute ändert, z.B. forecastStation und forecastResolution
  • Unterstützung von forecastResolution=1
  • neues Attribut "alertExcludeEvents" um Wetterwarnungen wegzufiltern

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

jensb

Hallo Andreas,

Zitat von: somansch am 09 Februar 2019, 20:02:15
Die Unterscheidung wird an Hand von "fcx_x_time" getroffen. Der Sonnenauf- und -untergang muss nicht noch extra berücksichtigt werden  ;).

Mit welcher Logik soll das DWD_OpenData-Modul denn dann day bzw. night bilden? Der DWD_OpenData_Weblink verwendet SUNRISE_EL und ist damit nur für den Ort geeignet, der in FHEM global eingestellt ist. Der muss aber nicht unbedingt mit dem Ort übereinstimmen, für den das DWD_OpenData-Modul die Vorhersage holt. Das DWD_OpenData-Modul kann außerdem mehr als nur eine Station abfragen, auch wenn das vielleicht nicht jeder nutzt. Aus dem Stationscode kann man aber die Geokoordinaten nicht ermitteln und ohne Geokoordinaten und ggf. einer Offset-Korrektur des Horizonts pro Station kann man Tag und Nacht nicht aus der Uhrzeit bestimmen.

Es macht für mich momentan mehr Sinn, für den einfachen Fall "FHEM-Geokoordinaten = DWD_OpenData-Station" eines der vorhandenen Astro-Module zu nehmen und das gewünschte Reading per Notify zu bilden. Selbst wenn man die Geokoordinaten als Attribut oder Reading im DWD_OpenData-Modul hätte, wäre ein modulare Lösung nicht möglich, da sich meines Wissens nach weder SUNRISE_EL, Astro oder Twilight für variable Geokoordinaten nutzen lassen. Man müsste also eines dieser Module erweitern oder eine eigene Astro-Implementierung im DWD_OpenData-Modul unterbringen.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

curt

Zitat von: sinus61 am 09 Februar 2019, 15:02:30
Mir geht es im Moment darum erstmal nur unabhängig von der Wetterkarte ein größeres Warnicon zu bekommen, das dann halt die aktuell noch anstehende Warnung anzeigt

Ich habe das schon verstanden - und schaue ganz neugierig.

Zitat von: jensb am 09 Februar 2019, 20:13:15
Es geht zwar momentan mehr um die FTUI-Umsetzung, aber wer den Weblink mit FHEMWEB nutzt, sollte das Update auf GitHub ausprobieren.

Sagst Du bitte noch die URL?
RPI 4 - Jeelink HomeMatic Z-Wave

somansch


somansch

Zitat von: jensb am 09 Februar 2019, 20:49:59
Hallo Andreas,

Mit welcher Logik soll das DWD_OpenData-Modul denn dann day bzw. night bilden? Der DWD_OpenData_Weblink verwendet SUNRISE_EL und ist damit nur für den Ort geeignet, der in FHEM global eingestellt ist. Der muss aber nicht unbedingt mit dem Ort übereinstimmen, für den das DWD_OpenData-Modul die Vorhersage holt. Das DWD_OpenData-Modul kann außerdem mehr als nur eine Station abfragen, auch wenn das vielleicht nicht jeder nutzt. Aus dem Stationscode kann man aber die Geokoordinaten nicht ermitteln und ohne Geokoordinaten und ggf. einer Offset-Korrektur des Horizonts pro Station kann man Tag und Nacht nicht aus der Uhrzeit bestimmen.

Es macht für mich momentan mehr Sinn, für den einfachen Fall "FHEM-Geokoordinaten = DWD_OpenData-Station" eines der vorhandenen Astro-Module zu nehmen und das gewünschte Reading per Notify zu bilden. Selbst wenn man die Geokoordinaten als Attribut oder Reading im DWD_OpenData-Modul hätte, wäre ein modulare Lösung nicht möglich, da sich meines Wissens nach weder SUNRISE_EL, Astro oder Twilight für variable Geokoordinaten nutzen lassen. Man müsste also eines dieser Module erweitern oder eine eigene Astro-Implementierung im DWD_OpenData-Modul unterbringen.

Grüße,
Jens

Hallo Jens,

die Logik für Tag/Nacht Unterscheidung per fcx_x_time zu bauen ist absolut ausreichend! Wenn ich es richtig sehe, gibt es im Moment folgende Uhrzeiten bzw. Werte:
01:00 -> n
04:00 -> n
07:00 -> d
10:00 -> d
13:00 -> d
16:00 -> d
19:00 -> n
22:00 -> n

Diese Zuordnung wäre prima  :)

PS: Werde in der Zwischenzeit die Excludes für Alerts testen.

Viele Grüße
Andreas

Knallkopp_02

Ich sehe das wie somansch. Man sollte den Tag halbieren, so wie angegeben.

Ich hätte nur eine Anmerkung/Frage dazu, wenn die Auflösung höher ist als 3 Stunden, man also mehr als 8 Werte pro Tag bekommt, dann müsste die zeitliche Unterscheidung auch höher auflösen, oder sehe ich das falsch?

Daher mein Gedanke Zeitbereich zu definieren, 0-7 Uhr = Nacht (n), 8-19 Uhr Tag (d), 20-23 Uhr Nacht.

Gruß
Ich bin kein Programmierer und habe keine Ahnung.

Raspberry PI 3B+ mit HM-MOD-RPI-PCB,     
HM-TC-IT-WM-W-EU, HM-CC-RT-DN, HM-SEC-SCo
Raspberry PI 3B+ mit 7" Touchdisplay

sinus61

Zitat von: jensb am 09 Februar 2019, 20:49:59
und das gewünschte Reading per Notify zu bilden. Selbst wenn man die Geokoordinaten als Attribut oder Reading im DWD_OpenData-Modul hätte, wäre ein modulare Lösung nicht möglich, da sich meines Wissens nach weder SUNRISE_EL, Astro oder Twilight für variable Geokoordinaten nutzen lassen. Man müsste also eines dieser Module erweitern oder eine eigene Astro-Implementierung im DWD_OpenData-Modul unterbringen.

Keine Ahnung wie das Aufwand-Nutzen Verhältnis wäre, aber könnte man nicht den Namen eines Twilight Device als Attribut eintragen und das DWD_OpenData-Modul holt sich dann dort die Werte?

Geht aber sicher auch irgendwie mit einem Notify.

sinus61

Um nochmal auf diese Frage zurückzukommen, kann es sein, dass hier immer ein Event kommt weil alle Readings gelöscht werden? Und könnte man nicht die a_ Readings die es immer gibt davon ausnehmen? Es macht es jetzt umständlich nur ein Notify anzusprechen wenn eine neue Warnung reinkommt.

Zitat von: sinus61 am 03 Februar 2019, 16:42:39
Noch eine andere Frage, ich habe folgende Attribute gesetzt:


attr DWD_Wetter event-on-change-reading a_count
attr DWD_Wetter event-on-update-reading state,fc_state,a_state


Im Moment habe ich einen alert, trotzdem wird alle 15 Minuten ein event für a_count ausgelöst, obwohl a_count auf 1 bleibt. Sollte das nicht nur passieren wenn sich a_count ändert?

jensb

@sinus61
Wie du bereits fest gestellt hast, werden momentan bei jedem Update alle a_* Readings gelöscht und dann neu aufgebaut. Ich werde das in der nächsten Version so ändern, wie du es vorgeschlagen hast, so dass a_state, a_count und a_time nicht mehr gelöscht werden.

Ein selektives Löschen der indizierten Wetterwarnung-Readings ist leider nicht möglich, da die Wetterwarnungen bei jedem DWD-Update eine andere Reihenfolge haben können. Der DWD löst dieses Problem, indem jede Wetterwarnung eine einmalige ID hat. Das lässt sich aber nicht gut auf feste Namen wie die der FHEM-Readings abbilden. Wenn man statt des jetzigen Index die DWD-ID in den Reading-Namen steckt, kann man nicht mehr mit einer Schleife über a_count die einzelnen Readings finden.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

jensb

Zitat von: somansch am 09 Februar 2019, 23:28:57
die Logik für Tag/Nacht Unterscheidung per fcx_x_time zu bauen ist absolut ausreichend!

Das reicht mir aber nicht. Wir wollen aus dieser Info eine visuelle Darstellung generieren, die uns einen Eindruck vermitteln, was draußen los ist, ohne dass wir selbst draußen nachsehen müssen. Bei Tag/Nacht nutzt auch jede Wetter-App auf einem Smartphone die Geokoordinaten und die Astro-Regeln, um die Umschaltung durchzuführen. Man muss hier nicht schlechter werden als nötig.

Bei Interesse würde ich mir den Code der anderen Astro-Module ansehen. Wenn ich die passenden Infos finde, werde ich eine Erweiterung des DWD-Moduls um die Astro-Readings Sonnen-Azimut und Sonnen-Elevation für jeden Vorhersage-Eintrag zusätzlich anlegen, wenn man das Attribut forecastStationCoordinates setzt. So könnte man sich in Abhängigkeit vom Elevation-Reading und dem jetzigen ww-Reading ein neues ww_dn-Reading bei Bedarf selbst bilden und dabei sogar die gewünschte Horizontlage selbst bestimmen. Ein Beispiel für das dazu nötige notify in der Wiki dürfte das für jeden handhabbar machen.

Ein Reading aus WW-Code und einem Buchstaben im DWD_OpenData-Modul zu erzeugen halte ich aber nach wie vor nicht für richtig. Es ist Aufgabe einer Middleware wie dem DWD_OpenData_Weblink-Generator die Rohdaten so aufzubereiten, wie sie für die Anzeige benötigt werden, statt in einem Daten-Modul zusammengesetzte Datenvarianten für die direkte Darstellung in einem speziellen Frontend zu integrieren - auch wenn das praktisch ist, weil es die Middleware überflüssig macht.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

jensb

@sinus61
Die neue Version des DWD_OpenData-Moduls mit selektivem Löschen der Wetterwarnungs-Readings ist nun zum Testen auf GitHub verfügbar.

Es ist übrigens keine gute Idee eine Auswertung nur auf Änderung von a_count zu machen. Für den Fall, dass eine "harmlose" Wetterwarnung mit dem nächsten DWD-Update durch eine Katastrophen-Warnung abgelöst wird, bleibt a_count bei 1, aber du würdest die Katastropen-Warnung trotzdem nicht anzeigen, sondern nach wie vor die harmlosen Wetterwarnung.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

curt

Zitat von: jensb am 10 Februar 2019, 20:28:25
Das reicht mir aber nicht. Wir wollen aus dieser Info eine visuelle Darstellung generieren, die uns einen Eindruck vermitteln, was draußen los ist, ohne dass wir selbst draußen nachsehen müssen. Bei Tag/Nacht nutzt auch jede Wetter-App auf einem Smartphone

Als jemand, der hier eher Nutznießer des Ganzen ist, würde ich ganz locker sagen: Mein Tag hat vier Teile: Vor dem Aufstehen ist "noch Nacht", dann ist Vormittag. Ab vielleicht 1300 ist Nachmittag. Nach dem Abendbrot ist dann "wieder Nacht" - macht vier Tagesteile.

Zitat von: jensb am 10 Februar 2019, 21:09:05
Es ist übrigens keine gute Idee eine Auswertung nur auf Änderung von a_count zu machen. Für den Fall, dass eine "harmlose" Wetterwarnung mit dem nächsten DWD-Update durch eine Katastrophen-Warnung abgelöst wird, bleibt a_count bei 1, aber

Orrrr nöh.


<div data-type="link"
      data-parent="index"
      data-url="#Garten_DWD_warn.html"
      data-load="#Garten_DWD_warn"
      data-color="white"
      >
  <div>Warnung</div>
  <div data-type="image"
       data-device="DWD"
       data-url="../images/eigene/gefahrenstelle.png"
       data-hide="a_count"
       data-hide-on="0"
       data-width="60px"
       class="nocache top-space">
  </div>
</div>


funktioniert doch so prima. Was würdest Du alternativ vorschlagen? (Der Vorschlag von @sinus61 funktioniert bei mir nicht. Ich habe mir das aber noch nicht genauer angesehen.)
RPI 4 - Jeelink HomeMatic Z-Wave

somansch

Zitat von: jensb am 10 Februar 2019, 20:28:25
Das reicht mir aber nicht. Wir wollen aus dieser Info eine visuelle Darstellung generieren, die uns einen Eindruck vermitteln, was draußen los ist, ohne dass wir selbst draußen nachsehen müssen. Bei Tag/Nacht nutzt auch jede Wetter-App auf einem Smartphone die Geokoordinaten und die Astro-Regeln, um die Umschaltung durchzuführen. Man muss hier nicht schlechter werden als nötig.

Bei Interesse würde ich mir den Code der anderen Astro-Module ansehen. Wenn ich die passenden Infos finde, werde ich eine Erweiterung des DWD-Moduls um die Astro-Readings Sonnen-Azimut und Sonnen-Elevation für jeden Vorhersage-Eintrag zusätzlich anlegen, wenn man das Attribut forecastStationCoordinates setzt. So könnte man sich in Abhängigkeit vom Elevation-Reading und dem jetzigen ww-Reading ein neues ww_dn-Reading bei Bedarf selbst bilden und dabei sogar die gewünschte Horizontlage selbst bestimmen. Ein Beispiel für das dazu nötige notify in der Wiki dürfte das für jeden handhabbar machen.

Ein Reading aus WW-Code und einem Buchstaben im DWD_OpenData-Modul zu erzeugen halte ich aber nach wie vor nicht für richtig. Es ist Aufgabe einer Middleware wie dem DWD_OpenData_Weblink-Generator die Rohdaten so aufzubereiten, wie sie für die Anzeige benötigt werden, statt in einem Daten-Modul zusammengesetzte Datenvarianten für die direkte Darstellung in einem speziellen Frontend zu integrieren - auch wenn das praktisch ist, weil es die Middleware überflüssig macht.

Grüße,
Jens
D.h. unterm Strich wird es in deinem Modul niemals die fertigen Readings als Unterscheidung für Tag/Nacht geben, richtig?

Das ist sehr schade, da die anderen Module dies liefern. Die Daten werden jedoch dort direkt von ProPlanta, DarkSky und OpenWeather geliefert.

PS: Wie wird denn das Problem im "DWD_OpenData_Weblink-Generator" gelöst?