Modul für DWD Open Data

jensb · 28 April 2018, 10:10:32

@fini
Vermutlich hast du mehr geändert als du wolltest. Prüfe ob

use DWDODweblink;

oben in deiner "99_myUtils.pm" steht.

Grüße,
Jens

fini · 28 April 2018, 13:37:59

Zitat von: jensb am 28 April 2018, 10:10:32
@fini
Vermutlich hast du mehr geändert als du wolltest. Prüfe ob

Code Auswählen Erweitern
use DWDODweblink;

oben in deiner "99_myUtils.pm" steht.

dat war es, eigentlich hatte ich dat eingetragen.
immer wenn ich ein update von fhem mache, ist der eintrag wieder weg.
kann man das verhindern?

jensb · 28 April 2018, 13:46:27

@fini

Zitatimmer wenn ich ein update von fhem mache, ist der eintrag wieder weg.
kann man das verhindern?

Das kommt darauf an. Wenn du den Eintrag wirklich in "99_myUtils.pm" machst, dann bleibt das auch so, wenn du ein FHEM Update durchführst. Vermutlich hast du aber den Eintrag in "99_Utils.pm" gemacht. Das wäre nicht das Gleiche und führt dazu, dass der Eintrag mit jedem Update verloren geht.

Grüße,
Jens

Tsturm · 05 Mai 2018, 17:19:16

Hi Jens,

Ich würde gerne wissen, ob mein Verständnis von "fc1_ev" - Evaporation richtig ist:

Definition:
- (ev [kg/m2] - evapotranspiration of previous 24 hours)
Das sollte die heutige Verdunstung sein (da Vorhersage von morgen der vorherigen 24 std).

Wie wird Regen berücksichtigt?
- Gar nicht (wenns Regnet, verdunstet nix, danach wieder)

Um die Gesamtänderung der Wassermenge im Boden zu schätzen:
Niederschlag - Verdunstung
also
fc1_1_RR24 - fc1_ev

Habe ich das richtig? Habe leider keine Beschreibung beim DWD gefunden, um das zu verifizieren - insbesondere nicht die genaue Definition von Evaporation (ich denke, dass das mit einer definierten Pflanzenoberfläche errechnet wird - wie in den anderen Agrarwerten vom DWD).

Hintergrund - das scheint der solideste Ansatz für die Bewässerungssteuerung zu sein. Man kann dann alle Klimmzüge mit Regen, Temperatur etc. ersetzen, weil es die Nettoveränderung des Bodenwasservorrates liefert.

VG Timmo

jensb · 05 Mai 2018, 20:54:51

Hallo Timmo,

deine Frage zur Spezifikation der Evaporistion des DWD kann ich nicht beantworten - meine Infos sind da genauso gut wie deine.

Zum Zeitbezug ist noch folgendes zu berücksichtigen: Die letzten 24 Stunden sind auf den Meldezeitpunkt des DWD zu beziehen. Den findet man heraus, indem man seine Vorhersagedatei vom DWD herunter lädt (dem Link aus der Modulhilfe folgen) und öffnet. Dann sucht man die 1. Zeile mit einem gültigen Wert für die interessierende Größe und findet in der 2. Spalte die die Bezugszeit in UTC. Bei mir ist das für ev z.B. 06:00 UTC. Damit ergibt sich ein Bezugszeitraum vom Vortag 06:00 bis heute 06:00.

RR24 ist offiziell in [mm], wobei man besser [l/qm] ansetzen sollte
ev ist in [kg/qm]

Wenn man also annimmt, dass sich ev nur auf Wasser bezieht, das aus dem Boden verdunstet und dass Wasser etwa 1kg/l wiegt, dann liegst du mit deiner Formel richtig, insbesondere wenn du RR24 auch von 06:00 UTC verwendest. Die Wirklichkeit ist aber meist komplizierter. Trotzdem würde ich das mal ausprobieren und beobachten, was du für Bewässerungsvorschläge bekommst.

