Modul für DWD Open Data

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

Vorheriges Thema - Nächstes Thema

binford6000

Hallo Jens,
Zitatsolltest du nach dem Entfernen und Speichern in der fhem.cfg nachsehen, ob da trotzdem noch etwas zu "TZ" oder "timezone" zu finden ist.
Nichts zu finden.
ZitatEs könnte auch sein, dass die TZ-Einstellung in der Datei "./backup_cfg-state/fhem.state...." steckt.
Ebenfalls nichts zu finden.
Nach Ändern von /etc/init.d/fhem erhalte ich nach
{ $ENV{TZ} } Europe/Berlin zurück. Soweit so gut. Danke für den schnellen Support.
VG Sebastian



JoWiemann

Hallo Jens,

ich habe das get() jetzt mal auf GetFileFromURL() aus dem Fhem Helpermodul HttpUtils (use HttpUtils;) umgestellt. Und siehe da, es funktioniert. Jetz das Ganze noch auf nonBlocking umgestellt und fein ist.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Maista

#17
@jensb

Hallo Jens,

{ $ENV{TZ} }
Zeigt bei mir nur ein Problem mit d_ccu an. Und "Autosave deactivated".

Meine Uhrzeit geht in FHEM nun ebenso eine Stunde nach.
Hatte Update eingegeben. Da es nichts gab wurde nur ein Backup erstellt und neu gestartet.

Zitat2018.02.04 19:52:01 1: backup done: FHEM-20180204_194642.tar.gz (47118033 Bytes)
2018.02.04 19:52:03 1: nothing to do...
2018.02.04 19:03:37 3: CUL433 IT: EG_Fenster_Zimmer1.1 closed->on

unter /etc/init.d/timezone steht "Europe/Berlin".

Nach dem ich die Modul-Definition gelöscht habe ist die Zeit immer noch -1h ?!

Was biegst Du den da um  ;D

Update :
Habe in der Startdatei "/etc/init.d/fhem" dein Vorschlag eingefügt mit dem Export.
Aber die Zeit geht immer noch nach!

Systemzeit vom RPi stimmt.
Zitatbla@RPi2:/opt/fhem# date
Sun Feb  4 20:41:04 CET 2018

Gruss Gerd

jensb

#18
Hallo Gerd,

die Systemzeit vom RPi ist egal, entscheidend ist die TZ-Umgebungsvariable, die Perl und damit FHEM sieht. Wenn du die PID des Perl-Prozesses von FHEM ermittelst, kannst du auch auf der Shell mit "cat /proc/<pid>/environ" alle Umgebungsvariablen des laufenden Prozesses ansehen. Entweder steht die TZ mit in der Ausgabe oder nicht.

Zur Laufzeit ist für Perl $ENV{TZ} ausschlaggebend. In der FHEM-Kommandozeile muss bei Eingabe von "{ $ENV{TZ} }" die Zeitzone angezeigt werden, wenn sie überhaupt gesetzt ist.

Die Hintergründe kann man auch noch mal hier nachlesen.

Wo der Effekt herkommt, weiß ich noch nicht, da es bei mir nicht auftritt. Ich habe sowohl mit unserer Zeitzone als auch mit diversen internationalen Zeitzonen getestet und hatte diesen Effekt nicht. Bitte entferne zunächst das Modul wieder aus deiner Konfiguration und lösche ggf. auch die fhem.save und starte dann FHEM noch einmal neu.

Grüße,
Jens

PS: Du hast um 20:21 CET gepostet. Deine Systemzeit ist zu diesem Zeitpunkt ca. 20:41 CET. Wie geht das?
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

Maista

#19
Hallo Jens,

die fhem.save hab ich gelöscht. Die Zeit ist nun wieder "normal".
Nach dem neu anlegen des Moduls ist die Zeit nun ebenfalls korrekt!

ZitatPS: Du hast um 20:21 CET gepostet. Deine Systemzeit ist zu diesem Zeitpunkt ca. 20:41 CET. Wie geht das?
Vermutlich weil ich die Nachricht in der Zeit mehrfach geändert hatte ;)

Ich kann Dir auch mal die fhem.save mit dem Problem und die neu erzeugte zu kommen lassen.
Beim vergleichen mit Totalcommander ist mir nichts aufgefallen.

Ich bin mir nun nicht mehr sicher ob FHEM tatsächlich beendet wurde als ich das in der Shell gestoppt hatte.
Es liefen zwei FHEM Tasks... :o

Mittlerweile bekomme ich auch eine Ausgabe bei { $ENV{TZ} } !

Aber irgend was zickt nun rum....Melde mich wieder.

Danke erst mal.

Laufen wieder zwei Perl-FHEM...

Ist das Normal das mehr als ein Task von FHEM im Prozessstatus zu sehen ist?

Starte den PI komplett neu.

Gruss Gerd

JoWiemann

Hallo Jens,

anbei ein Vorschlag für die Umsetzung mit nonBlockingCall.

Grüße Jörg

Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

jensb

Hallo Gerd,

freut mich, dass du wieder Normalzeit hast. Kann in meiner eigenen fhem.save auch nichts zu den Zeitzoneneinstellungen finden. Damit bleibt leider unklar, was hier dauerhaft an der Uhr dreht.

ZitatIst das Normal das mehr als ein Task von FHEM im Prozessstatus zu sehen ist?
Im einfachsten Fall läuft nur ein FHEM Perl Prozess. Aber je nach aktiven Modulen kann der Hauptprozess kurzzeitig oder dauerhaft forken und dann laufen u.U. (kurzzeitig oder dauerhaft) mehrere Prozesse.

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

Maista

Danke Jens,

hatte mich doch etwas gewundert. In den Anfängen liefen zwei Prozesse. Das hatte ich dann aber
gefunden.

