GDS Timeouts

HolyMoly · 29 Dezember 2015, 21:23:12

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:

Code Auswählen


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?

Fhem Karl · 30 Dezember 2015, 10:24:30

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

HolyMoly · 05 Januar 2016, 22:22:37

Heute wieder, mit saftig Speicherproblemen

Code Auswählen

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...

Fhem Karl · 05 Januar 2016, 23:16:35

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

betateilchen · 06 Januar 2016, 00:29:54

Mit den conditions habe ich aktuell auch Probleme, aber im Moment keine Zeit, mich darum zu kümmern.

Gisbert · 06 Januar 2016, 08:23:28

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.

betateilchen · 06 Januar 2016, 11:42:20

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.

betateilchen · 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

Code Auswählen

my $datafile = $files[-1];

ändern in

Code Auswählen

my $datafile = $files[-2];

Nach einem fhem restart sollten die conditions dann wieder vorhanden sein.

CoolTux · 06 Januar 2016, 12:02:07

Geht! Danke Dir.

Grüße

Ellert · 06 Januar 2016, 12:25:53

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.

betateilchen · 06 Januar 2016, 12:29:52

Keine Sorge, ich kenne genug HTML Parser.

doesel · 11 Januar 2016, 14:47:45

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

betateilchen · 11 Januar 2016, 19:23:52

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.

doesel · 11 Januar 2016, 21:08:57

OK, danke.
Doesel

elhennig · 28 Januar 2016, 15:09:11

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

Code Auswählen Erweitern
my $datafile = $files[-1];

ändern in

Code Auswählen Erweitern
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

Code Auswählen

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.