Modul für DWD Open Data

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

Vorheriges Thema - Nächstes Thema

D3ltorohd

#645
Ich wollte mir das Wetter anzeigen lassen, hab das nach dem Wiki eingerichtet, aber irgendwas schein hier noch nicht so ganz zu funktioniere. Wenn ich list dwd mache kommt dort folgendes.
2019-08-03 15:00:05   fc_state        error: HTTP error 404 retrieving URL 'https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_L/single_stations/99809/kml/MOSMIX_L_LATEST_99809.kmz '

Wie kann ich das beseitigen ? Gibt es die Station nicht, oder grad nur Probleme mit der Seite ?

Hier die ganze list


Internals:
   ALERTS_IN_CACHE 72
   CFGFN     
   FHEM_TZ   
   FUUID      5d452ed5-f33f-fc62-31bc-9497124db03ea8aa
   NAME       DWD
   NR         2506
   STATE      alerts updated
   TYPE       DWD_OpenData
   READINGS:
     2019-08-03 16:15:06   a_count         0
     2019-08-03 16:15:06   a_state         updated
     2019-08-03 16:15:06   a_time          2019-08-03 16:15:05
     2019-08-03 16:00:05   fc_state        error: HTTP error 404 retrieving URL 'https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_L/single_stations/99809/kml/MOSMIX_L_LATEST_99809.kmz '
     2019-08-03 16:15:06   state           alerts updated
Attributes:
   alertArea  808437076
   event-on-update-reading state,fc_state,a_state
   forecastDays 4
   forecastStation 99809
   forecastWW2Text 1


EDIT.
Ok hab den Fehler gefunden, hab noch mal genau nachgelesen, hatte nicht die ID sondern eine andere Nummer erwischt, mit der richtigen ID bekomme ich nen haufen readings.
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

Xguide

#646
Hallo zusammen,

es wurde schon mal auf das uninitialized  value hingewiesen, konnte aber keine weitere Verfolgung dazu finden.
Gibt es einen Lösungsansatz dazu? Hier ist es jetzt beim Neustart aufgetreten.


PERL WARNING: Use of uninitialized value $warncellId in numeric eq (==) at /opt/fhem//FHEM/55_DWD_OpenData.pm line 1371.


Ferner finde ich diesen Fehler relativ regelmäßig und hatte die ganze Zeit ein anderes Modul in Verdacht. Mit stacktrace wurde mir der DWD_Weblink genannt.


2019.08.26 17:02:58 1: PERL WARNING: Use of uninitialized value in subroutine entry at /opt/fhem//FHEM/99_Utils.pm line 21.
2019.08.26 17:02:58 1: stacktrace:
2019.08.26 17:02:58 1:     main::__ANON__                      called by /opt/fhem//FHEM/99_Utils.pm (21)
2019.08.26 17:02:58 1:     main::time_str2num                  called by /opt/fhem//FHEM/99_DWD_OpenData_Weblink.pm (756)
2019.08.26 17:02:58 1:     DWD_OpenData_Weblink::PrepareForecastData called by /opt/fhem//FHEM/99_DWD_OpenData_Weblink.pm (1151)
2019.08.26 17:02:58 1:     DWD_OpenData_Weblink::GetForecastHtmlH called by /opt/fhem//FHEM/99_DWD_OpenData_Weblink.pm (359)
2019.08.26 17:02:58 1:     DWD_OpenData_Weblink::Get           called by fhem.pl (3753)
2019.08.26 17:02:58 1:     main::CallFn                        called by fhem.pl (1958)
2019.08.26 17:02:58 1:     main::CommandGet                    called by fhem.pl (1236)
2019.08.26 17:02:58 1:     main::AnalyzeCommand                called by fhem.pl (1089)
2019.08.26 17:02:58 1:     main::AnalyzeCommandChain           called by /opt/fhem//FHEM/01_FHEMWEB.pm (2678)
2019.08.26 17:02:58 1:     main::FW_fC                         called by /opt/fhem//FHEM/01_FHEMWEB.pm (908)
2019.08.26 17:02:58 1:     main::FW_answerCall                 called by /opt/fhem//FHEM/01_FHEMWEB.pm (578)
2019.08.26 17:02:58 1:     main::FW_Read                       called by fhem.pl (3753)
2019.08.26 17:02:58 1:     main::CallFn                        called by fhem.pl (748)


Ich habe mal versucht es so abzufangen, ich berichte ob es funktioniert!


    my $epoch = 0;
if ($date && $time)
{
  $epoch = ::time_str2num($date.' '.$time);
}


Grüße Marcel
FHEM 5.9 - Intel NUC i3 mit Proxmox im Stretch Container
HomeMatic - VCCU mit 2 x HM-LAN-CFG
Module: SMA Peripheries - Sonos - IPCam(s) - Philips Hue - Sprinkler - TabletUI - DBlog -

Xguide

Zitat von: Xguide am 26 August 2019, 17:03:49
Ferner finde ich diesen Fehler relativ regelmäßig und hatte die ganze Zeit ein anderes Modul in Verdacht. Mit stacktrace wurde mir der DWD_Weblink genannt.

Der Lösungsansatz hat nicht funktioniert.
Temporär habe ich es jetzt in 99_Utils.pm begradigt. Hintergrund, 99_DWD_OpenData_Weblink.pm liefert manchmal keine Sekunden mit.
Hat jemand einen Ansatz wie das schön abgefangen werden kann?


2019.08.26 17:36:46 1: MS....:2019-08-26 02:00
2019.08.26 17:36:46 1: MS....:2019-08-26 08:00
2019.08.26 17:36:46 1: MS....:2019-08-26 14:00
2019.08.26 17:36:46 1: MS....:2019-08-26 20:00
2019.08.26 17:36:46 1: MS....:2019-08-26 20:00:00
2019.08.26 17:36:46 1: MS....:2019-08-27 02:00:00
2019.08.26 17:36:46 1: MS....:2019-08-27 08:00:00
2019.08.26 17:36:46 1: MS....:2019-08-27 14:00:00
2019.08.26 17:36:46 1: MS....:2019-08-28 08:00:00
2019.08.26 17:36:46 1: MS....:2019-08-28 14:00:00


Folgendes hat den Fehler temporär eliminiert:


#99_Utils.pm

my $sec = $a[5];
if (!$sec)
{
  $sec = 0;
}
    return mktime($sec,$a[4],$a[3],$a[2],$a[1]-1,$a[0]-1900,0,0,-1);
FHEM 5.9 - Intel NUC i3 mit Proxmox im Stretch Container
HomeMatic - VCCU mit 2 x HM-LAN-CFG
Module: SMA Peripheries - Sonos - IPCam(s) - Philips Hue - Sprinkler - TabletUI - DBlog -

JHo

Hallo,
ich habe zwei Verständnisfragen zum Modul, vielleicht bin ich gedanklich auf dem Holzweg oder noch nicht tief genug in die Bedeutungen eingestiegen.

1) Ich möchte die PEvap-Werte von heute, morgen und übermorgen zur Anpassung der heute notwendigen Bewässerung verwenden. Dazu werden die jeweils um 03:00 nachts gespeicherten PEvap-Werte fc1_PEvap, fc2_PEvap und fc3_PEvap herangezogen.
Zitat von: jensb am 13 April 2019, 20:03:42
Der 1. Wert für PEVap ist der 39. Eintrag basierend auf 16:00 UTC. Damit landen wir bei Übermorgen 08:00 Europe/Berlin. PEVap ist ein 24h-Wert. Dieser Wert gilt dann für Morgen 08:00 bis Übermorgen 08:00. Das klingt vielleicht verwirrend, ist aber vom DWD so definiert.
Verstehe ich das richtig, dass der heute um 03:00 abgerufene fc1_PEvap-Wert dann den Wert von heute 03:00 bis morgen 03:00 darstellt? Und der fc1_PEvap von heute um 07:00 dann die 24h bis morgen um 07:00, etc.?


2) Bei den Regenwahrscheinlichkeiten für die nächsten Tage (fcX_Rd00) finde ich im Log die Besonderheit, dass scheinbar bei jedem Update zwei verschiedene Werte pro Tag eingetragen werden:
2019-09-12_08:00:05 DWD fc0_Rd00: 87.00
2019-09-12_08:00:05 DWD fc0_Rd00: 80.00
2019-09-12_08:00:05 DWD fc1_Rd00: 34.00
2019-09-12_08:00:05 DWD fc1_Rd00: 11.00
2019-09-12_08:00:05 DWD fc2_Rd00: 37.00
2019-09-12_08:00:05 DWD fc2_Rd00: 17.00

Ich finde diese Werte im kml-File direkt "nebeneinander":
<dwd:Forecast dwd:elementName="Rd00">
                    <dwd:value>          -          -      87.00      80.00          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -      34.00      11.00          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -      37.00      17.00

Warum wird das fc0_Rd00-Reading gesetzt (87) und sofort mit dem Wert 80 wieder überschrieben, was ist der Sinn davon?

Danke für den Gedanken-Schubs in die richtige Richtung!
Jan
1: FHEM auf Ubuntu, MAX!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, diverse LaCrosse-Sensoren, per remote angebundene DS18B20-Sensoren
2: FHEM auf Raspi 3, Max!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, ht_pitiny-Adapter zu Junkers FW120

jensb

Hallo Jan,

Zitat von: JHo am 13 September 2019, 11:53:14
1) Verstehe ich das richtig, dass der heute um 03:00 abgerufene fc1_PEvap-Wert dann den Wert von heute 03:00 bis morgen 03:00 darstellt? Und der fc1_PEvap von heute um 07:00 dann die 24h bis morgen um 07:00, etc.?

Wie so oft muss ich dazu auf die Spezifikationen vom DWD und auf die Commandref verweisen. In der Commandref steht dazu:
ZitatPEvap [kg/m2] - evapotranspiration of previous 24 hours
Das heißt, dass der Wert am Ende des Zeitintervalls angegeben wird. fc1 steht ja für morgen. Damit bezieht sich der Wert auf den Zeitraum von heute bis morgen. Die Bezugsstunde hängt davon ab, wann der DWD den Wert in der KML-Datei ausgibt. Es hat nichts damit zu tun, wann der Wert vom DWD abgerufen wird. Steht in der KML-Datei der Eintrag bei 07:00 UTC dann wäre das heute 09:00 bis morgen 09:00 CEST.

Zitat von: JHo am 13 September 2019, 11:53:14
2) Warum wird das fc0_Rd00-Reading gesetzt (87) und sofort mit dem Wert 80 wieder überschrieben, was ist der Sinn davon?
Rd00 ist ein Tageswert, davon kann es nur einen geben. Du müsstest fragen, warum der DWD davon 2 pro Tag aufliefert (was ich nicht beantworten kann). Das DWD-Modul entscheidet sich halt für einen.

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

D3ltorohd

Hm hab irgendwie seit heute folgende Meldung stehen ::

Fehler: error retrieving URL 'https://opendata.dwd.de/weather/alerts/cap/COMMUNEUNION_CELLS_STAT/Z_CAP_C_EDZW_LATEST_PVW_STATUS_PREMIUMCELLS_COMMUNEUNION_DE.zip': https://opendata.dwd.de/weather/alerts/cap/COMMUNEUNION_CELLS_STAT/Z_CAP_C_EDZW_LATEST_PVW_STATUS_PREMIUMCELLS_COMMUNEUNION_DE.zip: Can't connect(1) to https://opendata.dwd.de:443: IO::Socket::INET: Bad hostname 'opendata.dwd.de:443'

Hat das was mit ssl zu tun ? Hatte gestern oder vorgestern noch
Zitatcpan -i IO::Socket::SSL
installiert, kann das damit zusammenhängen ?

Und wenn ja wie, bekomme ich DWD wieder vollständig zum laufen ?
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

curt

@D3ltorohd

Deine fragender Beitrag wirkt nicht schlüssig - Du hast nicht alles erzählt.

Zitat von: D3ltorohd am 20 Oktober 2019, 11:24:25
Hm hab irgendwie seit heute folgende Meldung stehen ::

Also das lief schon?

Zitat von: D3ltorohd am 20 Oktober 2019, 11:24:25

...
Can't connect(1) to https://opendata.dwd.de:443: IO::Socket::INET: Bad hostname 'opendata.dwd.de:443'


Das klingt eher danach, dass DNS in dem Moment einen Hustenanfall hatte. Der geht von allein wieder weg - unterstellt, Du hast nirgendwo geschraubt.

Zitat von: D3ltorohd am 20 Oktober 2019, 11:24:25
Hat das was mit ssl zu tun ? Hatte gestern oder vorgestern noch  installiert, kann das damit zusammenhängen ?

Auf den ersten Blick halte ich das für unwahrscheinlich.

Zitat von: D3ltorohd am 20 Oktober 2019, 11:24:25
Und wenn ja wie, bekomme ich DWD wieder vollständig zum laufen ?

Du musst halt mehr erzählen. So eine halbe Geschichte kann doch niemand nachvollziehen.

Und Du hast ja auch eine Vollsicherung dieses Servers, ja?
Um Deine Fehleridee völlig auszuschließen, spielst Du die zurück. Und schaust, ob es wieder läuft. ;)
RPI 4 - Jeelink HomeMatic Z-Wave

D3ltorohd

Genau, DWD ist schon seit einer Weile eingerichtet und lief bis dato auch ohne Probleme. In der FTUI hatte ich hier und da auch mal Wetterwarnungen stehen.

An dem Tag meines Posts, habe ich eigentlich was ganz anderes probiert. Und beim testen in FTUI ist mir dann die Fehlermeldung aufgefallen.

Aber ich schau mir das noch mal an heute. Vllt war das nur ein DNS Problem wir du meintest und läuft wieder.
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

jensb

@D3ltorohd

Das DWD-Modul verwendet die HttpUtils von FHEM für den Download und das verwendet den Perl sysread auf IO::Socket::INET/INET6 bzw. IO::Socket::SSL. Insofern ist hier das Modul IO::Socket::SSL sehr wohl direkt im Spiel. Wenn du die anderen IO::Socket Module bzw. Perl mit apt installiert hast und nur IO::Socket::SSL mit cpan könnte das durchaus ein Grund sein. Falls das der Fall ist versuche IO::Socket::SSL auch mit apt zu installieren (auf einigen Systemen funktioniert z.B. apt install libio-socket-ssl-perl). Dann FHEM neu starten und den Test wiederholen.

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

D3ltorohd

Ok, Danke für die Info. Ich schau mir das mal an. Momentan kann ich keine Fehler im DWD sehen.
Zitatstate
alerts updated
Ich lasse es erst mal so. Vllt war ja wirklich grad in dem Moment nur ein Problem mit dem Internet. Sollte ich derartige Fehler noch mal sehen, werde ich deinen Tipp mal versuchen.
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

D3ltorohd

Noch mal eine Frage. Gibt es die Möglichkeit, über dieses Modul eine aktuelle Temperatur ab zu fragen, so wie von einer Außenstation ?

Ich habe jetzt für jede Stunde einen Eintrag in den Readings. Wie nun müsste man ja für jede Temperatur ein eigenes Label erstellen. Gibt es nen Trick oder eine Möglichkeit, das ich nur eine Temp Anzeige in FTUI habe, diese sich aber alle h erneuert und den nächsten Wert vom DWD Modul abholt ?

Da ich leider keine Außenstation oder sonstiges habe, würde ich das erst mal so lösen wollen. So hab ich wenigstens die ungefähre Temperatur.
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

jensb

Zitat von: D3ltorohd am 27 Oktober 2019, 08:45:00
Noch mal eine Frage. Gibt es die Möglichkeit, über dieses Modul eine aktuelle Temperatur ab zu fragen, so wie von einer Außenstation ?

Der DWD liefert über den OpenData Server auch aktuelle Messwerte. Allerdings sind diese Daten völlig anders strukturiert als die Vorhersagedaten und der Abruf deshalb relativ aufwendig. Auch wenn man nur die Isttemperatur benötigt, muss man sehr viele andere Daten mit herunterladen und dann weg filtern und das auch noch relativ regelmäßig wiederholen. Es wäre also ein sehr ineffizienter Ersatz für einen Außentemperaturfühler und deshalb ist es bisher nicht implementiert worden.

Im DWD_OpenData_Weblink ist Perl-Code, der aus den Vorhersagedaten die zeitlich nächstgelegenen heraussucht und im 1. Icon verwendet - das sind die Daten die du suchst. Allerdings bildet der Weblink keine Readings sondern baut das HTML direkt auf. Du könntest aber den folgenden Perl-Code aus ca. Zeile 1119 als Basis verwenden, z.B. in einem at:


eval "use DWD_OpenData_Weblink;";
...
my ($items, $timeResolution, $offsets, $data, $alertMessages) = DWD_OpenData_Weblink::PrepareForecastData("myDWD_OpenData_Module", 1, 0, "light");


Im Element "$$data[0]{tempValue}" steckt die gesuchte Temperatur. Wahrscheinlich wird es erforderlich sein, dass du aus formalen Gründen ein DWD_OpenData_Weblink-Device anlegst, damit der Modul-Code von FHEM geladen wird, auch wenn du es nicht anzeigen willst.

Ansonsten gibt es diverse Ansätze die Daten in der FTUI zu nutzen, das ist aber nicht meine Spielwiese. Ein paar Sachen stehen dazu weiter vorn in diesem Thread. Ansonsten hilft dir die Suchfunktion aus dem Forum vielleicht weiter.

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

Knallkopp_02

Ich habe einen Raspberry 3b+ mit Display, dort habe ich ein Webradio und das Wetter mit FTUI realisiert.

Leider kommt es immer zur vollen Stunde vor, dass das Radio einen aussetzer von mehreren Sekunden hat. Als Ursache habe ich mal das DWD Modul ausgemacht. Es läuft genau zum passenden Moment und holt neue Daten. Entweder ist der Raspberry so beschäftigt mit dem holen und aufarbeiten Der Daten, oder die Komplette Bandbreite der WLAN Verbindung wird genutzt, sodas keine Musikdaten geladen werden können, und daher der Aussetzer stammt.

Hat jemand eine Idee, wie man das beheben könnte.

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

Die Frage ist wie wichtig dir die aktuellen Wetterdaten sind! Du könntest zum Beispiel, wenn du eine Möglichkeit hast den Status des Webradios zu ermitteln, das DWD Modul über das Attribut "disable" in der Zeit abschalten.
Ansonsten gibt´s in der Modulhilfe schon Hinweise, dass das Verarbeiten der Daten auf schwacher Hardware zu Problemen führen kann, und was man tun kann.
ZitatNote that depending on your device configuration each forecast consists of quite a lot of readings and each reading update will cause a FHEM event that needs to be processed. Depending on your hardware and your FHEM configuration this will take several hundred milliseconds. If you need to improve overall performance you can limit the number of readings created by setting a) the attribute forecastProperties to the ones you actually use, b) the attribute forecastResolution to the highest value suitable for your purposes and c) the attribute forecastDays to the lowest number suitable for your purposes. To further reduce the event processing overhead you can set the attribute event-on-update-reading to a small list of important reading that really need events (e.g. state,fc_state,a_state).

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

jensb

@Knallkopp_02

Der Vorschlag von Danny ist gut. Er stellt eine besondere Form der Umsetzung QoS dar. QoS erlaubt es verschiedenen Netzwerkdiensten verschiedene Übertragungsprioritäten zuzuordnen (siehe z.B. https://debian-handbook.info/browse/de-DE/stable/sect.quality-of-service.html). Problematisch für normales QoS ist hier, dass sich beide Quellen im Internet befinden und über Port 443 abgerufen werden. Das Ziel ist auch gleich, beides mal der Raspberry. An Quelle und Ziel lässt sich die Priorität also nicht festmachen. Damit scheitern Ansätze, wo man die Priorität z.B. über die Konfiguration einer Fritzbox beeinflussen kann (siehe z.B. https://avm.de/service/fritzbox/fritzbox-7590/wissensdatenbank/publication/show/228_Internetzugang-fur-wichtige-Netzwerkgerate-und-anwendungen-priorisieren/).

Auf Anwendungsebene den einen Dienst abzuschalten, wenn der andere genutzt wird, ist da noch die beste Lösung, wenn die in der Modulhilfe aufgeführten Vorschläge nicht ausreichen. Der DWD liefert bisweilen halt relativ große Dateien (mehrere Megabyte). Je nach effektiver WLAN-Bandbreite, Auslastung des Internetzugangs und freier CPU-Leistung des Raspberry dauert der Download etwas.

Allerdings kannst du noch prüfen, ob du den Receive-Buffer deines Webradios vergrößern kannst. Dann dauert der Start des Webradios zwar etwas länger, ist dann aber nicht mehr so störanfällig.

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