Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

Modul für DWD Open Data

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

Vorheriges Thema - Nächstes Thema

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

ZitatFrage 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
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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

ZitatWü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.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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

#1056
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 ... ;)
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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

#1058
ZitatAuß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  :)
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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.  ;)
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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:

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:
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.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Felix_86

Zitat von: jensb am 19 Dezember 2023, 22:58:09
Zitat von: Felix_86 am 18 Dezember 2023, 13:17:09... 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.
Grüße von Felix

Pi3, Raspbian 11, FHEM 6.2, ca 330 Device
SIGNALduino (TCM, TX, IT, SD_GT), CUL (EM, FS20, HMS), JeeLink (PCA301), HUEBridge, HUEDevice, mailcheck, echodevice, alexa, TelegramBot, Weather (OWM), DWD_OpenData, FRITZBOX, TabletUI, Calendar, Abfall, Vitoconnect, LGTV_WebOS, Nina, MQTT2

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:

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
FHEM: 6.3 auf Raspi 3B+, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.00), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

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.
FHEM: 6.3 auf Raspi 3B+, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.00), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

DS_Starter

Hallo zusammen,

ich habe die Version von mumpitzstaff übernommen bzw. mit meiner Version zusammengeführt, die Versionsnummer fortgeschrieben und als V 1.17.4 in mein contrib (Fußtext) geladen.
Eventuelle weitere Änderungen/Entwicklungen bitte auf dieser Version aufbauen um den Überblick zu behalten solange das Modul nicht eingecheckt ist.
Mal sehen ob/wann Jensb sich dazu äußert. Er war das letzte Mal am 24.03. angemeldet.

schöne Pfingsten.

LG,
Heiko

Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter