Im SVN Repository befindet sich im commit #9416 der erste release candidate für das überarbeitete Modul 55_GDS.pm
Diese Datei befindet sich aktuell im Verzeichnis ./contrib/55_GDS.2015 und muss manuell in das Verzeichnis ./FHEM kopiert werden.
Da der DWD aktuell die Datenstrukturen seiner Grundversorgung massiv umbaut, musste ich das Modul ohnehin in Angriff nehmen, um diesen Änderungen gerecht zu werden. Dabei habe ich eine ganze Menge Dinge umgesetzt, die schon lange auf meiner Ideenliste standen.
Ausserdem habe ich die von jensb in diesem Thread (http://forum.fhem.de/index.php/topic,38106.0.html) vorgeschlagenen Erweiterungen für forecasts und weblinks eingebaut.
Wichtige Informationen und vorgenommene Änderungen:
- Das Modul sollte mit RC-Versionen noch nicht in wichtigen Produktivumgebungen verwendet werden.
- Das Modul funktioniert nicht mehr unter Windows.
- Das Modul benötigt keine neuen zusätzlichen perl-Modul gegenüber der bisherigen offiziellen Version.
- Das Modul benutzt ab sofort ausschließlich ftp-Transfers, der LWP::UA wird nicht mehr benötigt.
- Die ftp-Übertragungen arbeiten nun nonblocking.
- Das Modul führt erste Datenaktualisierungen direkt nach dem fhem-Start durch.
- Das Modul kann weblinks analog zum Weather-Modul bereitstellen.
- Das Modul stellt Wettervorhersagen als Text und als Readings bereit.
- Die Version ist nahezu vollständig kompatibel zu bisherigen device-Definitionen. *
- * Ausnahme bei der Kompatibilität: Der Befehl "set <name> rereadcfg" wurde entfernt. Stattdessen kann der auch bisher schon vorhandene Befehl "get <name> rereadcfg" verwendet werden
- Neue Optionen für "set clear ...": conditions,forcasts
Bekannte Bugs / offene Punkte:
- Die Dokumentation ist noch nicht komplett überarbeitet
- Über den Verbleib des html-Generators im Modul habe ich noch nicht endgültig entschieden. Eigentlich halte ich ihn für entbehrlich.
- Für die Funktionsweise der forecast-Aufbereitung sowie des html-Generators bin ich nicht verantwortlich, dafür gibt es von mir keinen Support.
Den Support für die Vorhersage kann ich zur Verfügung stellen. Sollten dabei Codeänderungen am GDS-Modul erforderlich werden, kann ich einen Patch vorbereiten und wir stimmen uns ab.
Soeben wurde RC2 veröffentlicht. Darin enthalten sind folgende Änderungen:
# 2015-10-11 renamed 99_gdsUtils.pm to GDSweblink.pm
# changed load GDSweblink.pm in eval() on module startup
#
# 2015-10-10 added attribute gdsHideFile to hide "GDS File" Menu
# added optional parameter "host" in define() to override default hostname
#
# changed weblink generator moved into 99_gdsUtils.pm
# changed perl module List::MoreUtils is no longer used
# changed perl module Text::CSV is no longer needed
# changed use binary mode for all ftp transfers to preven errors in images
#
# fixed handling for alert items msgType, sent, status
# fixed handling for alert messages without "expires" data
#
# updated commandref documentation
Zitat von: jensb am 11 Oktober 2015, 12:10:45
Sollten dabei Codeänderungen am GDS-Modul erforderlich werden, kann ich einen Patch vorbereiten
Apropos patch... ich hab da mal was vereinfacht :)
sub getListForecastStations($) {
my ($hash) = @_;
my $name = $hash->{NAME};
my @regions = keys(%rmapList);
my @a;
foreach my $region (@regions) {
my $areaAndTime = $region.'_morgen_spaet';
retrieveFile($hash, "forecasts", $areaAndTime, undef,undef);
sleep 1;
my $fileName = $tempDir.$name."_forecasts";
my ($err,@data) = FileRead({FileName=>$fileName,ForceType=>"file" });
return "GDS $name: error reading $fileName" if($err);
splice(@data, 0,2);
splice(@data,-2);
map ( push(@a,"$region/".(split(/\s/,latin1ToUtf8($_),2))[0]), @data);
}
Log3($name, 4, "GDS $name: forecast data not found") unless (!@a);
@a = sort(@a);
$fList = join(",", @a);
$fList =~ s/\s+,/,/g; # replace multiple spaces followed by comma with comma
$fList =~ s/\s/_/g; # replace spaces in stationName with underscore for list in frontend
return;
}
Aber eigentlich könnte man $fList ja auch als "Abfallprodukt" aus dem Lesen der Vorhersagedaten generieren.
Das muss ich mir noch anschauen.
Mit dem ganzen nonblocking-Gedöns bin ich generell noch nicht so ganz glücklich.
Aber es funktioniert derzeit erstmal :)
Die sub getListForecastStations ist nun deutlich kompakter. Es gibt allerdings manchmal Vorhersagedateien ohne Trenner zwischen Stationsname und Temperatur, wobei die Temperatur dann ungültig "---" ist. Bin mir nicht sicher, was der neue Code daraus macht.
Klar, die Stationsliste ist ein Abfallprodukt der Vorhersagedaten, aber für die Stationsiste braucht man alle Regionen für eine beliebigen Zeitpunkt, während man für die Stationsaktualisierung alle Zeitpunkte einer Region benötigt. Lädt man immer alles, dauert der Update deutlich länger.
Um das nonblocking bei der FTP-Übertragung voll ausnutzen zu können, müsste man statt des sleep einen Sekundentimer einstellen und erst mal mit return die Kontolle an FHEM zurück geben. Wenn der Timer auslöst, prüft man, ob der FTP-Transfer fertig ist und arbeitet dann weiter oder wartet nochmal bis zum nächsten Timerevent. Außerdem muss man sich noch merken, womit man weiter machen will, wenn der FTP-Transfer fertig ist (Istwerte, Vorhersagewerte, Warnungen, etc.). FHEM würde dadurch nicht mehr geblockt, aber der Code müsste dafür angepasst werden.
Zitat von: jensb am 11 Oktober 2015, 19:47:29
Die sub getListForecastStations ist nun deutlich kompakter. Es gibt allerdings manchmal Vorhersagedateien ohne Trenner zwischen Stationsname und Temperatur, wobei die Temperatur dann ungültig "---" ist. Bin mir nicht sicher, was der neue Code daraus macht.
Was meinst Du mit "Temperatur ungültig"? Steht dann da "stadtnamexyz---" ohne ein Leerzeichen dazwischen?
Grundsätzlich ist mein Gedankengang, in einem einzigen nb-Funktionsaufruf per FTP die Dateiliste auf dem Server zu lesen und in der gleichen Session alle (ca. 80) Dateien abzuholen und ihren Inhalt in einem Hash zu speichern. Das funktioniert auch soweit, aber ich bekomme den Hash nicht aus der nb-Funktion an die finishFn zurückgegeben.
Aus dem Hash können danach alle für die Vorhersagen benötigten Daten aufbereitet werden, ohne nochmal eine Übertragung starten zu müssen.
Wenn ich das gelöst habe, werde ich das Verfahren auch für die anderen retrieval-Funktionen übernehmen.
ZitatWas meinst Du mit "Temperatur ungültig"? Steht dann da "stadtnamexyz---" ohne ein Leerzeichen dazwischen?
Yep. Du könntest hierfür eine Variante von Zeile 1421 meiner letzten Version
$line =~ s/---/ ---/g; # column distance may drop to zero between station name and invalid temp "---" -> prepend 3 spaces vor dem split einfügen.
Zitat... und ihren Inhalt in einem Hash zu speichern
Habe bei meinen letzten nb-Experimenten so was ähnliches versucht. Von hier aus komme ich aber nicht an den Code, so daß ich nicht nachsehen kann, ob ich da auch einen Hash, ein Array oder einen CSV-String für die Rückmeldung verwendet hatte.
Alternativ könntest du mit dem FTP-Fetch einen temporären Datei-Mirror erstellen und nur eine Fertigmeldung versenden. Dann muss man allerdings die Dateien mit File-IO noch mal laden. Der Hash wäre schon besser.
Die Sache mit dem Hash für alle Forecasts ist nonblocking gelöst. Die Übertragung und Aufbereitung aller 88 aktuellen Dateien in den Hash dauert auf meinem Raspberry ca. 20 Sekunden - im Hintergrund :)
Die Extraktion der Daten aus dem Hash ist nun der nächste Schritt.
Und das mit dem "---" geht auch einfacher. Da nach dieser Logik nach einem Stadtnamen nur ein Leerzeichen oder ein Minuszeichen kommen kann, muss ich ja nur das split-Kriterium anpassen.
88 Dateien in 20 s ist für DWD-Verhältnisse gut, vor allem, wenn es im Hintergrund passiert. Für Alerts, Conditions, Forecasts und ein paar der Karten hat es auf meinem RPi bisher allein schon ca. 15 s gedauert.
Hallo betateilchen,
was hältst du davon, eine Funktionalität einzubauen, die anderen Readings wie alarms, warnings und die maps automatisch zu aktualisieren?
Man spart sich dann das notify (und das Log wird nicht beschrieben wenn keine Meldungen vorliegen)
Intressant wär das ganze evtl in das vorhandene Attribut einzubauen und dann konfigurierbar zu machen, was upgedatet werden soll (der Hash muss ja scheinbar in jedem Fall neu vom Server geholt werden oder?)
Viele Grüße,
Kuzl
Zitat von: Kuzl am 12 Oktober 2015, 13:17:05
was hältst du davon, eine Funktionalität einzubauen, die anderen Readings wie alarms, warnings und die maps automatisch zu aktualisieren?
Nichts - aus verschiedenen Gründen.
Kannst du die mir bitte erläutern?
Ich bin ein Freund von Modulen, die zum Anzeigen von aktuellen Informationen keine notifys/at benötigen.
Aber wenns wirklich nicht vertretbar ist - Könntest du den Returnstring von "get <name> alarm ....." entfernen?
Denn wenn die einzige Möglichkeit von aktuellen Wetterwarnungen über ein at ist, wird der Returnstring dann immer ins Log eingetragen und man hat keine Möglichkeit das abzustellen (zuminderst kenne ich keine).
Erläuterung:
Ein automatisches Aktualisieren der alerts und warnings würde der (meiner) ursprünglichen Aufgabenstellung widersprechen, wegen der ich das Modul vor zweieinhalb Jahren überhaupt geschrieben habe. Bei mir werden sequentiell MEHRERE alerts für unterschiedliche Regionen abgefragt.
Am Rückgabewert von get werde ich nichts ändern. Dein Problem mit dem Log kann ich nicht nachvollziehen, bei mir stehen keinerlei Ergebnisse eines "get <name> alerts <region>" im Log. Du musst eigentlich nur in dem at, das die alerts prüft, den verbose-Level auf 2 stellen.
Okay das ist durchaus ein Argument, aber warum dann nicht einfach ein weiteres Device für eine weitere Region ablegen, so wie es im restlichen FHEM auch gemacht wird?
bei dem AT muss ich nochmal nachschaun, kann sein dass ich das nicht gemacht habe.
Zitat von: Kuzl am 13 Oktober 2015, 07:18:27
aber warum dann nicht einfach ein weiteres Device für eine weitere Region ablegen
Weil ich das aus Performancegründen damals beim Moduldesign anders entschieden habe.
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.
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:
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
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)
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.
Zitat von: HeikoE am 14 Oktober 2015, 18:02:31
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.
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;
}
Bezüglich der einträge im logfile:
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.
Zitat von: Kuzl am 15 Oktober 2015, 16:35:00
verbose für das at ist bereits auf 0 gestellt. Es steht aber auch kein Verboselevel vor der Meldung.
Blödsinn...
Zitat von: Kuzl am 15 Oktober 2015, 16:35:00
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.
oh stimmt hab ich übersehen. Aber warum kommt das durch, obwohl ich bei dem AT verbose 0 hab?
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.
Zitat von: betateilchen am 14 Oktober 2015, 21:18:30
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.
@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
Zitat1: 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.
@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.
Zitat von: jensb am 18 Oktober 2015, 19:33:24
@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.
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.
-
Sehr eigenartig das Ganze:
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.
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
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?
Zitat von: Kuzl am 24 Oktober 2015, 21:21:36
Noch jemand ne Idee?
Probiers mal so: (Und lass mal die Karten aussen vor)
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.
Deine Benutzerdaten (User & Password) solltest Du übrigens besser aus Deinem Listing entfernen.
Und das hier:
Die Nutzung der Wetterwarnungen und der Vorhersagen ist default abgeschaltet. Diese Funktionen müssen mit den Attributen gdsUseAlerts und gdsUseForecasts aktiviert werden.
hast Du geflissentlich auch ignoriert.
Hey betateilchen,
du hast jetzt RC4 in /FHEM statt /contrib eingecheckt!?
Wenn das geplant war, fehlt aber noch "GDSweblink.pm" in /FHEM...
Es war nicht geplant, den RC4 in /FHEM einzuchecken :-[ Danke für den Hinweis, ich werde das zurückdrehen.
Und GDSweblink.pm befindet sich in contrib/GDS und ist für den Betrieb des GDS-Moduls nicht zwingend notwendig.
Unter "Ankündigungen" habe ich das beschrieben.
http://forum.fhem.de/index.php/topic,42887
Ich habe die GDS.pm noch nicht durch irgendwas ersetzt, daher muss ich auch kein attribut setzen. Allerdings wird scheinbar dadurch das notify nicht getriggert.
Stimmt. Den Trigger gibt es nur aus der aktuellen RC-Version des Moduls.
Aber wenn Du diese RC-Version gar nicht benutzt, ist Deine Frage in diesem Thread ohnehin falsch.
Hallo betateilchen,
ich wollte gerade mal, wie in der Vorankündigung angegeben, das libarchive-extract-perl Paket installieren.
Erhalte dabei aber folgende Fehlermeldung:
Zitat
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
E: Paket libarchive-extract-perl kann nicht gefunden werden.
Mein debian (wheezy) habe ich zuvor noch mit apt-get update und apt-get ugrade auf aktuellen Stand gebracht.
Hast du vielleicht eine Idee an was das liegen kann und wie ich das Problem beheben kann?
(Ich wollte mich jetzt nicht unbedingt noch mit cpan rumschlagen müssen.)
Danke!
Gruß Benni.
probier mal libarchive-any-perl
übrigens: Google Suche -> "libarchive-extract-perl wheezy" -> erstes Suchergebnis ;)
Zitat von: betateilchen am 26 Oktober 2015, 20:08:28
probier mal libarchive-any-perl
Hat funktioniert. Danke!
übrigens: gegoogelt hab ich schon, allerdings eher so was wie "apt-get libarchive-extract-perl package not found" :)
Habe gerade den RC5 ausprobiert, doch leider funktioniert er bei mir nicht.
Die Conditions werden beim Neustart mehr als 10mal hintereinander fast im Sekundentakt aktualisiert, sind aber unvollständig, es fehlt z.B. c_weather und c_windGust. Das gleiche passiert bei get rereadcfg.
Die Forecast-Readings _date und _weekday werden mit aktualisiert, allerdings nur einmal, aber auch hier fehlen die Readings _weather, _windGust und die Temperaturen.
Im FHEM-Log finde ich dazu nur, z.T. mehrfach in der gleichen Sekunde
ZitatTimeout for _retrieveFORECAST reached, terminated process nnnnn
Die von Dir beschriebenen Fehler sind nicht aus dem GDS Modul heraus erklärbar.
Auf welcher Plattform läuft Dein fhem?
Edit: schomal verbose=5 probiert? Mir scheint, bei Dir geht etwas mit den ftp Verbindungen schief. Aber auch damit sind nicht alle von Dir beschriebenen Phänomene erklärbar.
Bei mir läuft RC5 aktuell auf 7 verschiedenen fhem Installationen problemlos.
Der Effekt ist wirklich sehr merkwürdig, tritt bei mir aber nur mit der neuen Version des GDS-Mofuls auf, wobei ich die anderen RCs nicht alle getestet hatte. Verwende einen RPi 2.0 mit Rasbian 4.1.7.
Habe insgesamt 2 GDS-Module bei mir konfiguriert, wobei ich das 2. bereits per Attribut disabled habe, doch das hat nichts geändert.
Werde mir das morgen noch genauer ansehen. Vielleich kann ich mit ein paar extra Logs herausfinden, wo es klemmt.
Zitat von: jensb am 26 Oktober 2015, 22:48:50
Habe insgesamt 2 GDS-Module bei mir konfiguriert
welchen Sinn macht das?
Technische Info: ALLE Daten (sowohl Alerts als auch Forecasts) werden im Speicher vorgehalten. Und das pro definierter Instanz. Egal ob diese disabled ist oder nicht.
Wenn Du mehrere Instanzen definierst, wird die Datenbeschaffung z.B. bei einem fhem Neustart mehrfach durchgeführt. Dazu werden mehrere perl Prozesse geforkt, die alle eine ftp Verbindung zum DWD Server aufbauen. Laut Nutzungsbedingungen des GDS sind maximal drei parallele Verbindungen erlaubt, alle weiteren Verbindungen werden abgelehnt, was dazu führt, dass die jeweilige Verbindung in den timeout läuft.
In den Internals siehst Du übrigens die Timestamps der letzten erfolgreichen Datenbeschaffungen.
(http://up.picr.de/23521904xx.png)
Keine der freien DWD-Stationen liegt für mich meteorologisch optimal. Daher habe ich die beiden Besten ausgewählt und zeige die Vorhersagen für beide untereinander an (und bilde mir machmal im Kopf die Mittelwerte :D).
Werde eine aus der Konfig löschen und dann noch mal testen. Danke für die Hinweise.
Das Entfernen des 2. GDS-Devices ändert leider nichts, es bleibt bei den vielen Aktualisierungen.
ZitatGDS_CONDITIONS_READ 1445898361
GDS_FORECAST_ABORTED Mon Oct 26 23:27:23 2015
GDS_REREAD 1445898360
c_weather ist allerdings wieder aufgetaucht. Das scheint daran zu liegen, dass bei meiner Station das Feld für weather manchmal nichts oder "---" enthält und dann das Reading gelöscht wird. Habe übrigens noch keine Möglichkeit gefunden einem DOIF beizubringen, mit solchen optionalen Readings zurecht zu kommen, denn die Perl-Funktion "defined" lässt sich dafür scheinbar nicht verwenden.
Zitat von: jensb am 26 Oktober 2015, 23:18:13
Werde eine aus der Konfig löschen und dann noch mal testen. Danke für die Hinweise.
Ab RC6 wird die Möglichkeit, mehrere gds-Devices zu definieren, komplett unterbunden.
Die eigentliche Philosophie von gds war von Anfang an (und ist bis heute), nur Daten zu beschaffen und bereitzustellen. Und das ganze "batchfähig" - also beispielsweise aus beliebigen Funktionen aus der 99_myUtils.pm. Du könntest also mit zwei "get <> conditions <station1>" die readings befüllen, in ein Array lesen und dann mit "get <> conditions <station2>" die Readings neu befüllen und in Deiner myUtils.pm die Mittelwerte errechnen und weiterverwenden.
So ähnlich arbeite ich mit den alerts: Da ich die alerts für mehrere Regionen brauche, wird jeweils mit "get <> alerts <region>" der entsprechende Datensatz in die readings geschrieben und dann die readings ausserhalb von gds weiterverarbeitet.
Das ist übrigens auch der Grund, warum es für die alerts keine automatische Aktualisierung innerhalb des Moduls gibt.
Zitat von: jensb am 26 Oktober 2015, 23:35:31
Das Entfernen des 2. GDS-Devices ändert leider nichts, es bleibt bei den vielen Aktualisierungen.
Ok, die Conditions wurden gelesen, die Forecasts nicht. Definiere Dir mal ein at im 10-Minuten Rhytmus, das ein "get <> rereadcfg" durchführt und beobachte, ob sich das irgendwann beruhigt.
Zitat von: jensb am 26 Oktober 2015, 22:21:34
Die Forecast-Readings _date und _weekday werden mit aktualisiert, allerdings nur einmal
Das ist inzwischen behoben, da war in RC5 noch ein Tippfehler ( s/AttrVall/AttrVal/; )
man beachte die TimeStamps... Aktualisierungen wie erwünscht :)
(http://up.picr.de/23525605xk.jpg)
(http://up.picr.de/23525606uz.jpg)
(http://up.picr.de/23525607tb.jpg)
(http://up.picr.de/23525608or.jpg)
Habe weiter getestet und inzwischen eine Idee, warum es bei mir nicht funktioniert:
"sub retrieveData" wird bei "get rereadcfg" 3mal hintereinander aufgerufen und damit forkt FHEM jedesmal, so dass u.U. 3 FTP-Verbindungen gleichzeitig aufgebaut werden, wenn der Verbindungsaufbau und der Transfer mehr als Sekundenbruchteile benötigen. Genau das passiert bei mir (vielleicht weil mein RPi nicht so schnell ist), was ein Aufruf von netstat bestätigt (sehe z.T. mehr als 10 gleichzeitige Verbindungen zu 141.38.3.183:21 im Zustand ESTABLISHED) und bei 2 gleichzeitigen Verbindung ist beim DWD ja leider Schluss.
Die einzelnen _retrieveXXXX müsste man untereinander blockieren, so dass immer nur einer aktiv ist und die anderen warten müssen.
Außerdem wird bei mir retrieveData(FORECAST) im Sekundentakt 16mal hintereinander aufgerufen, was u.a. zu den mehrfachen Logs "Timeout for _retrieveFORECAST reached, terminated process nnnnn" führt. Das ist wohl ein Folgefehler, da GDS_FORECAST_READ bei mir nie gesetzt wird und damit über "sub GDS_GetUpdate" immer wieder neu angefordert wird und auch "getConditions" immer wieder aufgerufen wird.
Zitat von: jensb am 27 Oktober 2015, 20:59:24
"sub retrieveData" wird bei "get rereadcfg" 3mal hintereinander aufgerufen und damit forkt FHEM jedesmal, so dass u.U. 3 FTP-Verbindungen gleichzeitig aufgebaut werden,
Das hab ich doch weiter oben schon genau so geschrieben?
Zitat von: jensb am 27 Oktober 2015, 20:59:24
wenn der Verbindungsaufbau und der Transfer mehr als Sekundenbruchteile benötigen.
Das ist eigentlich kein Problem. Bei mir dauert z.B. das retrieveFORECAST über 15 Sekunden (das sind immerhin bis zu 90 Dateien!) und alles läuft problemlos.
Zitat von: jensb am 27 Oktober 2015, 20:59:24
Genau das passiert bei mir (vielleicht weil mein RPi nicht so schnell ist),
Ich entwickle auf einem RaspberryPi Typ A, langsamer gehts kaum...
Zitat von: jensb am 27 Oktober 2015, 20:59:24
was ein Aufruf von netstat bestätigt (sehe z.T. mehr als 10 gleichzeitige Verbindungen zu 141.38.3.183:21 im Zustand ESTABLISHED) und bei 2 gleichzeitigen Verbindung ist beim DWD ja leider Schluss.
Ich glaube nicht, dass bei Dir 10 Verbindungen gleichzeitig aufgebaut werden, ich vermute aus dem Bauch heraus, dass bei Dir die Verbindungen nicht korrekt abgebaut/geschlossen werden.
Zitat von: jensb am 27 Oktober 2015, 20:59:24
Die einzelnen _retrieveXXXX müsste man untereinander blockieren, so dass immer nur einer aktiv ist und die anderen warten müssen.
Nein, muss man nicht. Sonst hätte ich mir den ganzen Aufwand nämlich sparen können.
Sag mal - ganz was Andere: Du arbeitest nicht zufällig mit einer Fritzbox als Internetzugang?
Habe in _retrieveForecast ein Start- und ein Ende-Log eingefügt. Die Starts kommen alle, die Enden nicht. Da hängt also was. Da auch das connected Log nicht kommt, hängt wohl der Verbindungsaufbau.
Habe tatsächlich eine FritzBox. Soll ich mal passives FTP ausprobieren?
Zitat von: jensb am 27 Oktober 2015, 21:38:57
Habe tatsächlich eine FritzBox.
Da haben wir das Problem.
Zitat von: jensb am 27 Oktober 2015, 21:38:57
Soll ich mal passives FTP ausprobieren?
Kannst Du gerne testen. Viel Hoffnung hab ich aber nicht.
Mir ist nicht klar, warum die FritzBox für die neue Modulversion ein Problem ist. Hast du dazu mehr Infos?
ZitatMir ist nicht klar, warum die FritzBox für die neue Modulversion ein Problem ist. Hast du dazu mehr Infos?
Die Fritzbox ist für unzählige Probleme die Ursache. Das kannst Du hier im Forum schon seit Jahren seitenlang nachlesen, das müssen wir hier nicht noch einmal aus dem Urschleim diskutieren. Es ist einfach so.
Falls Du irgendwo die Möglichkeit hast, den Raspberry ohne eine Fritzkotz dazwischen ins Internet zu bringen, teste einfach nochmal.
ZitatFalls Du irgendwo die Möglichkeit hast, den Raspberry ohne eine Fritzkotz dazwischen ins Internet zu bringen, teste einfach nochmal.
Kurzfristig sehe ich da keine Möglichkeit. Mein alter Speedport ist glaube ich auch eine verkappte FritzBox und kann kein VoIP :-\.
Laß uns mal systematisch vorgehen.
- checke morgen den RC6 aus, den ich in Kürze einchecke
- lösche die Attribute gdsUseForecasts und gdsUseAlerts
- setze das Attribut "gdsUseFritzkotz" auf 1
- teste und berichte, ob die Conditions korrekt gelesen werden.
Hat sich wohl gerade wieder überschnitten. Werde das natürlich trotzdem testen. Hier mein aktueller Stand:
Mit passivem FTP klappt die Übertragung und es gibt keine Blocking-Timeouts mehr.
Während der FTP-Transfer läuft (dauert für Conditions, Alerts und Forecasts bei mir ca. 13 Sekunden) werden im Sekundentakt immer wieder neue retrieveData(FORECAST) angestoßen. Könnte man in GDS_GetUpdate verriegeln, wenn man sich in "sub retrieveData" den jeweiligen Start-Zeitstempel als InternelReading merkt.
Vermisse aktuell allerdings noch einzelne Readings (z.B. die Vorhersage von Freitag früh), konnte aber noch nicht herausfinden, ob der DWD die Daten momentan nicht liefert oder ob die Verarbeitung klemmt. Werde das noch untersuchen.
ok, das mit dem passive ftp ist ja schonmal ein guter Schritt.
Auf die Sache mit dem GDS_GetUpdate bin ich inzwischen auch gekommen, da arbeite ich grade dran. Kann also mit dem RC6 noch etwas länger dauern als geplant. Jetzt geh ich erstmal pennen.
Das mit den fehlenden Readings hab ich auch schon bemerkt, aber nach dem zweiten oder dritten automatischen Update sind sie irgendwann vollständig. Ich denke, da kommt es manchmal einfach zu Überschneidungen zwischen dem Download vom Server und einer Aktualisierung auf dem Server.
Wobei Deine Aufbereitung der fc_ readings schon ziemlich haarsträubend und nicht wirklich nachvollziehbar ist 8)
ZitatWobei Deine Aufbereitung der fc_ readings schon ziemlich haarsträubend und nicht wirklich nachvollziehbar ist
Den Hintergrund hatte ich mal im 1. Beitrag zu http://forum.fhem.de/index.php/topic,38106.msg303560.html (http://forum.fhem.de/index.php/topic,38106.msg303560.html) kurz beschrieben:
ZitatDie Dateien für den aktuellen Tag werden abhängig von der Uhrzeit schrittweise durch Leerdateien ersetzt und zum Tageswechsel dauert es fast 1 Stunde, bis Daten für den neuen Tag zur Verfügung stehen. Durch eine Rotation der Vorhersage zum Tageswechsel wird das aber kompensiert.
Die Vorhersagedaten vom DWD sind zwischen 23:00 und 01:00 nicht konsistent verfügbar, daher die unschöne Verschiebungslogik. Was kurz vor Mitternacht für "morgen früh" vorhergesagt wurde sollte auch noch kurz nach Mitternacht für das neue "heute früh" gelten, bis der DWD die aktualisierten Daten liefert, wo dann alles wirklich um einen Tag verschoben ist.
Generell wird eine Vorhersagedatei teilweise bereits knapp 1 Stunde vor ihrem Melde-Bezugszeitpunkt vom DWD nicht mehr gefüllt (also z.B. die für heute Mittag 12:00 bereits kurz nach 11:00 nicht mehr). Das ist für ein Vorhersagemodell, das periodisch rechnet, nicht ungewöhnlich, aber für die Auswertung und Anzeige unpraktisch, da ich ja um 11:30 immer noch eine Vorhersage für 12:00 erwarte, wenn sie doch ein paar Minuten vorher noch da war.
Deshalb u.a. auch mein ursprünglicher Code in "sub retrieveForecasts", der nur bei gültigen Vorhersgedaten die Readings ändert und bei fehlenden Vorhersagedaten nicht löscht:
readingsBeginUpdate($hash);
while (($k, $v) = each %fread) {
# skip update if no valid data is available
if (defined($v) && substr($v, 0, 1) ne '-') {
readingsBulkUpdate($hash, $k, utf8ToLatin1($v));
}
}
readingsEndUpdate($hash, 1);
Damit gleichzeitig das Konzept für den dynamischen Stationswechsel aufgeht, könnte man am Anfang von "sub retrieveForecasts" und vielleicht auch von "sub getConditions" prüfen, ob sich der Stationsname geändert hat. Wenn ja, werden die relevanten Readings gelöscht (wie bei set clear forecasts/conditions), ansonsten wird nur aktualisiert, was neu vom DWD kommt.
Zitat von: jensb am 27 Oktober 2015, 23:31:56
Mit passivem FTP klappt die Übertragung und es gibt keine Blocking-Timeouts mehr.
Ab RC6 verwendet das Modul passive ftp als Standard, es sei denn, der Anwender hat das per Attribut expliizit abgeschaltet.
Zitat von: jensb am 28 Oktober 2015, 22:06:26
Die Vorhersagedaten vom DWD sind zwischen 23:00 und 01:00 nicht konsistent verfügbar, daher die unschöne Verschiebungslogik.
Von der Verschiebungslogik halte ich gar nichts. Meine einfach Philosophie bei solchen Daten ist: Es sollen nur solche readings generiert werden, deren Inhalt sich eindeutig und zweifelsfrei aus gelesenen (und vorhandenen!) Daten ergibt.
Insofern überlege ich gerade, die gesamte Vorhersagelogik aus meinem Modul wieder auszubauen.
Zitat von: jensb am 28 Oktober 2015, 22:06:26
Damit gleichzeitig das Konzept für den dynamischen Stationswechsel aufgeht, könnte man am Anfang von "sub retrieveForecasts" und vielleicht auch von "sub getConditions" prüfen, ob sich der Stationsname geändert hat. Wenn ja, werden die relevanten Readings gelöscht (wie bei set clear forecasts/conditions), ansonsten wird nur aktualisiert, was neu vom DWD kommt.
In irgendeiner Entwicklungsversion hatte ich das bereits umgesetzt, das muss ich nochmal suchen.
ZitatVon der Verschiebungslogik halte ich gar nichts.
Ich eigentlich auch nicht, aber:
- Vorhersagedaten werden vom DWD nicht in Echtzeit aktualisiert, sondern nur getaktet alle Stunde, aber nicht exakt zur vollen Stunde
- Vorhersagedaten für den aktuellen Tag werden schon knapp eine Stunde vor der Bezugszeit der Vorhersage vom DWD nicht mehr zur Verfügung gestellt
- das GDS-Modul pollt asynchron zum DWD-Takt
- um Mitternacht ändert sich der relative Tag
Damit hat man mehrere langsame asynchrone Abläufe für Daten, die sich i.a. nur sehr langsam ändern. Eine Halten der Vorhersagedaten bis zum Ablauf ihrer nominellen Gültigkeit ist ohnehin unkritisch und kompensiert nur die Eigenheiten der Datenquelle. Bei Warnungen wäre das etwas anderes, da kann sich ja jederzeit etwas ändern.
Das Verschieben zwischen den Readings (z.B. von fc1 nach fc0) beim Tageswechsel interpretiert die Daten nicht neu und macht sie auch nicht länger gültig, sondern ordnet sie nur dem richtigen relativen Tag zu, der sich hier unabhängig von den Quelldaten ändert. Damit wird die Auswertung (z.B. per Notify) erleichtert, da man sonst immer wieder vorübergehend mit nicht definierten Readings zu tun hat. Die Alternative, synchron um Mitternacht noch einmal den DWD zu pollen, hatte ich erwogen, doch einige Vorhersagen liegen z.T. erst deutlich nach Mitternacht wieder gültig vor.
Über ein Attribut könnte man das Meldeverhalten für die Vorhersage umschalten. Im einen Fall werden die Readings so befüllt, wie sie zuletzt gepollt wurden, im anderen Fall so, wie das derzeit erfolgt.
Habe die neue Version 9747 des GDS-Moduls bzgl. der Vorhersagefunktionen getestet und einen Patch erstellt, der vor allem die bereits erwähnte mehrfache parallele Abfrage der Vorhersagen unterdrückt.
Besonders merkwürdig war, das auch nach dieser Anpassung die Readings für die Vorhersage bei mir nicht vollständig waren, obwohl sie als Dateien empfangen wurden. Die Suche-Schleife über den Hash 'allForecastData' der Vorhersagedaten in der Zeile 1774 hat bei mir einfach nicht die vorhandenen 87 Einträge durchlaufen, sondern ist nach ein paar Einträgen einfach fertig gewesen, z.T. ohne den vorhandenen Eintrag zu finden. Zum Debuggen hatte ich Loggings eingefügt und u.a. auch die Hash-Größe ausgegeben. Dabei hat die vorherige Ermittlung der Hash-Größe in Zeile 1773 dazu geführt, dass nun immer alle Elemente überprüft werden und die Vorhersage-Readings damit auch bei mir vollständig sind. Da bei mir ansonsten alles so funktioniert wie erwartet, gehe ich nicht davon aus, dass meine Perl-Installation buggy ist aber was gibt es dafür noch für eine Erklärung?
Schick mir solche patches bitte demnächst per email, wir schaffen sonst hier ein absolutes Versionschaos, wenn Du hier komplette Module anhängst.
Deine Änderungen habe ich eingebaut, danke.
ZitatSchick mir solche patches bitte demnächst per email, wir schaffen sonst hier ein absolutes Versionschaos, wenn Du hier komplette Module anhängst.
Geht in Ordnung, es ist sonst nicht ganz klar was "offiziell" ist.
Damit die manchmal fehlenden c_weather Readings nicht mehr zu hässlichen Darstellungen führen, bereite ich auch noch eine Änderung an GDSweblink vor, die ich selbst nach contrib committen würde, sobald sie getestet ist.
Habe heute abend mal nach dem Update die neue version von 55_GDS eingebunden und die Version funktioniert bei mir auch soweit. (maps werden geholt, Forecasts in den Readings abgelegt, etc). Also erstmal danke für die Umstellung!
Dabei hat es allerdings (bei mir) eine paar Auffälligkeiten/Fragen gegeben:
1) Ich bekomme momentan nach Neustart immer folgende Meldung:
2015.11.01 23:26:10 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/55_GDS.pm line 661.
Internal GDS_REREAD ist allerdings bei mir gesetzt?
2) Nach einem rereadcfg als FHEM Befehl (nicht GDS) kamen folgende Meldungen:
2015.11.01 23:23:26 1: PERL WARNING: Deep recursion on subroutine "main::GDS_GetUpdate" at fhem.pl line 2725.
2015.11.01 23:23:26 1: PERL WARNING: Deep recursion on subroutine "main::InternalTimer" at FHEM/Blocking.pm line 79.
2015.11.01 23:23:26 1: PERL WARNING: Deep recursion on subroutine "main::InternalTimer" at ./FHEM/55_GDS.pm line 682.
. Ich musste danach den perl prozess abschiessen um den Server neustartetn zu können.
3) Ausserdem ist mir nicht klar, welche Werte bei gdsSetCond und gdsSetForecast eintragen kann, denn es gibt ja unterschiedliche Auswahlen für Statiosnamen/Regionen.
4) Ebenso ist mir die Funktion von gdsUseForecasts nicht klargeworden?
Danke für Eure Hilfe,
Johannes
zu 3 + 4)
Der DWD teilt Messstationen und Vorhersagestationen unterschiedlich ein und benennt sie auch z.T. leicht unterschiedlich, obwohl es für den Anwender meist keinen relevanten Unterschied gibt. Also nicht daran stören und einfach zweimal wählen.
Mit gdsUseForecasts=1 wird die Vorhersagefunktion im GDS-Device aktiviert. Danach "get rereadcfg" aufrufen, um u.a. die Vorhersage-Stationslisten zu bekommen. Jetzt kann man über "set forecasts" die gewünschte Vorhersagestation aus der Liste auswählen und dauerhaft einstellen (einige Vorhersagestationen stehen sogar in mehrere Regionen zur Verfügung). Für "set conditions" geht man schon immer so vor.
Hi jensb,
Danke für die schnelle Beantwortung!
Also ist der Ablauf (wenn interaktiv):
a) gdsUseForecasts auf 1 setzen
b) get rereadcfg
c) Web oberfläche reload, damit die Auswahllisten aktualisiert werden
d) set forecast entsprechend einstellen
und die Attribute müssen gar nicht manuell gesetzt werden? => Das wäre vielleicht auch etwas für die Doku
Wenn ich schonmal dabeibin dumme Fragen zu stellen: werden bei set forecasts auch die forecastmaps automatisch geholt?
Johannes
Hallo Johannes,
ja, wenn man FHEMWEB zur Konfiguration benutzt, muss man gdsSetCond/Forcast nich unbedingt manuell einstellen, was die Sache vereinfacht.
Zitat... werden bei set forecasts auch die forecastmaps automatisch geholt?
Nein, das ist wieder ein anderer "Datentopf", den man - wie in der Wiki beschrieben - am besten per "at" abfragt.
LG, Jens
Hallo in die Runde.
Ich habe gestern per Update auf die neue (umgebaute) Version umgestellt. Nun gibt es bei mir folgendes Phänomen.
Aktuell gibt es für meine Region/Stadt eine Warnmeldung, welche mir manuell über die Fhem-Oberfläche abgerufen auch als Reading abgelegt wird.
Rufe ich jedoch über die Warncell-ID ab, laufen bei mir auch andere Readings aus anderen Regionen auf und es kommen immer mehr Ort/Meldungen dazu.
Folgende Definitionen:
define dwd_alerts GDS User Passwort
attr dwd_alerts gdsLong 1
attr dwd_alerts gdsSetCond Brocken
attr dwd_alerts gdsUseAlerts 1
attr dwd_alerts group Wetter
attr dwd_alerts room System
define dwd_get_data at +*00:30:00 get dwd_alerts rereadcfg
attr dwd_get_data alignTime 00:00:30
attr dwd_get_data group Wetter
attr dwd_get_data room System
define dwd_read_data at +*00:30:00 get dwd_alerts alerts 103156000
attr dwd_read_data alignTime 00:05:30
attr dwd_read_data group Wetter
attr dwd_read_data room System
Internals:
CFGFN /opt/fhem/FHEM/wetter.cfg
DEF User Passwort
GDS_CAPDATA_READ 1446448240
GDS_CONDITIONS_READ 1446448230
GDS_REREAD 1446448230
NAME dwd_alerts
NR 173
NTFY_ORDER 50-dwd_alerts
STATE active
TYPE GDS
Readings:
2015-11-02 08:10:40 _dF_alerts Z_CAP_C_EDZW_20151102070651_PVW_STATUS.zip
2015-11-02 08:10:30 _dF_conditions SXDL99_DWAV_20151102_0645
2015-11-02 08:15:30 _dataSource Quelle: Deutscher Wetterdienst
2015-11-02 08:14:09 _nextUpdate Mon Nov 2 08:34:09 2015
2015-11-02 08:15:30 a_0_areaDesc Kreis Osterode am Harz
2015-11-02 08:15:30 a_0_category Met
2015-11-02 08:15:30 a_0_certainty Observed
2015-11-02 08:15:30 a_0_description Es wird in Bodennähe leichter Frost zwischen 0 °C und -2 °C erwartet.
2015-11-02 08:15:30 a_0_event BODENFROST
2015-11-02 08:15:30 a_0_eventCode_AREA_COLOR 255 255 0
2015-11-02 08:15:30 a_0_eventCode_AREA_COLOR_hex ffff00
2015-11-02 08:15:30 a_0_eventCode_GROUP FROST
2015-11-02 08:15:30 a_0_eventCode_II 21
2015-11-02 08:15:30 a_0_eventCode_LICENSE Geobasisdaten: Copyright Bundesamt für Kartographie und Geodäsie, Frankfurt am Main, 2013
2015-11-02 08:15:30 a_0_eventCode_PROFILE_VERSION 2.1
2015-11-02 08:15:30 a_0_expires 2015-11-02T08:00:00+00:00
2015-11-02 08:15:30 a_0_expires_local 02.11.2015 09:00:00
2015-11-02 08:15:30 a_0_geoCode_STATE NS
2015-11-02 08:15:30 a_0_geoCode_WARNCELLID 103156000
2015-11-02 08:15:30 a_0_headline Amtliche WARNUNG vor BODENFROST
2015-11-02 08:15:30 a_0_identifier ARRAY(0x434f6b0)
2015-11-02 08:15:30 a_0_language de-DE
2015-11-02 08:15:30 a_0_msgType Alert
2015-11-02 08:15:30 a_0_onset 2015-11-01T21:00:00+00:00
2015-11-02 08:15:30 a_0_onset_local 01.11.2015 22:00:00
2015-11-02 08:15:30 a_0_responseType None
2015-11-02 08:15:30 a_0_sent 2015-11-02T07:07:00+00:00
2015-11-02 08:15:30 a_0_sent_local 02.11.2015 08:07:00
2015-11-02 08:15:30 a_0_severity Minor
2015-11-02 08:15:30 a_0_status Actual
2015-11-02 08:15:30 a_0_urgency Immediate
2015-11-02 08:15:30 a_0_valid 1
2015-11-02 08:15:30 a_1_areaDesc Stadt Hagen
2015-11-02 08:15:30 a_1_category Met
2015-11-02 08:15:30 a_1_certainty Observed
2015-11-02 08:15:30 a_1_description Es tritt gebietsweise Nebel mit Sichtweiten unter 150 Meter auf.
2015-11-02 08:15:30 a_1_event NEBEL
2015-11-02 08:15:30 a_1_eventCode_AREA_COLOR 255 255 0
2015-11-02 08:15:30 a_1_eventCode_AREA_COLOR_hex ffff00
2015-11-02 08:15:30 a_1_eventCode_GROUP FOG
2015-11-02 08:15:30 a_1_eventCode_II 59
2015-11-02 08:15:30 a_1_eventCode_LICENSE Geobasisdaten: Copyright Bundesamt für Kartographie und Geodäsie, Frankfurt am Main, 2013
2015-11-02 08:15:30 a_1_eventCode_PROFILE_VERSION 2.1
2015-11-02 08:15:30 a_1_expires 2015-11-02T09:00:00+00:00
2015-11-02 08:15:30 a_1_expires_local 02.11.2015 10:00:00
2015-11-02 08:15:30 a_1_geoCode_STATE NRW
2015-11-02 08:15:30 a_1_geoCode_WARNCELLID 105914000
2015-11-02 08:15:30 a_1_headline Amtliche WARNUNG vor NEBEL
2015-11-02 08:15:30 a_1_identifier ARRAY(0x434f6b0)
2015-11-02 08:15:30 a_1_language de-DE
2015-11-02 08:15:30 a_1_msgType Alert
2015-11-02 08:15:30 a_1_onset 2015-11-02T00:23:00+00:00
2015-11-02 08:15:30 a_1_onset_local 02.11.2015 01:23:00
2015-11-02 08:15:30 a_1_responseType None
2015-11-02 08:15:30 a_1_sent 2015-11-02T07:07:00+00:00
2015-11-02 08:15:30 a_1_sent_local 02.11.2015 08:07:00
2015-11-02 08:15:30 a_1_severity Minor
2015-11-02 08:15:30 a_1_status Actual
2015-11-02 08:15:30 a_1_urgency Immediate
2015-11-02 08:15:30 a_1_valid 1
2015-11-02 08:15:30 a_2_category Met
2015-11-02 08:15:30 a_2_certainty Observed
2015-11-02 08:15:30 a_2_description Es tritt Nebel mit Sichtweiten unter 150 Meter auf.
2015-11-02 08:15:30 a_2_event NEBEL
2015-11-02 08:15:30 a_2_eventCode_AREA_COLOR 255 255 0
2015-11-02 08:15:30 a_2_eventCode_AREA_COLOR_hex ffff00
2015-11-02 08:15:30 a_2_eventCode_GROUP FOG
2015-11-02 08:15:30 a_2_eventCode_II 59
2015-11-02 08:15:30 a_2_eventCode_LICENSE Geobasisdaten: Copyright Bundesamt für Kartographie und Geodäsie, Frankfurt am Main, 2013
2015-11-02 08:15:30 a_2_eventCode_PROFILE_VERSION 2.1
2015-11-02 08:15:30 a_2_expires 2015-11-02T09:00:00+00:00
2015-11-02 08:15:30 a_2_expires_local 02.11.2015 10:00:00
2015-11-02 08:15:30 a_2_headline Amtliche WARNUNG vor NEBEL
2015-11-02 08:15:30 a_2_identifier ARRAY(0x434f6b0)
2015-11-02 08:15:30 a_2_language de-DE
2015-11-02 08:15:30 a_2_msgType Alert
2015-11-02 08:15:30 a_2_onset 2015-11-02T02:39:00+00:00
2015-11-02 08:15:30 a_2_onset_local 02.11.2015 03:39:00
2015-11-02 08:15:30 a_2_responseType None
2015-11-02 08:15:30 a_2_sent 2015-11-02T07:07:00+00:00
2015-11-02 08:15:30 a_2_sent_local 02.11.2015 08:07:00
2015-11-02 08:15:30 a_2_severity Minor
2015-11-02 08:15:30 a_2_status Actual
2015-11-02 08:15:30 a_2_urgency Immediate
2015-11-02 08:15:30 a_2_valid 1
2015-11-02 08:15:30 a_3_category Met
2015-11-02 08:15:30 a_3_certainty Observed
2015-11-02 08:15:30 a_3_description Es tritt Nebel mit Sichtweiten unter 150 Meter auf.
2015-11-02 08:15:30 a_3_event NEBEL
2015-11-02 08:15:30 a_3_eventCode_AREA_COLOR 255 255 0
2015-11-02 08:15:30 a_3_eventCode_AREA_COLOR_hex ffff00
2015-11-02 08:15:30 a_3_eventCode_GROUP FOG
2015-11-02 08:15:30 a_3_eventCode_II 59
2015-11-02 08:15:30 a_3_eventCode_LICENSE Geobasisdaten: Copyright Bundesamt für Kartographie und Geodäsie, Frankfurt am Main, 2013
2015-11-02 08:15:30 a_3_eventCode_PROFILE_VERSION 2.1
2015-11-02 08:15:30 a_3_expires 2015-11-02T09:00:00+00:00
2015-11-02 08:15:30 a_3_expires_local 02.11.2015 10:00:00
2015-11-02 08:15:30 a_3_headline Amtliche WARNUNG vor NEBEL
2015-11-02 08:15:30 a_3_identifier ARRAY(0x434f6b0)
2015-11-02 08:15:30 a_3_language de-DE
2015-11-02 08:15:30 a_3_msgType Alert
2015-11-02 08:15:30 a_3_onset 2015-11-02T04:46:00+00:00
2015-11-02 08:15:30 a_3_onset_local 02.11.2015 05:46:00
2015-11-02 08:15:30 a_3_responseType None
2015-11-02 08:15:30 a_3_sent 2015-11-02T07:07:00+00:00
2015-11-02 08:15:30 a_3_sent_local 02.11.2015 08:07:00
2015-11-02 08:15:30 a_3_severity Minor
2015-11-02 08:15:30 a_3_status Actual
2015-11-02 08:15:30 a_3_urgency Immediate
2015-11-02 08:15:30 a_3_valid 1
2015-11-02 08:15:30 a_4_category Met
2015-11-02 08:15:30 a_4_certainty Observed
2015-11-02 08:15:30 a_4_description Es tritt gebietsweise Nebel mit Sichtweiten unter 150 Meter auf.
2015-11-02 08:15:30 a_4_event NEBEL
2015-11-02 08:15:30 a_4_eventCode_AREA_COLOR 255 255 0
2015-11-02 08:15:30 a_4_eventCode_AREA_COLOR_hex ffff00
2015-11-02 08:15:30 a_4_eventCode_GROUP FOG
2015-11-02 08:15:30 a_4_eventCode_II 59
2015-11-02 08:15:30 a_4_eventCode_LICENSE Geobasisdaten: Copyright Bundesamt für Kartographie und Geodäsie, Frankfurt am Main, 2013
2015-11-02 08:15:30 a_4_eventCode_PROFILE_VERSION 2.1
2015-11-02 08:15:30 a_4_expires 2015-11-02T09:00:00+00:00
2015-11-02 08:15:30 a_4_expires_local 02.11.2015 10:00:00
2015-11-02 08:15:30 a_4_headline Amtliche WARNUNG vor NEBEL
2015-11-02 08:15:30 a_4_identifier ARRAY(0x434f6b0)
2015-11-02 08:15:30 a_4_language de-DE
2015-11-02 08:15:30 a_4_msgType Alert
2015-11-02 08:15:30 a_4_onset 2015-11-01T17:45:00+00:00
2015-11-02 08:15:30 a_4_onset_local 01.11.2015 18:45:00
2015-11-02 08:15:30 a_4_responseType None
2015-11-02 08:15:30 a_4_sent 2015-11-02T07:07:00+00:00
2015-11-02 08:15:30 a_4_sent_local 02.11.2015 08:07:00
2015-11-02 08:15:30 a_4_severity Minor
2015-11-02 08:15:30 a_4_status Actual
2015-11-02 08:15:30 a_4_urgency Immediate
2015-11-02 08:15:30 a_4_valid 1
2015-11-02 08:15:30 a_5_category Met
2015-11-02 08:15:30 a_5_certainty Observed
2015-11-02 08:15:30 a_5_description Es tritt gebietsweise Nebel mit Sichtweiten unter 150 Meter auf.
2015-11-02 08:15:30 a_5_event NEBEL
2015-11-02 08:15:30 a_5_eventCode_AREA_COLOR 255 255 0
2015-11-02 08:15:30 a_5_eventCode_AREA_COLOR_hex ffff00
2015-11-02 08:15:30 a_5_eventCode_GROUP FOG
2015-11-02 08:15:30 a_5_eventCode_II 59
2015-11-02 08:15:30 a_5_eventCode_LICENSE Geobasisdaten: Copyright Bundesamt für Kartographie und Geodäsie, Frankfurt am Main, 2013
2015-11-02 08:15:30 a_5_eventCode_PROFILE_VERSION 2.1
2015-11-02 08:15:30 a_5_expires 2015-11-02T09:00:00+00:00
2015-11-02 08:15:30 a_5_expires_local 02.11.2015 10:00:00
2015-11-02 08:15:30 a_5_headline Amtliche WARNUNG vor NEBEL
2015-11-02 08:15:30 a_5_identifier ARRAY(0x434f6b0)
2015-11-02 08:15:30 a_5_language de-DE
2015-11-02 08:15:30 a_5_msgType Alert
2015-11-02 08:15:30 a_5_onset 2015-11-02T04:10:00+00:00
2015-11-02 08:15:30 a_5_onset_local 02.11.2015 05:10:00
2015-11-02 08:15:30 a_5_responseType None
2015-11-02 08:15:30 a_5_sent 2015-11-02T07:07:00+00:00
2015-11-02 08:15:30 a_5_sent_local 02.11.2015 08:07:00
2015-11-02 08:15:30 a_5_severity Minor
2015-11-02 08:15:30 a_5_status Actual
2015-11-02 08:15:30 a_5_urgency Immediate
2015-11-02 08:15:30 a_5_valid 1
2015-11-02 08:15:30 a_count 6
2015-11-02 08:15:30 a_valid 1
2015-11-02 08:14:09 c_altitude 1142
2015-11-02 08:14:09 c_rain24h 0
2015-11-02 08:14:09 c_stationName Brocken
2015-11-02 08:14:09 c_sunshine 9.6
2015-11-02 08:14:09 c_tAvgAir24 15.2
2015-11-02 08:14:09 c_tMaxAir24 18.1
2015-11-02 08:14:09 c_tMinAir24 10.2
2015-11-02 08:14:09 c_tMinGrnd24 1.0
2015-11-02 08:14:09 c_windPeak 70
2015-11-02 08:15:30 state active
File:
dir gds/help/
dwd legend_warnings_CAP_WarnCellsID.csv
target /tmp/capstations.csv
Helper:
INTERVAL 1200
PASS Passwort
URL ftp-outgoing2.dwd.de
USER User
Attributes:
gdsDebug 1
gdsLong 1
gdsSetCond Brocken
gdsUseAlerts 1
group Wetter
room System
Nach einem Neustart von Fhem kommt Anfangs wieder nur die Meldung für meine Stadt, was sich im Laufe der automaischen (at) Aktualisierung zu obigen Phänomen aufschaukelt.
Ich bin ratlos.
Nachtrag: Beobachtet habe ich jetzt, daß es nach jedem rereadcfg und Aktualisierung der vom DWD-Server geladenen Daten auftritt. Mit jeder Aktualisierung kommt eine andere Stadt/Meldung hinzu.
2. Nachtrag: Jetzt liegen für meine Stadt keine Warnmeldungen mehr vor und damit sind auch alle anderen Meldungen weg.
MfG
Zitat von: jensb am 02 November 2015, 07:43:03
ja, wenn man FHEMWEB zur Konfiguration benutzt, muss man gdsSetCond/Forcast nich unbedingt manuell einstellen, was die Sache vereinfacht.
*** STOP ***bei gdsSetCond und gdsSetForecast trägt bitte NIEMAND etwas ein!
Die zu verwendenden Stationen werden ausschließlich über
set <name> conditions <stationName> eingestellt (bzw. set forecast) und NICHT über die Attribute.
Zitat2015.11.01 23:23:26 1: PERL WARNING: Deep recursion on subroutine "main::GDS_GetUpdate" at fhem.pl line 2725.
Das muss ich mir anschauen.
Zitat von: spikeh1 am 02 November 2015, 08:25:25
Aktuell gibt es für meine Region/Stadt eine Warnmeldung, welche mir manuell über die Fhem-Oberfläche abgerufen auch als Reading abgelegt wird.
Rufe ich jedoch über die Warncell-ID ab, laufen bei mir auch andere Readings aus anderen Regionen auf und es kommen immer mehr Ort/Meldungen dazu.
Das Problem ist mir bekannt, daran arbeite ich noch. Das Tückische ist, dass ich daran nur arbeiten kann, wenn es zufällig gerade Stationen mit mehr als einer Warnmeldung gibt.
Zitat
define dwd_read_data at +*00:30:00 get dwd_alerts alerts 103156000
attr dwd_read_data alignTime 00:05:30
Dieses zweite at brauchst Du nicht mehr, Du kannst stattdessen das Auswerten der Wetterwarnungen jetzt direkt per notify starten. Das gds Modul liefert nach jeder erfolgreichen Verarbeitung gelesener Daten einen entsprechenden Trigger. Einfach mal den EventMonitor beobachten.
Natürlich funktioniert der "alte" Lösungsweg mit zwei at Definitionen nach wie vor.
Zitat von: betateilchen am 02 November 2015, 10:26:20
Das Problem ist mir bekannt, daran arbeite ich noch. Das Tückische ist, dass ich daran nur arbeiten kann, wenn es zufällig gerade Stationen mit mehr als einer Warnmeldung gibt.
Dieses zweite at brauchst Du nicht mehr, Du kannst stattdessen das Auswerten der Wetterwarnungen jetzt direkt per notify starten. Das gds Modul liefert nach jeder erfolgreichen Verarbeitung gelesener Daten einen entsprechenden Trigger. Einfach mal den EventMonitor beobachten.
Natürlich funktioniert der "alte" Lösungsweg mit zwei at Definitionen nach wie vor.
Ich danke dir für deine Antwort. War schon am verzweifeln.
Ich habe zwar die E-Mail vom DWD erhalten, das eine Umstellung der Struktur erfolgt, jedoch habe ich diese gelöscht.
Bis wann läuft denn noch die alte Verzeichnisstruktur beim DWD und wie lange kann ich somit auf meinem Produktivsystem noch die alte Version von deinem Modul verwenden?
Auf meinem Testsystem lasse ich die aktuelle Version laufen. Werde beobachten und bei Bedarf berichten.
MfG
Zitat von: betateilchen am 02 November 2015, 10:26:20
2015.11.01 23:23:26 1: PERL WARNING: Deep recursion on subroutine "main::GDS_GetUpdate" at fhem.pl line 2725.
Das muss ich mir anschauen.
OK, wenn ich das nochmals reproduzieren kann, sag ich Bescheid.
Allerdings hatte ich bei den Attributen selber etwas eingetragen, wie das auch im wiki steht. Vielleicht war das die Ursache?
Wiki find ich doof.
Man sieht ja nun, was dabei rauskommt...
Zitat von: betateilchen am 02 November 2015, 10:55:11
Wiki find ich doof.
Man sieht ja nun, was dabei rauskommt...
Nun ja, ich war halt zu müde und faul um alles im Code nachzulesen... ;)
Hallo Zusammen,
Danke erstmal für eure tolle Arbeit!
Ich habe seit gestern folgende Meldung im Log:
Zitat2015.11.03 11:40:05 1: PERL WARNING: Key 'archive' (/tmp/GDSWetter_alerts.zip) is of invalid type for 'Archive::Extract::new' provided by (eval) at ./FHEM/55_GDS.pm line 1390
Irgendetwas scheint mit dem Entpacken des Archives nicht zu stimmen.
Viele Grüße,
redflag
ja, dieser Fehler tritt manchmal auf, eine eindeutige Ursache dafür konnte ich noch nicht ausmachen. Solange der Fehler nicht bei jedem Datenabruf stattfindet, sollte man sich keine allzugroßen Gedanken darüber machen. Vielleicht fällt mir irgendwann eine Lösung ein, wie ich das unterbinden kann. Aktuell habe ich noch keine.
Zitat von: betateilchen am 03 November 2015, 12:31:34
ja, dieser Fehler tritt manchmal auf, eine eindeutige Ursache dafür konnte ich noch nicht ausmachen. Solange der Fehler nicht bei jedem Datenabruf stattfindet, sollte man sich keine allzugroßen Gedanken darüber machen. Vielleicht fällt mir irgendwann eine Lösung ein, wie ich das unterbinden kann. Aktuell habe ich noch keine.
Tut mir leid, aber seit Samstag wurde kein reading mehr ausgeführt und bricht stets mit der Meldung im Log ab. Hier ist jetzt ein durchgehendes Problem. Ich habe auch mal ein bisschen gesucht, aber kenne mich leider zu wenig mit Perl aus. Hast du vielleicht eine Idee?
@redflag237
Das könnte bei dir auch ein Installationsproblem sein. Hatte am 27.10. die gleiche Fehlermeldung. Das neue GDS-Modul verwendet wie weiter oben beschrieben ein neues Perl-Modul, das ggf. nachinstalliert werden muss, siehe http://forum.fhem.de/index.php/topic,42015.msg349067.html#msg349067 (http://forum.fhem.de/index.php/topic,42015.msg349067.html#msg349067).
Auf einem RPi hilft für Archive::Extract z.B.
apt-get install libarchive-extract-perl
Das war aber nicht das einzige Paket was bei mir gefehlt hat. Welches Paket fehlt, kann man aus der Fehlermeldung schließen. Danach hilft eine Suchmaschine, den passenden apt-get install zu finden.
LG, Jens
Zitat von: jensb am 04 November 2015, 19:59:28
Das könnte bei dir auch ein Installationsproblem sein. Hatte am 27.10. die gleiche Fehlermeldung. Das neue GDS-Modul verwendet wie weiter oben beschrieben ein neues Perl-Modul, das ggf. nachinstalliert werden muss, ...
Ich habe auf meiner Testumgebung dieses Problem auch ab und zu schon gehabt. Dort sind alle benötigten Perl-Module installiert.
Das einzige was bei mir geholfen hat, das Archiv aus dem /tmp Ordner manuell löschen und rereadcfg im GDS-Modul.
Dann lief es bei mir einige Zeit wieder.
@Jens @spikeh1
Modul per CPAN nachinstalliert. Fehlte offensichtlich, danke für den Hinweis.
Für alle Leidensgenossen hier das notwendige Snippet:
/usr/bin/perl -MCPAN -e 'install Archive::Extract'
Ich muss nun alle 6 Stunden die Zip aus dem tmp Ordner löschen, weil die Aktualisierung immer wieder mit der bekannten Meldung hängt.
Viele Grüße,
redflag237
ZitatIch muss nun alle 6 Stunden die Zip aus dem tmp Ordner löschen, weil die Aktualisierung immer wieder mit der bekannten Meldung hängt.
Wahrscheinlich ist das nicht die Ursache bei euch, aber nur um sicher zu sein: Hat euer 55_GDS.pm die Versionsnummer
9751 (mit Kommando "version" abfragen)? Das Modul wurde Sonntag Abend noch einmal zur Verbesserung der Vorhersage-Abfrage aktualisiert, was sich allerdings nur bei aktivierter Vorhersage-Abfrage auswirkt und (eigentlich) nur auf die Vollständigkeit der Vorhersagedaten.
LG, Jens
Zitat von: jensb am 04 November 2015, 21:45:43
Wahrscheinlich ist das nicht die Ursache bei euch, aber nur um sicher zu sein: Hat euer 55_GDS.pm die Versionsnummer 9751 (mit Kommando "version" abfragen)? Das Modul wurde Sonntag Abend noch einmal zur Verbesserung der Vorhersage-Abfrage aktualisiert, was sich allerdings nur bei aktivierter Vorhersage-Abfrage auswirkt und (eigentlich) nur auf die Vollständigkeit der Vorhersagedaten.
LG, Jens
Version bei mir ist die 9751. Allerdings nutze ich nicht die Vorhersage-Abfrage, sondern nur die Funktion für Warn-/Alarmmeldungen.
MfG
Ich erhalte auf meinem RasPI einen Fehler beim Installieren von libarchive-extract-perl :
pi@raspberrypi ~ $ sudo apt-get install libarchive-extract-perl
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
E: Paket libarchive-extract-perl kann nicht gefunden werden.
Hat jemand eine Idee, woran das liegen könnte?
Vielen Dank vorab.
Zitat von: feeeem am 05 November 2015, 13:24:01
Ich erhalte auf meinem RasPI einen Fehler beim Installieren von libarchive-extract-perl :
Hat jemand eine Idee, woran das liegen könnte?
Siehe mein Post weiter oben, das kannst du einfach so in der Befehlszeile absetzen. Das scheint für Debian irgendwie anders Paketiert zu sein, mcpan installiert es direkt aus den Perl Quellen. However, es funktioniert ;)
Grüße,
redflag237
Hallo redflag237,
Habe gerade in dem Thread 55_GDS.pm - komplett überarbeitet - RC1 (http://forum.fhem.de/index.php/topic,42015.30.html) den Hinweis auf das Paket libarchive-any-perl gefunden und angewendet. Denke das ist eher der vorgesehene Weg.
Danke trotzdem für die Rückmeldung.
Norbert
Zitat von: viegener am 01 November 2015, 23:45:34
2015.11.01 23:23:26 1: PERL WARNING: Deep recursion on subroutine "main::GDS_GetUpdate" at fhem.pl line 2725.
2015.11.01 23:23:26 1: PERL WARNING: Deep recursion on subroutine "main::InternalTimer" at FHEM/Blocking.pm line 79.
2015.11.01 23:23:26 1: PERL WARNING: Deep recursion on subroutine "main::InternalTimer" at ./FHEM/55_GDS.pm line 682.
Dieses Problem sollte mit dem morgigen Update gelöst sein.
Zitat von: redflag237 am 04 November 2015, 21:16:55
Ich muss nun alle 6 Stunden die Zip aus dem tmp Ordner löschen, weil die Aktualisierung immer wieder mit der bekannten Meldung hängt.
Die ZIP Datei sollte eigentlich nach der Datenaufbereitung automatisch gelöscht werden, aber die Zeile mit dem Löschen ist vermutlich irgendeinem Code-Cleanup zum Opfer gefallen.
Mit dem morgigen Update sollte es nach einer Aufbereitung der Daten im /tmp kein ZIP mehr geben.
Ausnahme: wenn das Attribut gdsDebug auf 1 gesetzt ist, wird die Datei auch weiterhin
nicht gelöscht. Das ist manchmal nützlich für Tests und Fehlersuche.
Zitat von: betateilchen am 06 November 2015, 16:25:24
Dieses Problem sollte mit dem morgigen Update gelöst sein.
OK, habe heute upgedated und auch Server mehrfach neu gestartet. Ist jetzt nicht wieder aufgetreten.
Danke für die Behebung!
Johannes
Funktioniert bei euch aktuell die GetHeadlines-Methode? Ich erhalte nur die Seperatoren, der Text dazwischen fehlt derzeit. (Version neuster Stand).
Hallo betateilchen,
https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/55_GDS.pm [Zeile 809] habe ich wie folgt gefixed:
ALT: $text .= ReadingsVal('gds','a_'.$i.'_headline','')
NEU: $text .= ReadingsVal($d,'a_'.$i.'_headline','')
Falls das so korrekt ist, bitte ich um korrektur im Git.
Viele Grüße,
redflag
Hallo betateilchen,
Die Methode GetHeadlines gibt zahlreiche Warnings aus, die aus anderen CellIds stammen. Anbei eine angepasste Version, die die Headlines vorfiltert:
sub
myGdsHeadlines($;$;$) {
my ($d,$cell,$sep) = @_;
my $text = "";
$sep = (defined($sep)) ? $sep : '|';
my $count = ReadingsVal($d,'a_count',0);
my $flagfirst = 0;
for (my $i = 0; $i < $count; $i++) {
my $currentcell = ReadingsVal($d,'a_'.$i.'_geoCode_WARNCELLID','');
$currentcell =~ s/^\s+|\s+$//g ;
if ($cell eq $currentcell)
{
$text .= $sep if $flagfirst;
$flagfirst++;
$text .= ReadingsVal($d,'a_'.$i.'_headline','');
}
}
return $text;
}
Gruß redflag
Hallo betateilchen,
Vielen Dank für Dein tolles Modul. Habe es nun auch in der aktuellen Version bei mir einbinden können. Kleine Fragen habe ich aber.
- Benötige ich ein at und wenn ja wofür? Meine c_ Werte werden immer aktuallisiert?
- für was stehen dieg_ Werte und warum werden sie nicht aktuallisiert und wie kann ich das machen?
Vielen Dank und weiter so
Grüße
Leon
Deine Fragen sind eigentlich alle in der commandref beantwortet...
Zitat
c_<readingName> - weather data from SET weather conditions. Readings will be updated every 20 minutes.
g_<readingName> - weather data from GET weather conditions. Readings will NOT be updated automatically
Zitat von: betateilchen am 11 November 2015, 19:36:21
Deine Fragen sind eigentlich alle in der commandref beantwortet...
Ok da hätte ich in der Tat lesen sollen, hatte auf die schnelle nur im Wiki geschaut. Sorry. Dann schau ich mal in die Commandref wie ich die g_ Readings aktuallisiert bekomme ;D
Grüße
Edit: Gefunden und gelesen. Alles gut :)
Betr.: Unzählige falsche Warnmeldungen bei Abruf über Cell-ID
Hallo,
wird das Problem
Zitat von: spikeh1 am 02 November 2015, 08:25:25
Rufe ich jedoch über die Warncell-ID ab, laufen bei mir auch andere Readings aus anderen Regionen auf und es kommen immer mehr Ort/Meldungen dazu.
durch die von redflag237 vorgeschlagenen Änderungen
Zitat von: redflag237 am 09 November 2015, 21:37:24
Anbei eine angepasste Version, die die Headlines vorfiltert:
gelöst? Sollte man die Änderungen selbst einpflegen, oder sind an anderer Stelle neue Probleme zu befürchten?
Danke,
awel
Hallo betateilchen,
Bisher hatte ich noch keine Warnungen für meinen Bereich. Wenn eine Kommt soll ja a_valid auf 1 gehen und a_count x die Anzahl der Warnungen anzeigen. Bleiben diese Readings dann auch erhalten und ändern sich nur auf 0. Oder löscht Du sie wieder? (das Modul)
Wäre schön wenn sie stehen bleiben, da ich sie in TabletUI für einen Button verwenden.
Grüße
Das Problem mit den Readings auf falschen Regionen sollte mit dem morgigen Update gelöst sein.
Die Headlines funktionieren bei mir ohne Änderung problemlos, dazu wird es keine weitere Änderung geben.