55_GDS.pm - komplett überarbeitet - RC1

[HeikoE]

Hallo betateilchen,

ich nutze GDS schon seit über einem Jahr. Ein Punkt hat mir gefehlt, den ich selbst eingebaut habe:
Der Zeitpunkt zu dem der DWD die Wetterdaten abgelegt hat.
Oft vergehen 30min bis man die Daten sieht. (Aktualisierung der Daten + 20min Abfrageintervall)
In der Conditions-Datei steht die Uhrzeit oben, z.B.

Code Auswählen Erweitern


Wetterbeobachtungen von Montag, 12.10.2015, 01 Uhr

also hinter dem letzten Komma.
Ich habe ein Reading "DWDTime" hinzugefügt.
Dazu habe ich die SUB "retrieveConditions" um folgende Zeilen erweitert:

Code Auswählen Erweitern


sub retrieveConditions($$@){
...
my ($debug, $dataFile, $found, $line, $item, %pos, %alignment, %wx, %cread, $k, $v, $dwdtime);
...
    if ($line =~ /Wetterbeobachtungen/) {
      $dwdtime = substr($line,rindex($line,",")+2,6);
    }
...
    $cread{$prefix."_DWDTime"} = $dwdtime;
...

Vieleicht könntest Du das in die neue Version mit einbauen.

Gruß
HeikoE

[betateilchen]

Ich weiss zwar nicht, wozu man diese Information tatsächlich braucht, aber wenn ich das einbauen sollte, dann werde ich das richtig machen und nich so hingepfuscht.

Die wirklich korrekte Uhrzeit steckt nämlich woanders:


SXDL99 DWAV 132214
Wetterbeobachtungen von Mittwoch, 14.10.2015, 00 Uhr

  13 = Datum (13.10.2015)
2214 = Ausgabezeitpunkt (in UTC, also am 14.10.2105 um 00:14 Uhr MESZ)


Solche Informationen stehen schon seit langem in den _dF-Readings, die man sieht, wenn man das Attribut gdsDebug auf 1 stellt.

(http://up.picr.de/23398178kv.png)

[HeikoE]

Na ja, dass mein Codeschnipsel Optimierungsmöglichkeiten bietet, streite ich nicht ab. Ist beim machen so geworden. Meine Perl-Kentnisse sind nicht gerade super. Ich kopiere mir alles so zusammen.
Für meine Bedürfnisse ist es OK.
Wozu man das braucht: ich zeige Luftdruck, Temperatur und den Lagetext auf einem HM-Dis-WM55 an und wenn ich um 6:15h draufschaue, ist es schon interessant ob die Daten von 5h oder von 6h sind. Da wollte ich die Zeit nämlich sehen.

[betateilchen]

Meine Perl-Kentnisse sind nicht gerade super.

Dagegen kann man ja was tun Hier ein sehr ausführliches Beispiel - mit Erklärungen - wie Du aus den vorhandenen Readings im gds Device die Ausgabezeit der letzten Lagemeldung erzeugen kannst.

Code Auswählen Erweitern


sub ausgabezeit() {
my $t = ReadingsVal(<name>,'_df_conditions','0000'); # reading lesen
my $o = (ReadingsVal(<name>,'_tzOffset',0)/36);  # offset ermitteln
   $t = substr($t,length($t)-4,4);               # letzte vier Stellen ermitteln
   $t = $t + $o;                                 # offset addieren, ergibt im Beispiel 2214 + 200 = 2414
   $t = $t % 2400;                               # modulo 2400, ergibt im Beispiel = 14
   $t = sprintf ("%04d",$t);                     # führende Nullen auffüllen, ergibt im Beispiel 0014
   $t = substr($t,0,2).":".substr($t,2,2);       # jetzt bauen wir noch einen Doppelpunkt ein
return $t;
}


[Kuzl]

Bezüglich der einträge im logfile:

Code Auswählen Erweitern


2015.10.15 10:20:02.999 3: get GDS rereadcfg; get GDS radarmap Suedost; get GDS alerts 109189000 : Keine Warnmeldung für die gesuchte Region vorhanden.
2015.10.15 11:20:01.974 3: get GDS rereadcfg; get GDS radarmap Suedost; get GDS alerts 109189000 : Keine Warnmeldung für die gesuchte Region vorhanden.
2015.10.15 12:20:02.346 3: get GDS rereadcfg; get GDS radarmap Suedost; get GDS alerts 109189000 : Keine Warnmeldung für die gesuchte Region vorhanden.
2015.10.15 13:20:01.913 3: get GDS rereadcfg; get GDS radarmap Suedost; get GDS alerts 109189000 : Keine Warnmeldung für die gesuchte Region vorhanden.


verbose für das at ist bereits auf 0 gestellt. Es steht aber auch kein Verboselevel vor der Meldung.

[betateilchen]

verbose für das at ist bereits auf 0 gestellt. Es steht aber auch kein Verboselevel vor der Meldung.

Blödsinn...

2015.10.15 13:20:01.913 3: get GDS rereadcfg; get GDS radarmap Suedost; get GDS alerts 109189000 : Keine Warnmeldung für die gesuchte Region vorhanden.

[Kuzl]

oh stimmt hab ich übersehen. Aber warum kommt das durch, obwohl ich bei dem AT verbose 0 hab?

[betateilchen]

Ich kann leider nicht hellsehen und kenne Deine Konfiguration nicht. Deshalb kann ich Dir auch nicht sagen, welches der an diesem Vorgang beteiligten Devices im verbose 3 läuft und deshalb diese Meldung loggt.

[HeikoE]

Dagegen kann man ja was tun Hier ein sehr ausführliches Beispiel - mit Erklärungen - wie Du aus den vorhandenen Readings im gds Device die Ausgabezeit der letzten Lagemeldung erzeugen kannst.

Danke. Werde es mal ausprobieren.

[jensb]

@betateilchen

Habe gerade den RC2 bei mir eingespielt und die neue Version hat nach einem "reload 55_GDS" sofort und ohne Konfigurationsänderungen funktioniert .

Hier zwei Punkte, die mir aufgefallen sind:

• Im Logfile steht bei mir nach einem Neustart von FHEM 7mal hintereinander in der gleichen Sekunde

  1: Timeout for _retrieveFile reached, terminated process nnnn

  danach aber nicht noch einmal. Das kommt wohl von BlockingKill und könnte damit zusammen hängen, das zumindest bei mir der Start von FHEM etwas mehr als 1 Minute benötigt und daher die ersten Aufrufe von retrieveFile, die z.B. vom GDS_Define angestoßen werden, nicht abgearbeitet werden können und auf das Timeout laufen. Das Timeout weiter hoch zu setzen ist wohl nicht die richtige Lösung, aber vielleicht macht es Sinn, das ganze mit $init_done zu verriegeln, z.B. über einen Timer, der im GDS_Define gestart wird und erst bei $init_done die Initialisierungsschritte durchführt, die von retrieveFile abhängig sind.


• In der sub retrieveForecasts hatte ich die Strategie "skip update if no valid data is available" verwendet. Im RC2 hast du dich für "delete reading if no valid data is available" entschieden. Natürlich ist eine Vorhersage für heute um 06:00 ab 07:00 nicht mehr relevant und kann daher gelöscht werden. Bei statischen Abfragen auf die Readings, z.B. in einem DOIF, bekommt man dann aber Loggings wie "2: DDDD: reading does not exist: [GDS:fc0_weather06]", was man wiederum mit einer zusätzlichen Abfrage im DOIF unterbinden kann. Im Endeffekt ist das Geschmackssache, wollte es nur erwähnen.

[jensb]

@Kuzl

Bei mir hat es gereicht, im at verbose=2 einzustellen, um die Logausgaben loszuwerden. Warum bei dir verbose=0 nicht funktioniert kann ich nicht erklären. at verwendet hier zum Loggen die Funktion Log3 mit Loglevel 3 und Log3 loggt nicht, wenn die Meldung einen größeren Loglevel hat als das Device.

[betateilchen]

@betateilchen

Habe gerade den RC2 bei mir eingespielt und die neue Version hat nach einem "reload 55_GDS" sofort und ohne Konfigurationsänderungen funktioniert .

Vergiß RC2

Das Modul 55_GDS.pm ist quasi komplett neugeschrieben und hat mit dem RC2 nicht mehr viel gemeinsam. In RC2 waren die Grundzüge von nonblocking getestet, mehr oder weniger eine "Lernvariante" für mich selbst. Die Erkenntnisse habe ich dann in der Version, die bei mir grade in Arbeit ist, einfließen lassen.

Trotzdem danke für die Rückmeldung.

[betateilchen]

So... wieder ein Stück weiter.

In contrib/GDS/ habe ich gerade RC3 des überarbeiteten Moduls 55_GDS.pm eingecheckt. Wer testen möchte - nur zu

Achtung!

• Das Modul benötigt das zusätzliche perl Modul Archive::Extract
• Die Nutzung der Wetterwarnungen und der Vorhersagen ist default abgeschaltet. Diese Funktionen müssen mit den Attributen gdsUseAlerts und gdsUseForecasts aktiviert werden.

Bekannte Probleme:

• Manchmal scheitert das Entpacken des Archivs mit den Wetterwarnungen - Ursache bisher unklar, wird weiter beobachtet
• Wenn für eine Region mehrere Wetterwarnungen gleichzeitig existieren, funktioniert die Datenaufbereitung noch nicht korrekt und es werden teilweise falsche Regionen mit angezeigt. An diesem Problem arbeite ich noch.

-

[Kuzl]

Sehr eigenartig das Ganze:

Code Auswählen Erweitern

2015.10.24 21:16:03.804 3: get GDS rereadcfg; get GDS radarmap Suedost; get GDS alerts 109189000 : Keine Warnmeldung für die gesuchte Region vorhanden.

Hier die listings von dem Device GDS und dem beteiligten AT.

Code Auswählen Erweitern

Internals:
   DEF        **** ****
   LOCAL      1
   NAME       GDS
   NR         401
   STATE      active
   TYPE       GDS
   Readings:
     2015-10-24 21:16:03   _dataSource     Quelle: Deutscher Wetterdienst
     2015-10-24 21:16:03   _tzOffset       7200
     2015-10-24 21:16:03   state           active
   Helper:
     INTERVAL   1200
     PASS       ****
     URL        ftp-outgoing2.dwd.de
     USER       ****
Attributes:
   gdsLong    1
   gdsPassiveFtp 1
   verbose    0

Code Auswählen Erweitern

Internals:
   COMMAND    {fhem("get GDS rereadcfg; get GDS radarmap Suedost; get GDS alerts 109189000");}
   DEF        +*01:00 {fhem("get GDS rereadcfg; get GDS radarmap Suedost; get GDS alerts 109189000");}
   NAME       GDSupdate
   NR         389
   NTM        22:15:49
   PERIODIC   yes
   RELATIVE   yes
   REP        -1
   STATE      Next: 22:15:49
   TIMESPEC   01:00
   TRIGGERTIME 1445717749.00918
   TRIGGERTIME_FMT 2015-10-24 22:15:49
   TYPE       at
   Readings:
     2015-10-24 21:16:03   state           Next: 22:15:49
Attributes:
   verbose    2

ich habs jetzt auch mal auf verbose 2 gestellt, hat auch nix gebracht.
Noch jemand ne Idee?

[betateilchen]

Noch jemand ne Idee?

Probiers mal so: (Und lass mal die Karten aussen vor)

Code Auswählen Erweitern



define at_read_GDS at +*00:10:00 get GDS rereadcfg

define n_check_GDS notify GDS:REREADALERTS get GDS alerts 109189000



Für die Region 109189000 gibt es bei mir übrigens aktuell keine Warnmeldungen.