Hallo betateilchen,
ich habe eine Frage zu Deinem GDS-Modul: Ich habe das Problem, dass ich immer perfom-delays bekomme, wenn das GDS-Modul das ZIP-Archiv extrahiert.
Jetzt habe ich im Code gesehen, dass die globale Variable "PREFER_BIN" des Archive::Extract-Perlmoduls auf 1 gesetzt ist und damit das unzip Kommandozeilentool statt dem unzip Perl Modul verwendet wird.
$Archive::Extract::PREFER_BIN = 1;
Was ist der Grund dafür? Kann das mit meinem perfom-delays zusammenmhängen aufgrund eines blocking-Verhaltens der Kommandozeile?
update: habe es getestet, auch mit prefer_bin 0 kommen die perfmon delays. was kann man noch gegen die delays machen bzgl. unizp? kann das unzip nicht irgendwie mit minimaler priorität im hintergrund ablaufen?
Ich finde das GDS Modul so klasse, dass ich darauf nicht verzichten möchte, auch wenn andere Module wie UWZ bei mir keine perform delays verursachen.
Zitat von: FhemPiUser am 28 August 2016, 07:51:44
Jetzt habe ich im Code gesehen, dass die globale Variable "PREFER_BIN" des Archive::Extract-Perlmoduls auf 1 gesetzt ist
In der aktuellen Version des GDS Moduls
55_GDS.pm 11734 2016-07-03 14:12:48Zwird Archive::Extract überhaupt nicht mehr verwendet.
ok, ich habe gerade ein update all gemacht und habe trotzdem eine ältere Version?
55_GDS.pm 11367 2016-05-02
In der Version ist eine Funktion zum unzippen vorhanden, allerdings habe ich gerade bemerkt, dass diese scheinbar gar nicht verwendet wird...
Hmm, wie wird dann das zip-Archiv extrahiert bzw. woher können sonst die perfmon delays kommen?
Die Delays kommen immer genau zu dem Zeitpunkt des notify bzw at
define n_checkGDS notify dwd:REREADALERTS get dwd alerts xxx
define a_checkGDS at +*01:00:00 get dwd rereadcfg
Zitat von: FhemPiUser am 29 August 2016, 07:11:40
ok, ich habe gerade ein update all gemacht und habe trotzdem eine ältere Version?
Logisch. GDS wird nicht per update aktualisiert, da es seit einigen Monaten nur noch im ./contrib Zweig von fhem liegt.
Da muss man sich schon selbst um das Update kümmern.
ahh, ok, danke, das wusste ich nicht. ich spiel mal die neue version ein und teste mal. bin gespannt, will endlich diese delays loswerden...
das modul ist super, danke für die entwicklung!
bei der neuen version wird bei mir das notify zum holen der alerts nicht mehr getriggert. hat sich da etwas verändert?
bisher hatte ich ein at und ein notify:
define at_dwd at +*01:00:00 get dwd rereadcfg
define n_dwd notify dwd:REREADALERTS get dwd alerts xxxx
hmm, ok, komisch, er scheint das notify nicht auszuführen...
Eine andere Frage: Wieso wird das GDS Modul nicht mehr offiziell mit fhem verteilt?
Zitat von: FhemPiUser am 30 August 2016, 20:38:15
Eine andere Frage: Wieso wird das GDS Modul nicht mehr offiziell mit fhem verteilt?
https://forum.fhem.de/index.php/topic,53676.msg454893.html#msg454893
danke benni und schade, denn ich finde das Modul klasse...
Zitat von: FhemPiUser am 30 August 2016, 21:09:26
schade, denn ich finde das Modul klasse...
Ich auch, aber den Streß drumrum nicht.
ahh, jetzt geht es bei mir wieder mit notify und at und es gibt keine delays mehr.
Super, danke!
Hi betateilchen,
kriege seit dem Update von GDS-Modul auf die neueste Version immer folgende Meldung im fhem log:
readingsUpdate(dwd,alert_headline,Amtliche WARNUNG vor STARKEM GEWITTER ) missed to call readingsBeginUpdate first.
2016.09.04 18:17:27 1: readingsUpdate(dwd,alert_headline_exists,1) missed to call readingsBeginUpdate first.
Sagt Dir das was?
Zitat von: FhemPiUser am 04 September 2016, 20:51:29
kriege seit dem Update von GDS-Modul auf die neueste Version immer folgende Meldung im fhem log:
...
Sagt Dir das was?
Das sagt mir, dass die Meldungen eigentlich nicht aus dem GDS Modul stammen können.
Hi betateilchen,
ich bekomme jetzt auch ein stacktrace zu dem Fehler. Hast Du eine Ahnung, was die Ursache sein könnte?
readingsUpdate(dwd,alert_headline,Amtliche WARNUNG vor FROST ) missed to call readingsBeginUpdate first.
2017.02.16 07:08:30.788 1: stacktrace:
2017.02.16 07:08:30.789 1: main::readingsBulkUpdate called by fhem.pl (4134)
2017.02.16 07:08:30.789 1: main::readingsEndUpdate called by ./FHEM/55_GDS.pm (1029)
2017.02.16 07:08:30.789 1: main::decodeCAPData called by ./FHEM/55_GDS.pm (541)
2017.02.16 07:08:30.789 1: main::GDS_Get called by fhem.pl (3302)
2017.02.16 07:08:30.790 1: main::CallFn called by fhem.pl (1714)
2017.02.16 07:08:30.790 1: main::CommandGet called by fhem.pl (1107)
2017.02.16 07:08:30.790 1: main::AnalyzeCommand called by fhem.pl (976)
2017.02.16 07:08:30.790 1: main::AnalyzeCommandChain called by ./FHEM/91_notify.pm (102)
2017.02.16 07:08:30.791 1: main::notify_Exec called by fhem.pl (3302)
2017.02.16 07:08:30.791 1: main::CallFn called by fhem.pl (3223)
2017.02.16 07:08:30.791 1: main::DoTrigger called by ./FHEM/55_GDS.pm (1246)
2017.02.16 07:08:30.791 1: main::_finishedCAPDATA called by (eval 79188) (1)
2017.02.16 07:08:30.792 1: (eval) called by fhem.pl (1028)
2017.02.16 07:08:30.792 1: main::AnalyzePerlCommand called by fhem.pl (1048)
2017.02.16 07:08:30.793 1: main::AnalyzeCommand called by fhem.pl (976)
2017.02.16 07:08:30.793 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (269)
2017.02.16 07:08:30.793 1: main::telnet_Read called by fhem.pl (3302)
2017.02.16 07:08:30.794 1: main::CallFn called by fhem.pl (674)
Das dazugehörige userReadings im GDS device "dwd" ist wie folgt:
attr dwd userReadings alert_headline { ReadingsVal("dwd","a_0_headline","Keine Unwetterwarnung")." ".ReadingsVal("dwd","a_1_event","")." ".ReadingsVal("dwd","a_2_event","");;;; },alert_headline_exists { (ReadingsVal("dwd","a_0_headline","Keine Unwetterwarnung") eq "Keine Unwetterwarnung") ? 0 : 1;;;; }