Modul für DWD Open Data

[Dirk070]

Danke Dir und ja, der Präfix fc1_ ist klar.

Um 23:59 Uhr weise ich die Variablen wie folgt zu:

Code Auswählen Erweitern

my $RegenHeute=ReadingsVal("DWD", "fc1_RRdc", "");;
my $RegenRisikoHeute=ReadingsVal("DWD", "fc1_Rd00", "");;
fhem("setreading DWD RainToday $RegenHeute");;
fhem("setreading DWD RainRiskToday $RegenRisikoHeute");;
Ich verstehe, dass nur der DWD die Datenherkunft, -qualität etc. benennen kann.
Ich hatte hier angefragt um sicherzustellen, dass die Logik in Ordnung ist.
Aktuell liegen die Werte aus der WarnApp und OpenData nur noch minimal auseinander.

[jensb]

Ich hatte hier angefragt um sicherzustellen, dass die Logik in Ordnung ist.

Wenn du ein paar Minuten investierst, kannst du dich selbst davon überzeugen. Lies die Modulhilfe in Ruhe durch. Da findest du auch den Link mit der URL, über die sich das Modul die Daten besorgt. Der Verzeichnisname ist deine Stationskennung. Das Dateiformat ist eine gezippte XML. Einfach *.kmz in *.zip umbenennen, auspacken und anschauen.

Viel Spaß!

[Fredi69]

Kann mir jemand auf die Sprünge helfen warum ich seit heute folgende Meldung im Log habe?

Code Auswählen Erweitern

ERROR - device "DWD" -> attribute "forecastProperties" must contain: TTT,Neff,R101,ww,SunUp,SunRise,SunSet, ERROR - device "DWD" -> attribute "forecastResolution" must be set to "1"

[DS_Starter]

@Fredi69,
die Meldung kommt durch eine Prüfung in meinem SolarForecast-Modul. Der (noch aktuelle) Thread dazu: https://forum.fhem.de/index.php?topic=117864.0
 

[DS_Starter]

Hallo jensb,

ich benutze die Daten aus deinem DWD Modul als Input für verschiedene Werte im SolarForecast Modul.

Wenn ich es richtig sehe, verwendest du die MOSMIX_L Stationen als Wertelieferanten. Laut DWD werden die MOSMIX_L  allerdings nur 4 x täglich aktualisiert (Quelle Abschnitt 2.1.5). Schnelle Wetteränderungen kommen so aller Voraussicht nach nicht zur Geltung.

Siehst du eine Möglichkeit alternativ die gewählte Station aus MOSMIX_S zu verwenden, sofern sie dort vorhanden ist?  MOSMIX_S wird 1 x pro Stunde aktualisiert (https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml/).

Im File MOSMIX_S_LATEST_240.kmz steckt halt alles drin und es ist dementspechend groß. Da du aber ohnehin BlockingCall verwendest, könnte es vllt. machbar sein. Wie denkst du darüber?
Wäre eine super Sache dadurch sehr aktuelle Werte zu bekommen.

Danke und LG,
Heiko

[jensb]

Hallo Heiko,

kann mich nicht entsinnen, dass es MOSMIX_S schon gab, als das Modul entstanden ist. Habe mich entsprechend noch nicht mit dem Inhalt beschäftigt. Wenn der Aufbau der Daten von MOSMIX_S dem von MOSMIX_L entspricht und sich "nur" die Aktualisierungshäufigkeit unterscheidet, dann sollte die Anpassung eher einfach sein. Du kannst es gern schon ausprobieren, einfach im Modul den URL-Prefix auf MOSMIX_S ändern.

Ist der Datenaufbau oder der Datenumfang doch anders, muss man ein bisschen Zeit investieren. Werde mir das ansehen, wird aber ein paar Tage dauern.

Grüße,
Jens

[DS_Starter]

Vielen Dank Jens! 

LG,
Heiko

[DS_Starter]

Habe es mal stumpf ausprobiert. Download klappt, aber da das File alle Stationen enthält (ist auch sehr groß) ist die Struktur nicht identisch. Jedenfalls wird mein Standort als TROMSOE geparst. 
Aber ich bin optimistisch, dass du ein angepasstes Parsing einbauen kannst.

Die Download Url wäre:

# get forecast for station from DWD server
  my $url = 'https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml/MOSMIX_S_LATEST_240.kmz';;

[jensb]

Hallo Heiko,

der DWD beschreibt MOSMIX hier: https://www.dwd.de/DE/leistungen/met_verfahren_mosmix/met_verfahren_mosmix.html

MOSMIX S (24x täglich) hat also nur 40 Parameter, während MOSMIX L (4x täglich) 115 Parameter hat.

Und, wie du schon festgestellt hast, enthält MOSMIX S alle Stationen in einer Datei, die ca. 40 MB groß ist. Dekomprimiert ergibt das dann ca. 700 MB. Wenn man das stündlich abarbeitet und die 40 + 700 MB vorübergehend auf der SD eines Pi landen, dann geht das deutlich mehr auf die Lebensdauer der SD als bei MOSMIX L. Wenn /tmp als RAM-Disk konfiguriert ist, kommt es darauf an, wie viel RAM da ist. Wenn es schon knapp ist, dann bleibt der Pi wahrscheinlich stecken. Es wird auch sehr viel mehr CPU-Leistungen benötigt, denn die 700 MB müssen durchgelesen werden, bis alle Daten für die gewünschte Station gefunden sind. Im Endeffekt wäre es aber eine Entscheidung des Anwenders, ob er sich für S oder L entscheidet.

Für die Erweiterung des DWD OpenData Moduls auf MOSMIX S fallen folgende Arbeiten an:

• neues Attribut für Umschaltung S/L
• neues Attribut für Aktualisierungsintervall S
• neue interne Metadaten pro DWD-Parameter, ob in S verfügbar
• Abfrage-URL und Auswertung abhängig vom neuen Attribut
• Auswertung erweitern
• Stationsfilter
• Testen
• Modulhilfe anpassen
• Wiki anpassen
• FHEM Repository Update

In einer erweiterten Version könnte ich mir auch vorstellen, sowohl S und L zu lesen und zu mischen, damit man immer alle Parameter hat.

Bleibt die Frage, wer sich an die Arbeit macht - schätze es werden ca. 16..20 h für die "einfache" Version (S oder L).

Wie viele User haben Interesse an dieser Erweiterung ("Gefällt mir" verwenden) und würde jemand einen Patch erstellen können?

Grüße,
Jens

[DS_Starter]

Hallo Jens,

danke für deine Einschätzung/Bewertung.
Dass MOSMIX S im Gegensatz zu MOSMIX L weniger Paramter hat, war mir auch schon aufgefallen. Speziell bzgl. des genannten Einsatzfalles (SolarForecast) passt das.
Natürlich ist dieser Umstand in einem Modul welches beide MOSMIX Varianten abbilden soll, eher aufwandstreibend.

Sollten sich nicht genügend Nutzer melden um dich zu motivieren    kann ich mir auch vorstellen, eine explizite Implementierung von MOSMIX L im SolarForecast Modul zu realisieren. Weil nur bestimmte Parameter gebraucht werden, reduziert sich die Komplexität und Kompatibilitätsnotwendigkeit.
Allerdings muss ich mich selbst erst in das Vorgehen mit der XML Library und dem Parsing einarbeiten. Deswegen hatte ich bzgl. der Implementierung/dem Patch auf dein Engagement gesetzt.
 
Sollte eine Implentierung in deinem Modul wegen des zu erwartenden Aufwands nicht für dich in Frage kommen, würde ich mich freuen wenn du mich bei einer weniger komplexen Implementierung in SolarForecast mit deinem Konow-How unterstützen würdest.

Grüße,
Heiko


 

[jensb]

Hallo Heiko,

aufgrund der großen Rohdatenmenge funktionieren "einfache" Implementierungen nicht. Das DWD OpenData Modul ist vor allem aus Performancegründen etwas komplexer aufgebaut. Macht man es anders/einfacher, dann werden von FHEM für mehrere Sekunden (oder vielleicht sogar Minuten) nichts mehr verarbeitet, bis der DWD-Ablauf fertig ist.

Eine Erweiterung des DWD-Moduls dürfte daher die sinnvollste und einfachste Lösung sein.

Grüße,
Jens

[DS_Starter]

Hallo Jens und Interessenten,

ich habe eine Version erstellt und hier angehängt.
Funktioniert bei mir bezüglich forecast schonmal einwandfrei. Es gibt das Attr forecastProcess zum Umstellen zwischen MOSMIX_L und MOSMIX_S.
Mit verbose 5 sieht man:

Code Auswählen Erweitern

...
2024.02.17 16:06:03.277 5: DWD.Solar: GetForecastStart START (PID 4988): https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml/MOSMIX_S_LATEST_240.kmz
2024.02.17 16:06:09.424 5: DWD.Solar: ProcessForecast START
2024.02.17 16:06:09.425 5: DWD.Solar: ProcessForecast: data received, decoding ...
2024.02.17 16:06:11.393 5: DWD.Solar: ProcessForecast: parsing XML document
2024.02.17 16:06:13.741 5: DWD.Solar: ProcessForecast: extracting data
2024.02.17 16:06:14.247 5: DWD.Solar: ProcessForecast: use position >xxxx< of station >xxxx<
....

@Jens, es gibt eine neue Funktion getStationPos zur Positionsbestimmung im XML. Die kann man dann noch bei ProcessAlerts einbauen.
Wenn es dir gefällt, würde ich als nächstes die internen Metadaten für S zusammentragen.

Edit2: habe noch die %forecastDefaultPropertiesL und %forecastDefaultPropertiesS eingefügt.

LG,
Heiko

[jensb]

Hallo Heiko,

ziemlich cool was du da in der kurzen Zeit auf die Beine gestellt hast. Mir fehlt dazu aktuell ein bisschen die Luft, da ich schon an mehreren anderen Projekten dran bin und die Wochenenden so schnell vorbei sind

Habe mir den Diff angeschaut und da gibt es nicht viel was ich ändern würde:

• englische Kommentare
• keine #-Zeilen
• vorhandenen Klammer- und Einrückungsstil beibehalten
• forecastDefaultProperties -> forecastDefaultPropertiesL
• forecastDefPropMOSMIX_S-> forecastDefaultPropertiesS

Der Ablauf dauert bei dir nur ca. 11 Sekunden. Das ist relativ wenig, aber ein NUC6i5SYH hat halt etwas mehr Power als ein Pi.

... würde ich als nächstes die internen Metadaten für S zusammentragen.

Gibt es bei S Properties, die es bei L nicht gibt oder gilt das nur umgekehrt?

Habe noch mal über die Konfiguration nachgedacht. Den Anwender interessiert relativ wenig ob es sich um MOSMIX S oder L handelt und wie die Daten unter der Haube beschafft werden. Daher macht es meiner Ansicht nach mehr Sinn, dass indirekt zu verpacken, z.B. als "forecastDataRefresh=1 h/6 h". Mit dem Wert kann man dann in einem 2. Schritt besser spielen und z.B. auch 2 h ermöglichen, indem man die Daten nicht immer herunterlädt.

Das von mir angesprochene Merging von S und L könnte man aus der Kombination "forecastDataRefresh < 6 h" und "Parameter nur in L" anstoßen, indem man erst L und dann S abfragt.

Grüße,
Jens

[DS_Starter]

Hallo Jens,

ja jeder hat so seinen Stil. Ich liebe es nicht alles so gedrängt und mit etwas Abstand lesen zu können ... bin schon nicht mehr so taufrisch. 

Gibt es bei S Properties, die es bei L nicht gibt oder gilt das nur umgekehrt?

Alles was es bei MOSMIX_L gibt, ist auch bei MOSMIX_S vorhanden. Umgekehrt natürlich nicht da es nur 40 sind.
Im Prinzip sehe ich da kein ToDo außer die Defaults die ich schon gesetzt habe.

Habe noch mal über die Konfiguration nachgedacht. Den Anwender interessiert relativ wenig ob es sich um MOSMIX S oder L handelt und wie die Daten unter der Haube beschafft werden. Daher macht es meiner Ansicht nach mehr Sinn, dass indirekt zu verpacken, z.B. als "forecastDataRefresh=1 h/6 h".

Im Prinzip stimme ich dir zu. Allerdings liest sich forecastDataRefresh so "harmlos". Ich meine damit, dass man in der ComRef bei der Auswahl von MOSMIX_X explizit und eindringlich darauf hinweisen kann, dass man genügend leistungsfähige Ressourcen benötigt, angefangen bei genug RAM usw.
Deswegen finde ich die explizite Auswahl nicht so verkehrt, aber ist dein Modul.

Um diesen Mix aus S und L zu tun, könnte forecastProcess noch ein "both" zur Auswahl stellen.
Wir können ja nochmal darüber schlafen.

Die Refreshsteuerung ist noch offen. Ich habe 3 DWD Devices in Betrieb. Wenn ich alles auf S stelle, reicht auch bei mir der RAM nicht. Das muss man zwischen den Devices etwas auseinanderziehen.

Edit: Habe die Studie oben gleich bzgl. forecastDefaultPropertiesL und forecastDefaultPropertiesS abgeändert

Grüße,
Heiko

[jensb]

Hallo Heiko,

Ich habe 3 DWD Devices in Betrieb. Wenn ich alles auf S stelle, reicht auch bei mir der RAM nicht. Das muss man zwischen den Devices etwas auseinanderziehen.

Hatte noch die Idee, das DWD OpenData-Modul so anzupassen, dass die Readings zusätzlich/alternativ in ein beliebiges Target-Device geschrieben werden können (noch ein Attribut mehr, z.B. Prefix). Das käme dem S-Modus zu Gute, denn dann könnte man mit einem DWD-Modul mehrere Stationen abfrühstücken, ohne noch mehr Ressourcen zu benötigen.

Grüße,
Jens