Hallo,
habe seit einer weile Probleme mit dem neuen GDS Modul. Meine GDS Instanz wird folgendermaßen verwendet:
define gds GDS xxx xxx
attr gds gdsDebug 1
attr gds gdsSetCond München-Flh.
attr gds gdsUseAlerts 1
define getGDSData at +*01:00:00 get gds rereadcfg
define getGDSAlerts notify gds:REREADALERTS {\
fhem("get gds alerts 109184000");;\
}
Aber es treten quasi jede Sekunde folgende Fehler auf:
2015.12.29 20:47:01 1: PERL WARNING: Key 'archive' (/tmp/gds_alerts.zip) is of invalid type for 'Archive::Extract::new' provided by (eval) at ./FHEM/55_GDS.pm line 1410.
2015.12.29 20:47:01 1: Timeout for _retrieveCAPDATA reached, terminated process 709
2015.12.29 20:47:01 3: get gds alerts 109184000 : Keine Warnmeldung für die gesuchte Region vorhanden.
2015.12.29 20:47:01 3: getGDSAlerts return value: Keine Warnmeldung für die gesuchte Region vorhanden.
2015.12.29 20:47:02 1: PERL WARNING: IO error: opening /tmp/gds_alerts.zip for read : No such file or directory
at /usr/local/share/perl/5.20.2/Archive/Zip/Archive.pm line 557.
Archive::Zip::Archive::read(Archive::Zip::Archive=HASH(0x220c1e8), "/tmp/gds_alerts.zip") called at /usr/local/share/perl/5.20.2/Archive/Extract.pm line 1154
Archive::Extract::_unzip_az(Archive::Extract=HASH(0x2230b40)) called at /usr/local/share/perl/5.20.2/Archive/Extract.pm line 432
Archive::Extract::extract(Archive::Extract=HASH(0x2230b40), "to", "/tmp/gds_alerts.dir") called at ./FHEM/55_GDS.pm line 1411
eval {...} called at ./FHEM/55_GDS.pm line 1407
main::_retrieveCAPDATA(HASH(0x2049350)) called at FHEM/Blocking.pm line 90
main::BlockingCall("_retrieveCAPDATA", HASH(0x2049350), "_finishedCAPDATA", 60, "_abortedCAPDATA", HASH(0x2049350)) called at ./FHEM/55_GDS.pm line 1190
main::retrieveData(HASH(0x2049350), "capdata") called at ./FHEM/55_GDS.pm line 548
main::GDS_Get(HASH(0x2049350), "gds", "rereadcfg") called at fhem.pl line 3185
main::CallFn("gds", "GetFn", HASH(0x2049350), "gds", "rereadcfg") called at fhem.pl line 1630
main::CommandGet(undef, "gds rereadcfg", "get") called at fhem.pl line 1067
main::AnalyzeCommand(undef, "get gds rereadcfg", undef) called at fhem.pl line 936
main::AnalyzeCommandChain(undef, "get gds rereadcfg") called at ./FHEM/90_at.pm line 169
main::at_Exec(HASH(0x26a5940)) called at fhem.pl line 2800
main::HandleTimeout() called at fhem.pl line 589
2015.12.29 20:47:02 1: Timeout for _retrieveCONDITIONS reached, terminated process 711
2015.12.29 20:47:02 1: Timeout for _retrieveCAPDATA reached, terminated process 712
2015.12.29 20:47:03 1: Timeout for _retrieveCAPDATA reached, terminated process 715
2015.12.29 20:47:04 1: Timeout for _retrieveCONDITIONS reached, terminated process 720
2015.12.29 20:47:04 1: PERL WARNING: IO error: Can't open /tmp/gds_alerts.zip : No such file or directory
at ./FHEM/55_GDS.pm line 1411.
2015.12.29 20:47:04 1: Timeout for _retrieveCAPDATA reached, terminated process 723
2015.12.29 20:47:05 1: Timeout for _retrieveCAPDATA reached, terminated process 725
Scheinbar kann er /tmp/gds_alerts.zip nicht entpacken. Die Datei liegt aber an dieser Stelle, lässt sich von Hand entpacken und enthält sinnvolle xml Dateien. libarchive-extract-perl ist installiert, gestern kamen auch mal in Fhem alerts an. Alle Kerne sind zu 100% ausgelastet, der Speicherbedarf steigt an bis einzelne fhem threads gekillt werden...
Weiß jemand woran es liegen könnte?
Hallo Holy Moly,
ich habe ein ähnliches Problem - bis jetzt lief alles einwandfrei und nun:
Vielleicht liegt es auch am DWD bzw. am Münchener Standort ... meine Daten kommen auch von Standort München-Flh. ...
2015.12.30 10:06:12 1: Timeout for _retrieveCONDITIONS reached, terminated process 6088
2015.12.30 10:06:12 1: Timeout for _retrieveCONDITIONS reached, terminated process 6089
2015.12.30 10:06:12 1: Timeout for _retrieveCAPDATA reached, terminated process 6090
2015.12.30 10:06:12 1: Timeout for _retrieveFILE reached, terminated process 6091
Key 'archive' (/tmp/DWD_alerts.zip) is of invalid type for 'Archive::Extract::new' provided by (eval) at ./FHEM/55_GDS.pm line 1410
Habe auch versucht ältere Versionen von GDS einzuspielen, reboot, ... alles nichts geholfen
Edit:31.12
Habe nun auch nochmal den DWD Zugang überprüft, Update des Moduls, tmp Vertzeichnis gelöscht und den alternative ftp Host probiert - leider Fehlanzeige ...
Vielleicht kann uns ja @ betateilchen weiterhelfen - mir fällt einfach nichts mehr ein.
Viele Grüße
Karl
Heute wieder, mit saftig Speicherproblemen :(
2016.01.05 18:56:54 3: getGDSAlerts return value: Keine Warnmeldung für die gesuchte Region vorhanden.
2016.01.05 18:56:54 3: get gds alerts 109184000 : Keine Warnmeldung für die gesuchte Region vorhanden.
2016.01.05 18:56:53 1: Timeout for _retrieveCONDITIONS reached, terminated process 4849
2016.01.05 18:56:52 3: getGDSAlerts return value: Keine Warnmeldung für die gesuchte Region vorhanden.
2016.01.05 18:56:52 3: get gds alerts 109184000 : Keine Warnmeldung für die gesuchte Region vorhanden.
2016.01.05 18:56:52 1: Cannot fork: Cannot allocate memory
2016.01.05 18:56:52 1: Cannot fork: Cannot allocate memory
2016.01.05 18:56:52 1: Cannot fork: Cannot allocate memory
2016.01.05 18:56:52 1: Cannot fork: Cannot allocate memory
at ./FHEM/55_GDS.pm line 1423.
2016.01.05 18:56:52 1: PERL WARNING: IO error: Can't open file /Z_CAP_C_EDZW_20160105175518_PVW_0.xml for write : Permission denied
2016.01.05 18:56:52 1: Cannot fork: Cannot allocate memory
2016.01.05 18:56:52 1: Cannot fork: Cannot allocate memory
2016.01.05 18:56:52 1: Cannot fork: Cannot allocate memory
2016.01.05 18:56:52 1: Cannot fork: Cannot allocate memory
at ./FHEM/55_GDS.pm line 1423.
2016.01.05 18:56:52 1: PERL WARNING: IO error: Can't open file /Z_CAP_C_EDZW_20160105175518_PVW_0.xml for write : Permission denied
2016.01.05 18:56:52 1: Cannot fork: Cannot allocate memory
2016.01.05 18:56:52 1: Cannot fork: Cannot allocate memory
2016.01.05 18:56:52 1: Timeout for _retrieveCONDITIONS reached, terminated process 4837
2016.01.05 18:56:52 1: Cannot fork: Cannot allocate memory
2016.01.05 18:56:52 1: Cannot fork: Cannot allocate memory
main::HandleTimeout() called at fhem.pl line 593
main::at_Exec(HASH(0x26a3310)) called at fhem.pl line 2816
main::AnalyzeCommandChain(undef, "get gds rereadcfg") called at ./FHEM/90_at.pm line 169
main::AnalyzeCommand(undef, "get gds rereadcfg") called at fhem.pl line 940
main::CommandGet(undef, "gds rereadcfg", "get") called at fhem.pl line 1070
main::CallFn("gds", "GetFn", HASH(0x206f2e0), "gds", "rereadcfg") called at fhem.pl line 1641
main::GDS_Get(HASH(0x206f2e0), "gds", "rereadcfg") called at fhem.pl line 3201
main::retrieveData(HASH(0x206f2e0), "capdata") called at ./FHEM/55_GDS.pm line 551
main::BlockingCall("_retrieveCAPDATA", HASH(0x206f2e0), "_finishedCAPDATA", 60, "_abortedCAPDATA", HASH(0x206f2e0)) called at ./FHEM/55_GDS.pm line 1204
main::_retrieveCAPDATA(HASH(0x206f2e0)) called at FHEM/Blocking.pm line 88
eval {...} called at ./FHEM/55_GDS.pm line 1419
Archive::Extract::extract(Archive::Extract=HASH(0x2256bd0), "to", "/tmp/gds_alerts.dir") called at ./FHEM/55_GDS.pm line 1423
Archive::Extract::_unzip_az(Archive::Extract=HASH(0x2256bd0)) called at /usr/local/share/perl/5.20.2/Archive/Extract.pm line 432
Archive::Zip::Archive::read(Archive::Zip::Archive=HASH(0x22312c0), "/tmp/gds_alerts.zip") called at /usr/local/share/perl/5.20.2/Archive/Extract.pm line 1154
at /usr/local/share/perl/5.20.2/Archive/Zip/Archive.pm line 557.
2016.01.05 18:56:51 1: PERL WARNING: IO error: opening /tmp/gds_alerts.zip for read : No such file or directory
Can't open file /Z_CAP_C_EDZW_20160105175518_PVW_0.xml for write : Permission denied
ist auch höchst seltsam. Diese alerts liegen ganz normal in /tmp/gds_alerts.dir und gehören dem fhem user...
Hallo,
nach einem Fhem Update heute bekomme ich zumindest die Alerts und Forecasts rein. Bei den aktuellen Conditions - nichts - no Data.
Ein neuer DWD User brachte auch nicht den gewünschten Erfolg.
Viele Grüsse Karl
Mit den conditions habe ich aktuell auch Probleme, aber im Moment keine Zeit, mich darum zu kümmern.
Hallo,
bei mir erscheinen seit dem 5.1. 10:53 keine neuen Einträge im log-file des Moduls.
Im Fhem-log-file stehen die folgenden Einträge:
2016.01.06 07:36:14 1: PERL WARNING: Use of uninitialized value $align in string eq at ./FHEM/55_GDS.pm line 986.
2016.01.06 07:36:14 1: PERL WARNING: Use of uninitialized value $align in string eq at ./FHEM/55_GDS.pm line 990.
Zitat von: betateilchen am 06 Januar 2016, 00:29:54
aber im Moment keine Zeit, mich darum zu kümmern.
*lach*Die Ursache des Problems bei den conditions steht im GDS Newsletter, der allerdings erst heute (nach einer vollzogenen Änderung beim DWD) hier ankam. In den nächsten Tagen werde ich mich darum kümmern.
Ob das GDS Modul die conditions demnächst überhaupt noch bereitstellt, muss ich in aller Ruhe überlegen.
Hintergrund ist, dass der DWD die Bereitstellung der Daten von txt auf html umstellt. Bis zum o.g. Datum werden beide Dateiformate geliefert, danach nur noch html. Schon das Parsen der txt Dateien war ein Krampf, aber dann die Daten aus html extrahieren zu müssen, wird ja noch schräger.
Wer die conditions aktuell "reparieren" will, kann folgendes tun:
Im aktuellen GDS Modul die Zeile 1298
my $datafile = $files[-1];
ändern in
my $datafile = $files[-2];
Nach einem fhem restart sollten die conditions dann wieder vorhanden sein.
Geht! Danke Dir.
Grüße
Zitat von: betateilchen am 06 Januar 2016, 11:56:00
Ob das GDS Modul die conditions demnächst überhaupt noch bereitstellt, muss ich in aller Ruhe überlegen.
Hintergrund ist, dass der DWD die Bereitstellung der Daten von txt auf html umstellt. Bis zum o.g. Datum werden beide Dateiformate geliefert, danach nur noch html. Schon das Parsen der txt Dateien war ein Krampf, aber dann die Daten aus html extrahieren zu müssen, wird ja noch schräger.
Kennst Du WWW::Mechanize, WWW::Mechanize::TreeBuilder? Damit könntest Du auf HTML-Tags zugreifen und hättest Java-Script änliche Zugriffsfunktionen.
Keine Sorge, ich kenne genug HTML Parser.
Hallo,
auch ich habe jetzt leider immer wieder folgende Einträge im LOG:
PERL WARNING: Key 'archive' (/tmp/DWD_alerts.zip) is of invalid type for 'Archive::Extract::new' provided by (eval) at ./FHEM/55_GDS.pm line 1422.
Habe schon an allen Schrauben gedreht, die ich hier im Forum gefunden hab. Die Warnings erscheinen auch unregelmäßig, manchmal nur 3 mal am Tag, manchmal regelmäßig alle 10 Minuten nach rereadcfg.
Hat jemand einen Tip, wo ich was übersehen/vergessen habe?
Danke im voraus,
Doesel
Zitat von: doesel am 11 Januar 2016, 14:47:45
Hat jemand einen Tip, wo ich was übersehen/vergessen habe?
nichts; einfach damit leben und ignorieren.
OK, danke.
Doesel
Zitat von: betateilchen am 06 Januar 2016, 11:56:00
Ob das GDS Modul die conditions demnächst überhaupt noch bereitstellt, muss ich in aller Ruhe überlegen.
Hintergrund ist, dass der DWD die Bereitstellung der Daten von txt auf html umstellt. Bis zum o.g. Datum werden beide Dateiformate geliefert, danach nur noch html. Schon das Parsen der txt Dateien war ein Krampf, aber dann die Daten aus html extrahieren zu müssen, wird ja noch schräger.
Wer die conditions aktuell "reparieren" will, kann folgendes tun:
Im aktuellen GDS Modul die Zeile 1298
my $datafile = $files[-1];
ändern in
my $datafile = $files[-2];
Nach einem fhem restart sollten die conditions dann wieder vorhanden sein.
Mit dem letzten Update des GDS Moduls ist diese Änderung ja vorhanden, trotzdem bekomme ich keine Conditions mehr. Der einzige Fehler im Log ist
Timeout for _retrieveCONDITIONS reached, terminated process Keine Ahnung ob der was damit zu tun hat.
Was kann ich tun, um die Aktuelle Werte zu bekommen?
Die Conditions sind für mich im Moment das Mittel der Wahl, um den Frostschutz für ein paar Kübelpflanzen entsprechend Temperatur zu schalten. Einen Temperatursensor habe ich nämlich nicht und die Genauigkeit der DWD-Werte ist für den Zweck völlig ausreichend. daher wäre sehr schade, wenn diese Daten nicht mehr zur Verfügung stünden.
Zitat von: elhennig am 28 Januar 2016, 15:09:11
Keine Ahnung ob der was damit zu tun hat.
Ja. Wenn die condititons wegen eines timeouts nicht vom Server gelesen werden, kann logischerweise nichts in fhem angezeigt werden.
Zitat von: elhennig am 28 Januar 2016, 15:09:11
Was kann ich tun, um die Aktuelle Werte zu bekommen?
Die timeout Meldung deutet auf ein Problem in Deiner fhem Installation hin, die nicht auf das GDS Modul selbst zurückzuführen ist.
Du musst also versuchen, das Problem in Deinem fhem zu finden.
Grundsätzlich funktioniert das Abrufen der conditions in der aktuellen Modulversion, bei mir gerade auf mehreren fhem-Installationen geprüft.
(http://up.picr.de/24418840vw.png)
Danke für Deine Antwort.
Mit dem Commanline ftp klappt die Verbindung, so dass ich ein grunbdlegendes Netzwerkproblem ausschließe.
Wie kann ich denn das Attribut gdsDebug setzen, die Doku sagt nicht viel dazu.
Ein weiterer Fehler im fhem-Log ist:
2016.01.28 17:53:05 1: PERL WARNING: Use of uninitialized value $align in string eq at ./FHEM/55_GDS.pm line 1011.
2016.01.28 17:53:05 1: PERL WARNING: Use of uninitialized value $align in string eq at ./FHEM/55_GDS.pm line 1015.
Zitat von: elhennig am 28 Januar 2016, 17:56:58
Ein weiterer Fehler im fhem-Log ist:
Da steht WARNING und nicht ERROR, also ist das kein Fehler, sondern nur eine Warnung. Das ist ein Folgefehler aufgrund der fehlenden conditions-Daten.
Das Attribut gdsDebug wird gesetzt wie jedes andere Attribut auch. Entweder im Frontend oder per Kommandozeile. Aber für die Fehlersuche bei Deinem Problem wird es ohenhin nicht helfen.
Mit einem "get GDSWeather list data" habe ich gerade gesehen, dass es für Augsburg keine Daten gibt.
Haben sich die Standorte geändert? Oder ist das ein temporäres Problem?