Modul für DWD Open Data

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

Vorheriges Thema - Nächstes Thema

Knallkopp_02

#660
Ich werde schauen, was ich machen kann. Die Einstellungen selbst sind schon so klein/gering gewählt wie es geht, aber es sind für halt immer noch viele Daten.

Das mit dem Abschalten der Aktuallisierung ist eine gute Idee, nur leider für mich warscheinlich nicht umsetzbar, da das Radio den ganzen Tag läuft und daher dann nur Nachts aktuallisierungen gemacht werden. Werde ich aber mal testen mit 2 Aktuallisierungen am Tag, sollte reichen.

Gruß Knallkopp_02
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

Knallkopp_02

Ich habe das jetzt über die letzten Tage getestet, funktioniert soweit gut, es hat nur einen kleinen Schönheitsfehler, dass immer angezeigt wird, dass die Config geändert ist und gespeichert werden soll, was ja auch richtig ist, da ja ein Attribut geändert wird.

Gruß Knallkopp_02
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

moskito

Da hilft Dir der Befehl "save" weiter.

Gruß
Danny
FHEM auf Intel NUC/Proxmox & Debian 12 + HM-CFG-USB + zigbee2mqtt + Zwave + Enocean

rabehd

Es hat sicher einen Grund warum es den Befehl SAVE gibt und nicht ein AUTOSAVE läuft.
Auch funktionierende Lösungen kann man hinterfragen.

Knallkopp_02

Das stimmt natürlich, das SAVE kann man ja noch mit übergeben, thx
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

wolfgang99

Ich möchte Wetter auf DWD umstellen und habe mich an alles aus Doku gehalten.
Alerts werden geupdatet, aber der forecast meldet:
error: HTTP error 404 retrieving URL 'https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_L/single_stations/99801/kml/MOSMIX_L_LATEST_99801.kmz '
und FHEM meldet nach Start
2020.01.11 10:42:56.793 1: reload: Error:Modul 99_DWD_OpenData_Weblink deactivated:
Excessively long <> operator at ./FHEM/99_DWD_OpenData_Weblink.pm line 21, <$fh> line 93.
2020.01.11 10:42:56.793 0: Excessively long <> operator at ./FHEM/99_DWD_OpenData_Weblink.pm line 21, <$fh> line 93.
configfile: Cannot load module DWD_OpenData_Weblink
Danke für Tips

mumpitzstuff

Ein list von deinem Device wäre hilfreich.

jensb

@wolfgang99

Ich kann @mumpitzstuff nur zustimmen:
Zitat von: mumpitzstuff am 11 Januar 2020, 21:08:10
Ein list von deinem Device wäre hilfreich.
Deine Beschreibung ist ein bisschen kanpp. Ansonsten scheint es um 2 verschiedene Probleme zu gehen:

Ein Klick auf deinen Link
Zitat von: wolfgang99 am 11 Januar 2020, 11:12:39
'https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_L/single_stations/99801/kml/MOSMIX_L_LATEST_99801.kmz '
liefert auch mit einem normalen Browser Fehler 404. Wenn du die URL auf https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_L/single_stations/ verkürzt, bekommst du die möglichen Stationen angezeigt und 99801 ist nicht dabei. Kann es sein, dass du für die Vorhersage eine Stationsnummer für Wetterwarnungen verwendest? Schau dir noch mal die Modulhilfe an und wähle eine Station aus, die in der Liste von der verkürzten URL enthalten ist.

Zitat von: wolfgang99 am 11 Januar 2020, 11:12:39
und FHEM meldet nach Start
2020.01.11 10:42:56.793 1: reload: Error:Modul 99_DWD_OpenData_Weblink deactivated:
Excessively long <> operator at ./FHEM/99_DWD_OpenData_Weblink.pm line 21, <$fh> line 93.
2020.01.11 10:42:56.793 0: Excessively long <> operator at ./FHEM/99_DWD_OpenData_Weblink.pm line 21, <$fh> line 93.
configfile: Cannot load module DWD_OpenData_Weblink
Es könnte sein, dass das Encoding des Modul-Quelltexts auf dem Weg von GitHub auf dein FHEM-System verändert wurde. Das kann sowohl beim Download auf den PC als auch beim Übertragen vom PC auf dein FHEM-Sytem passieren. Mit diesem Link sollte es beim Download nicht passieren. Beim Übertragen auf das FHEM-System mit Tools wie WinSCP immer den Binärmodus verwenden.

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

wolfgang99

Alle Hinweise waren korrekt! (Hätte ich aush selbst sehen müssen :(
Alles gut und läuft!  :)
Vielen Dank!

Elektrofreak

Ich habe eine Frage zum Reading fc1_PEvap.

Ich habe mir ein notify auf den Wert gelegt und lasse mich per pushbullet über Änderungen informieren.

Was mich wundert ist, dass innerhalb von 24h der Wert aktualisiert wird, die Werte aber weit voneinander abweichen... ist das normal? Hier ein Beispiel für ein und den selben Tag:

00:00 INFO: Wetter - Es wird für heute eine Verdunstung von 4.40 L/qm erwartet.
07:00 INFO: Wetter - Es wird für heute eine Verdunstung von 1.70 L/qm erwartet.

Ist es plausibel und realistisch, dass die Werte so stark innerhalb eines Tages für die nächsten 24h schwanken? Wenn würde ich eine Abweichung von Max. 50% erwarten, wenn sich das Wetter nur geringfügig ändert. Und momentan ist jeden Tag 14h Sonne und ca. 18°C, die Temperaturen ändern sich nur um wenige Grad . Nur der Wind ändert sich... ???

jensb

@Elektrofreak

Physikalisch kann sich die Verdunstung nicht ohne weiteres sprunghaft ändern.

Aber PEvap ist kein Sensor-Wert mit Minutenauflösung sondern ein Vorhersagewert für die letzten 24 Stunden. Kann es sein, dass er sich PEvap meist einmal am Tag zu einer bestimmten Uhrzeit ändert? Denn die Tagesvorhersagewerte haben eine bestimmte Bezugszeit, und die ist im Normalfall nicht 00:00 sondern z.B. 06:00 (siehe Commandref).

Das heißt auch, dass man für gestern 06:00 bis heute 06:00 auf den Wert fc0 und erst danach auf fc1 schauen muss. Außerdem wird um 00:00 aus den fc1-Readings die fc0-Readings usw. Das verursacht in jedem Fall einen Sprung, wenn man das gleiche Reading betrachtet, da sich der Zeitbezug verschiebt.

Eine andere Erklärung wäre z.B. relativ stark variierendes und entsprechend schwer vorhersagbares Lokalwetter, das es in einigen Gegenden gibt.

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

Elektrofreak

Guten Morgen,

Ich hatte die Anzahl der Forecast-Tage auf 1 gestellt, er hat auch kein Reading fc0_PEvap.

Was du schreibst macht Sinn. Um Mitternacht übernimmt er Werte von woher auch immer und jeden Morgen um 6:00 Oder 7:00 bekommt er "echte" neue Vorhersagewertr vom DWD. Ich habe mal dir Anzahl der Tage auf 2 gestellt, sodass ich auch die Vorhersage für den darauffolgenden Tag sehe. Mal schauen, ob jetzt das Update um Mitternacht plausiblere Werte liefert...

Ansonsten würde ich sagen ist es ein Bug im Modul, wenn er um Mitternacht etwas falsches errechnet und das reading aktualisiert. Ich hätte auch erwartet, dass der Wert von morgens um 06:00 stimmt, so habe ich es in der Dokumentation auch verstanden...

jensb

@Elektrofreak

Zitat... ist es ein Bug im Modul, wenn er um Mitternacht etwas falsches errechnet ...

Nein, es ist kein Bug und das Modul berechnet auch nichts selbst. Das Modul ist, vereinfacht gesagt, ein Downloader, der die Daten vom DWD unverändert als Readings bereitstellt. Allerdings rotiert das Modul, wie von mir im vorherigen Post beschrieben, selbstständig alle Readings um Mitternacht.

Grund: Es gibt nicht genau um 00:00 ein Update vom DWD, aber genau um 00:00 ist heute vorbei und morgen beginnt (oder so ähnlich, je nach dem wie man das betrachtet). Jedenfalls werden dann die Vorhersagewerte fc1 fürs "alte morgen" automatisch die vom "neuen heute" und die vom "alten heute" werden überschrieben. Das Gleiche wird mit fc2 usw. gemacht. Der letzte Vorhersagetag wird dabei gelöscht. Diese Vorgehensweise ändert ebenfalls nichts an den Werten vom DWD, aber sie stehen halt hinterher in anderen Readings. Erst irgendwann später treffen dann neue Werte ein. Das kann z.B. erst um 06:00 oder 07:00 sein, wenn die neuen Berechnungen beim DWD durchgeführt und bereitgestellt wurden.

Alle Vorhersagewerte sind mit einem zukünftigen Zeitpunkt verknüpft, dem man am Reading fcX_date bzw. fcX_Y_time ablesen kann. Das ist der große Unterschied zu Live-Messwerten, die immer nur für "jetzt" gelten.

Wenn also um 00:00 rotiert wird, musst du nach den von mir beschriebenen Regeln ein anderes Reading verwenden, um den gleichen Wert zu behalten. Es reicht halt nicht, bei Tageswerten wie PEvap nur ein bestimmtes Reading auszuwerten. Du musst zusätzlich das Datum und den Geltungsbereich des Reading (z.B. letzte 24 Stunden bzgl. 06:00) berücksichtigen. Faktisch musst du also abhängig von der aktuellen Uhrzeit nach dem passenden Reading suchen. Das ist je nach Anwendungsfall vielleicht etwas unpraktisch aber unvermeidbar.

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

Elektrofreak

Hallo Jens,

Danke für die Erklärung. Du hast recht. Jedoch sind die Updates der Werte trotzdem komisch. Beispiel von heute morgen:

Gestern 07:00 3.5L/(24h*m^2)
Heute 00:00 3.2L/(24h*m^2)
Heute 01:00 6.2L/(24h*m^2)
Heute 07:00 3.3L/(24h*m^2)

Mich irritiert der Wert heute Nacht um 01:00Uhr, ähnlich wie die Tage zuvor. Die anderen Werte sehe ich auch mit deiner Begründung als plausibel an...

Du kannst ja mal die Daten meiner Lokalität mit deiner vergleichen und schauen, ob das Verhalten reproduzierbar ist...

forecastStation ist N8334

RomanticBoy83

Ist der Wert um 1:00 eventuell ein "UTC" Problem.
Ich kann mich wage an meine Implementierung erinnern, dass alle Werte auf openData in UTC angegeben sind. Jetzt wäre hilfreich gewesen hätte er auch "gestern" geloggt.
Ich selber nutze das Modul leider nicht - deshalb kann ich auch nicht weiter helfen außer meine Vermutung äußern.