Grüße,
Jens

Tsturm · 08 Mai 2018, 21:23:01

Hi Jens,

mache ich - der DWD zeichnet sich ja nicht durch Übersichtlichkeit aus, vielen Dank für Deine Arbeit, das dennoch hinzubekommen.

Das mit dem Zeitpunkt ist ein guter Hinweis, werde ich noch einbauen.

VG Timmo

jensb · 09 Mai 2018, 22:31:40

Im 1. Post findest sich eine aktualisierte Version des Moduls 55_DWD_OpenData.pm. Nachdem es in den letzten Wochen immer wieder mal zu Zeiten ohne Wetterwarnungen gekommen ist, konnte ich diesen Sonderfall testen und korrekt implementieren.

Die bisherige Version hat den State in diesem Fall bei "updating alerts cache" stehen gelassen, die neue Version ändert den State wieder auf "alerts cache updated". An der Funktion des Moduls und den Daten ändert sich dadurch nichts. Das neue Internal "ALERTS_IN_CACHE" gibt an, wieviele Wetterwarnung insgesamt im Cache sind.

Grüße,
Jens

jensb · 10 Mai 2018, 23:28:39

Auf mehrfachen Wunsch gibt es in der FHEMWiki nun einen Artikel zur Installation des Moduls DWD_OpenData und des Weblinks.

Wer im Artikel Fehler findet oder konkrete Änderungen oder Zusätze hat, kann sie entweder direkt einarbeiten oder hier posten.

Außerdem wird ab morgen das Modul 55_DWD_OpenData über FHEM Update abrufbar sein.

Grüße,
Jens

MadMax-FHEM · 11 Mai 2018, 00:25:59

Hi Jens,

ich habe seit kurzem einen MagicMirror wo es ein Plugin/Modul für DWD gibt...
...daher habe ich mich auf die Suche in fhem gemacht: und bin hierauf gestoßen!

Vielen Dank schon mal!

Eben installiert und ausprobiert: funktioniert (wenn man mal die forecast und alert ID etc. hat

)!

Ich habe die DWDODweblink.pm als 99_DWDODweblink.pm nach /opt/fhem/FHEM kopiert (Rechte angepasst: sudo chown fhem:dialout 99_DWDODweblink.pm) und dann noch folgendes ergänzt (zu Beginn nach den ganzen 'use'):

Code Auswählen


sub
DWDODweblink_Initialize($$)
{
 my ($hash) = @_;
}

Dadurch spart man sich den Eintrag in der myUtil und das "Modul" wird automatisch geladen...
...ansonsten sollte es keinen Unterschied zu dem im Wiki beschriebenen Vorgehen machen (denke ich).

Allerdings musste ich zusätzlich folgendes installieren:

Code Auswählen

sudo apt-get install libdatetime-perl

So, dann werde ich mir mal die nächsten Tage anschauen was man da so als Notify etc. und Warnungen per Telegram etc. machen kann

Gruß, Joachim

jensb · 11 Mai 2018, 08:52:28

Hallo Joachim,

freut mich, dass du bei deiner Suche nach dem DWD erfolgreich warst und das DWD-Modul gefunden hast

Deine Anregungen zum Weblink werde ich aufgreifen. Die zusätzliche Sub kann ohne Nebenwirkungen mit in den Code und mit etwas Doku dazu bleibt es jedem überlassen, wie es eingebunden wird.

Der Weblink hat eine zusätzliche Abhängigkeit zum Perl-Modul DateTime. Bei all meinen Systemen war dieses Modul wohl aus anderen Gründen schon installiert, so dass mir das nicht weiter aufgefallen ist. Das kommt dann auch in die Doku und die Wiki.

Danke für die Hinweise und Grüße,
Jens

Rudy · 11 Mai 2018, 17:29:31

Zunächst einmal: Super Modul und danke für die Entwicklung.

Eine Verständnisfrage habe ich jedoch noch. In der commandref heißt es, dass das Attribut "alertArea" aus Performancegründen besser nicht genutzt werden sollte. Unklar ist mir jetzt jedoch ob der Aufruf nur für eine einzige Station mit bspw. "get alterts 111000000" alle 15 Minuten (wie bei alertArea auch) über bspw. ein "at" (+*00:15:00) genauso viel Performance und Traffic kostet. Oder ist das bei dieser Aufrufvariante deutlich geringer, weil sich die Daten nur auf eine Station (statt aller Stationen bei alertArea) beziehen?

jensb · 11 Mai 2018, 20:13:21

Hallo Rudy,

ich vermute du beziehst dich auf

ZitatIt will cause significant download traffic if used in continuous mode (more than 1 GB per day are possible).

Für das Datenvolumen spielt es keine Rolle, ob du "get updateAlertsCache" alle 15 Minuten z.B. durch ein at auslöst oder das Attribut "alertArea" setzt und es dem Modul selbst überlässt. Also verwende einfach die eingebaute Automatik, wenn du nicht hochaktuell sein willst oder mehrere Warnzellen hintereinander abfragen willst. Natürlich gibt es 3mal mehr Datenvolumen, wenn der at den Cache alle 5 Minuten aktualisiert. Entsprechend nimmt der Datenverbrauch auf ein Viertel ab, wenn man nur stündlich aktualisiert.

Das Datenvolumen hängt aber auch stark davon ab, wieviele Wetterwarnungen vom DWD gemeldet werden und das ist halt wetterabhängig, so dass das Tagesdatenvolumen schwankt.

Dagegen spielt es keine Rolle, wie oft man hintereinander "get alerts" aufruft. Solange der Cache nicht älter als 15 Minuten ist, wird aus dem Cache gelesen.

Mir war wichtig, darauf aufmerksam zu machen, dass es eine ganze Menge Daten sein können (aber nicht müssen), damit niemand, der z.B. seine Internetverbindung per Mobilfunk herstellt, unverhofft sein Freivolumen verbraucht hat. Wer eine DSL Flat verwendet, muss sich keine Gedanken machen.

Grüße,
Jens

jensb · 11 Mai 2018, 20:48:03

@MadMax-FHEM
Hallo Joachim,

bist du sicher, dass es ausreichend ist, die Initialize-Sub hinzuzufügen und das Modul in 99_DWDODweblink.pm umzubenennen? Ich wäre davon ausgegangen, dass man dann zumindest noch ein

Code Auswählen

define myWeblink DWDODweblink
benötigt, damit es geladen wird. Denn woher soll FHEM oder Perl sonst wissen, dass diese Modul-Datei gebraucht wird?

Grüße,
Jens

MadMax-FHEM · 11 Mai 2018, 21:16:06

Jaja klar den weblink muss man definieren...

Aber man muss nix in die myUtils eintragen (oder extra eine anlegen, sollte man keine haben)...
Und wenn die DWDODweblink.pm mal nicht geladen werden kann zieht sie halt nicht auch gleich noch die eigene myUtils mit "runter"...

Ist mir ja passiert...

(wegen dem fehlenden Date/Time Modul)

Will man das weblink nicht verwenden, dann braucht man die 99_DWDODweblink.pm ja nicht nach /opt/fhem/FHEM kopieren...

Gruß, Joachim

jensb · 11 Mai 2018, 21:29:28

Hallo Joachim,

danke für die Info. Bin beruhigt, dass das FHEM doch so funktioniert wie ich glaube das verstanden zu haben

Dass FHEM abstürzt, wenn man den Weblink verwendet und das DataTime-Modul fehlt, ist natürlich sehr unschön. Das könnte man aber auch durch einen modifizierten Eintrag in 99_myUtils.pm verhindern:

Code Auswählen

eval "use DWDODweblink;";

Das ist erst mal nur Theorie, habe es noch nicht ausprobiert.

Grüße,
Jens