Modul für DWD Open Data

[stefanru]

Kurze Rückmeldung,
habe die letzte Version von mumpitzstuff nun seit ein paar Tagen in kombination mit SolarForecast laufen.
Funktioniert super!

Speicherverbrauch und Laufzeit auf Raspberry auch top.

Danke!

[SparcWolf]

Hallo,
bei mir läuft die Version von @mumpitzstuff auch gut. Vielen Dank an mumpitzstuff.

Frage an @jensb und @DS_Starter: Gibt es Pläne die Version in ein Release zu überführen?

Grüße,
  Guido.

[DS_Starter]

Frage an @jensb und @DS_Starter: Gibt es Pläne die Version in ein Release zu überführen?

Ich bin auf jeden Fall dafür!
Letztlich liegte diese Entscheidung bei Jensb als Maintainer des Moduls.
Leider hat sich Jens lange nicht zu Wort gemeldet, hoffe es geht ihm gut.

PS: Die letzte V von mumpitzstuff will ich bei mir auch mal noch testen, gehe aber davon aus dass alles ok ist wenn ich die ganzen Rückmeldungen lese.

LG,
Heiko

[mumpitzstuff]

Eine Idee spukt mir noch im Hirn rum. MOSMIX L kann man doch relativ schnell abrufen und hier gibt es doch eigentlich alle Daten, nur eben nicht ganz so genau wie MOSMIX S. Würde es vielleicht Sinn machen bei der aktuellen MOSMIX S Variante noch einzubauen, das dort vorher auch noch MOSMIX L abgeholt wird und dann nur die ungenaueren Daten von MOSMIX L durch die MOSMIX S Daten ersetzt werden. Dann hätte man einen Mix aus beidem. Wie denkt ihr darüber? Der Vorteil den ich sehe wäre, das man wirklich alle möglichen Daten zur Verfügung hätte und wenn man etwas verwendet das in MOSMIX S vorhanden ist, dann nutzt man hier die besseren Daten und wenn das nicht der Fall ist, dann würde man auf MOSMIX L zurück fallen. Man würde das Beste aus beiden Welten kombinieren.

[DS_Starter]

Würde es vielleicht Sinn machen bei der aktuellen MOSMIX S Variante noch einzubauen, das dort vorher auch noch MOSMIX L abgeholt wird und dann nur die ungenaueren Daten von MOSMIX L durch die MOSMIX S Daten ersetzt werden.

Dann weiß man aber nicht mehr wie aktuell die jeweiligen Daten sind. Zudem wäre das Reading fc_time, welches den definitiven Updatezustand bzw. das Alter der Daten mitteilt, nicht mehr aussagefähig.
Ich bin da ehrlich gesagt nicht so überzeugt davon.

[mumpitzstuff]

Wie meinst du das mit ,,wie aktuell die Daten sind"? Bezieht sich die Aussage auf das Reading? Okay bis ins letzte Detail habe ich das nicht durchleuchtet aber grundsätzlich könnte man das Reading für MOSMIX L und MOSMIX S separat anlegen und pflegen. Z.B. fc_time_L und fc_time_S.

[DS_Starter]

Ja zum einen auf das Reading. Zum anderen auf die Werte selbst. Man bekommt zwar vom DWD eine Liste an die Hand welche Kenngrößen einstündig upgedated werden und welche nur alle 6 Stunden.
Nur ist man als User erstmal hilflos ... ist der Wert X jetzt u.U. vor 6 Stunden vom DWD upgedated oder vor ein paar Minuten? Das weiß man nicht. Benutzt man nur ein Modell steht dann im  fc_time die Updatetime der Daten vom DWD. Dann ist die Sache klar.
Zwei Readings fc_time_L und fc_time_S helfen m.M. nach auch nicht. Es geht ja nicht daraus hervor welche Werte wozu gehören.

Aber vllt. mache ich es mir da zu schwer ...

[mumpitzstuff]

Hmm okay ich verstehe glaube ich deinen Punkt aber im Prinzip geht ja aus der Tabelle hervor, welcher Wert wo drin ist.

https://www.dwd.de/DE/leistungen/opendata/help/schluessel_datenformate/kml/mosmix_elemente_xls.xlsx;jsessionid=10B9A2329749A3A5A2221337976F39E7.live31091?__blob=publicationFile&v=7

Ist er bei MOSMIX S mit drin, dann entspricht das Reading MOSMIX S, ansonsten MOSMIX L. Außerdem sind doch auch die Werte von MOSMIX L stundenbezogen oder bin ich da jetzt auf dem Holzweg? Jedenfalls benutze ich seit Ewigkeiten MOSMIX L auf Stundenbasis. Die Werte werden halt nur nicht so oft aktualisiert und sind deshalb ungenauer, aber trotzdem ist die Zeitbasis die selbe, nämlich 1h, wenn man das so eingestellt hat.

[DS_Starter]

Außerdem sind doch auch die Werte von MOSMIX L stundenbezogen oder bin ich da jetzt auf dem Holzweg? Jedenfalls benutze ich seit Ewigkeiten MOSMIX L auf Stundenbasis. Die Werte werden halt nur nicht so oft aktualisiert und sind deshalb ungenauer, aber trotzdem ist die Zeitbasis die selbe, nämlich 1h, wenn man das so eingestellt hat.

Absolut richtig. Sie werden zwar auf stundenbasis geliefert, werden aber nur alle 6 Stunden aktualisiert (L).

Mir ging es tatsächlich darum dass man erst in die Liste schauen muß um herauszufinden welche Updatefrequenz der Wert X hat. Es ist auch klar dass die "Cracks" wissen wie die Daten zu lesen sind.
Ich persönlich hätte auch keine Thema damit, bin mir aber sicher dass Fragen kommen ...

Edit: zumindest hätte man mit getrennten Readings fc_time_L und fc_time_S zumindest den Anhaltspunkt für die jeweilige Aktualität ... das würde dann doch hilfreich sein wenn du die implementierst wie vorgeschlagen 

[DS_Starter]

Die getrennte Erzeugung der Readings fc_time_L und fc_time_S würde auch als Indiz taugen ob der Abruf/Auswertung vom MOSMIX_S wirklich funktioniert.
Je mehr ich darüber nachdenke desto besser finde ich diese Variante. 

[Adimarantis]

Ich wollte mich jetzt auch ein wenig mit SolarForecast beschäftigen. Dabei ist mir aufgefallen, dass das DWD Modul mit "unicode" (attr global encoding unicode) überhaupt nicht zurecht kommt.

Im Modul gibt es eine Fehlermeldung
forecast error: unzip failed: Error reading data: Bad file descriptor

Hier die Stacktraces dazu:

Code Auswählen Erweitern

PERL WARNING: Strings with code points over 0xFF may not be mapped into in-memory file handles
2024.03.30 21:26:47.280 1: stacktrace:
2024.03.30 21:26:47.280 1:     main::__ANON__                      called by ./FHEM/55_DWD_OpenData.pm (2289)
2024.03.30 21:26:47.280 1:     (eval)                              called by ./FHEM/55_DWD_OpenData.pm (2275)
2024.03.30 21:26:47.281 1:     DWD_OpenData::ProcessAlerts         called by ./FHEM/55_DWD_OpenData.pm (2239)
2024.03.30 21:26:47.281 1:     DWD_OpenData::GetAlertsStart        called by FHEM/Blocking.pm (194)
2024.03.30 21:26:47.281 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2024.03.30 21:26:47.281 1:     main::BlockingCall                  called by ./FHEM/55_DWD_OpenData.pm (2182)
2024.03.30 21:26:47.281 1:     DWD_OpenData::GetAlerts             called by ./FHEM/55_DWD_OpenData.pm (1047)
2024.03.30 21:26:47.281 1:     DWD_OpenData::Get                   called by fhem.pl (3985)
2024.03.30 21:26:47.281 1:     main::CallFn                        called by fhem.pl (2035)
2024.03.30 21:26:47.281 1:     main::CommandGet                    called by fhem.pl (1282)
2024.03.30 21:26:47.281 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2866)
2024.03.30 21:26:47.281 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (986)
2024.03.30 21:26:47.282 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (609)
2024.03.30 21:26:47.282 1:     main::FW_Read                       called by fhem.pl (3985)
2024.03.30 21:26:47.282 1:     main::CallFn                        called by fhem.pl (786)
2024.03.30 21:26:47.284 1: PERL WARNING: binmode() on closed filehandle $zipFileHandle at /usr/share/perl/5.28/IO/Compress/Base/Common.pm line 100.
2024.03.30 21:26:47.284 1: stacktrace:
2024.03.30 21:26:47.284 1:     main::__ANON__                      called by /usr/share/perl/5.28/IO/Compress/Base/Common.pm (100)
2024.03.30 21:26:47.284 1:     IO::Compress::Base::Common::setBinModeInput called by /usr/share/perl/5.28/IO/Uncompress/Base.pm (437)
2024.03.30 21:26:47.285 1:     IO::Uncompress::Base::_create       called by /usr/share/perl/5.28/IO/Uncompress/Base.pm (749)
2024.03.30 21:26:47.285 1:     IO::Uncompress::Base::_rd2          called by /usr/share/perl/5.28/IO/Uncompress/Base.pm (717)
2024.03.30 21:26:47.285 1:     IO::Uncompress::Base::_singleTarget called by /usr/share/perl/5.28/IO/Uncompress/Base.pm (654)
2024.03.30 21:26:47.285 1:     IO::Uncompress::Base::_inf          called by /usr/share/perl/5.28/IO/Uncompress/Unzip.pm (62)
2024.03.30 21:26:47.285 1:     IO::Uncompress::Unzip::unzip        called by ./FHEM/55_DWD_OpenData.pm (2291)
2024.03.30 21:26:47.285 1:     (eval)                              called by ./FHEM/55_DWD_OpenData.pm (2275)
2024.03.30 21:26:47.285 1:     DWD_OpenData::ProcessAlerts         called by ./FHEM/55_DWD_OpenData.pm (2239)
2024.03.30 21:26:47.285 1:     DWD_OpenData::GetAlertsStart        called by FHEM/Blocking.pm (194)
2024.03.30 21:26:47.285 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2024.03.30 21:26:47.285 1:     main::BlockingCall                  called by ./FHEM/55_DWD_OpenData.pm (2182)
2024.03.30 21:26:47.286 1:     DWD_OpenData::GetAlerts             called by ./FHEM/55_DWD_OpenData.pm (1047)
2024.03.30 21:26:47.286 1:     DWD_OpenData::Get                   called by fhem.pl (3985)
2024.03.30 21:26:47.286 1:     main::CallFn                        called by fhem.pl (2035)
2024.03.30 21:26:47.286 1:     main::CommandGet                    called by fhem.pl (1282)
2024.03.30 21:26:47.286 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2866)
2024.03.30 21:26:47.286 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (986)
2024.03.30 21:26:47.286 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (609)
2024.03.30 21:26:47.286 1:     main::FW_Read                       called by fhem.pl (3985)
2024.03.30 21:26:47.286 1:     main::CallFn                        called by fhem.pl (786)

Wahrscheinlich müssten hier einige Strings explizit umgewandelt werden - in der Art:

Code Auswählen Erweitern

use Encode;
[...]
$text=decode_utf8($text) if !($unicodeEncoding);Bzw. encode_utf8 - komme immer selber durcheinander was man wann braucht.

Da FHEM die unicode Einstellung schon seit einiger Zeit unterstützt, wäre es schön wenn das Modul damit lauffähig wäre.

[Felix_86]

... Intervall auf 30 oder gar 60 Minuten ... reicht mir völlig aus.

Nehme ich so mit. Werde dafür ein Attribut einführen - allerdings nicht kurzfristig, da ich gerade noch an etwas anderem arbeite.

Hallo Jens,

wie ist denn der Stand zu dem Attribut um die Intervall festzulegen?
Ich nutze das Modul DWD_OpenData in der VERSION 1.016003 und kann kein Attribut sehen.

Danke vorab.

[tomcat.x]

Hallo,

mir ist gerade aufgefallen, dass ich im SolarForcast-Gerät keine Vorhersage für morgen habe. Daraufhin dann, dass im DWD-Gerät die Rad1h-Werte nur für heute vorhanden sind, andere gibt es auch für morgen. Beim Versuch per get forcast ein Update zu machen, bekomme ich:

Code Auswählen Erweitern

fhemweb.js line 1334:
SyntaxError: JSON.parse: expected ',' or ']' after array element at line 1 column 31 of the JSON data
Geht das nur bei mir nicht mehr?

Viele Grüße
Thomas

[tomcat.x]

Hm, also der Fehler kommt nicht mehr, wenn ich forecastWW2Text auf 0 setze. Werte für Rad1h bekomme ich trotzdem nicht mehr. Hat also nichts damit zu tun. Sieht so aus, als ob die gewählte Station auf einmal (oder für morgen) keine Rad1h-Daten mehr liefert. Die kamen zuletzt gestern (04.04.) um 6:00 Uhr.