Komisch ist nur, das ich diese nicht per Stop in der Shell beendet bekommen.

Nur KILL oder Shutdown in FHEM wirkt.

Nun ist schon wieder spät.

DWD lasse ich so mal laufen. Dann schaue ich was ich damit machen kann  ;)

Gruss Gerd

jensb

Hallo Jörg,

prima, dass du dir inzwischen selbst helfen konntest und es so funktioniert :D Werde mir deinen Vorschlag im laufe der Woche ansehen und dann integrieren.

Non-Blocking stand bei mir auch noch auf dem Plan. Allerdings bin ich mir nicht sicher, wieviel das bei der Vorhersage bringt. Zumindest bei großen Datenmengen ist die Performace nicht so toll (Beispiel: das alte GDS-Modul hat nach der Umstellung auf Non-Blocking FHEM trotzdem regelmäßig 5 bis 10 Sekunden blockiert) und bei kleinen Datenmengen ist der Overhead durch das Forken relativ groß. Wenn der HTTP-Get allerdings hängen bleibt oder kriecht, hilft es natürlich - insofern ist Non-Blocking immer vorzuziehen.

Wie es klingt hattest du keine Probleme mit der Zeitzone und der FHEM-Zeit. Würde zu gern verstehen, wo dieser Effekt herkommt. Es könnte sein, dass einige FHEM-Installationen ohne TZ-Umgebungsvariable arbeiten und für FHEM die Systemzeit verwenden (die von init - nicht die von root oder pi), wobei die Systemzeit bei diesen Systemen wahrscheinlich als Zeitzone GMT hat. Wenn man dann die Systemuhr so einstellt, dass sie wie CET aussieht, aber die Zeitzone auf GMT lässt, gibt es natürlich durcheinander, sobald man TZ zum ersten Mal setzt. Dagegen sollte der unten erwähnte Vorschlag mit dem Setzen von TZ im Startskript helfen. Vielleicht muss ich aber auch noch die Fälle unterscheiden A) TZ nicht gesetzt (keine TZ-Umgebungsvariable vorhanden) und B) TZ nicht definiert (es gibt eine TZ-Umgebungsvariable, aber ohne Wert).

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

JoWiemann

Hallo Jens,

habe das mal mit dem neuen Modul 98_FREEZEMON getestet. Ohne nonBlocking zwischen 3 und 4 Sekunden. Bei Fhem Instanzen mit vielen Aktoren / Sensoren schon sehr viel. Mit nonBlocking völlig unauffällig.

Bei mir spielt es keine Rolle, da ich fast alle Module, die Daten aus dem I-Net holen, auf einer zweiten Fhem-Instanz laufen lassen, die sich über Fhem2Fhem die Daten der Aktoren / Sensoren holt. Allerdings könnten die DWD Daten ja doch noch für die Hauptinstanz interessant sein.

Grüße Jörg

PS: Gibt es eigentlich so etwas wie einen Aktualisierungszeitstempel vom DWD. Dann bräuchte man die Daten nicht immer komplett holen.
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

jensb

Hallo Jörg,

ZitatGibt es eigentlich so etwas wie einen Aktualisierungszeitstempel vom DWD. Dann bräuchte man die Daten nicht immer komplett holen.
Das hatte ich mir auch schon angesehen. Da ich den HTTP-Get mit LWP::Simple realisert hatte, gab es kein Zugriff auf den Modified-Zeitstempel vom Server. Ob die HttpUtils einen Zugriff ermöglichen werde ich mir noch ansehen. In den Daten ist auch noch ein Zeitstempel und der wird ja als Reading geliefert (fc_date). Allerdings ändert sich der Datenumfang trotzdem. Wenn ich das richtig sehe, macht der DWD alle 12 Stunden eine neue Vorhersage. Die Daten innerhalb des Dokuments werden aber mit der Zeit ständig weiter rotiert, so dass inzwischen vergangene Zeiten entfallen und durch zukünftige ersetzt werden. Daher habe ich eine stündliche Abfrage eingebaut - damit bleibt man aktuell.

ZitatOhne nonBlocking zwischen 3 und 4 Sekunden
Das ist relativ viel. Kein Wunder, dass du sofort auf Non-Blocking kommst. Wie gesagt, bei mir im Normalfall um 500 ms. Wo der Unterschied herkommt, kann ich nicht sagen, aber Non-Blocking werde ich trotzdem einbauen.

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

JoWiemann

Hallo Jens,

ich habe halt nur eine 10.000 Datenleitung. Wenn da Streaming und Spiele laufen, bzw. telefoniert wird, ist halt etwas zäh.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

JoWiemann

Hallo Jens,

es sieht so aus, dass die Verzeichnisse auch Datum / Uhrzeit aktualisieren. Damit würde es ausreichen https://opendata.dwd.de/weather/local_forecasts/ zu holen und den Zeitstempel für das Verzeichnis poi zu prüfen.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

jensb

Hallo Jörg,

mit LWP::UserAgent kommt am an "last_modified" eines Objekts, sofern auf dem Server gesetzt. Wie man das mit HttpUtils macht, habe ich noch nicht herausgefunden. Hast du eine Idee?

Ich möchte vermeiden, die Daten mit 2 verschiedenen Techniken (HttpUtils + LWP) abzufragen, damit man nicht z.B. den  Proxy mehrfach auf unterschiedliche Weise einstellen muss. Vielleicht hat schon mal jemand irgendwo in FHEM Webserver-Zeitstempel abgefragt - werde mit mal umsehen.

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

JoWiemann

Hm, Du könntest nur den Header mit der HEAD Methode anfordern und auswerten. Oder der GET Methode über setzen vom Header-Feld "Conditional" auf If-Modified-Since den letzten Zeitstempel übergeben.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM