Use of uninitialized value $a[0] in hash element at ./FHEM/92_FileLog.pm line 35

[mimue]

# $Id: 92_FileLog.pm 6726 2014-10-09 17:43:44Z rudolfkoenig $

Wenn ich in einem mit createlog erzeugten Filelog der erzeugten Definition ein .* voranstelle erhalte ich "58 PERL WARNING :" - Nachrichten im Log

Also Original-DEF

Code Auswählen Erweitern

DEF ./log/blu-%Y.log blu

veränderte DEF

DEF    ./log/blu-%Y.log .*blu

Resultat im Log 29 mal

Code Auswählen Erweitern

2014.10.13 08:34:56 1: PERL WARNING: Use of uninitialized value $a[0] in hash element at ./FHEM/92_FileLog.pm line 353.
2014.10.13 08:34:56 1: PERL WARNING: Use of uninitialized value $a[0] in hash element at ./FHEM/92_FileLog.pm line 354.

mimue

[rudolfkoenig]

Habs eigentlich gefixed:

------------------------------------------------------------------------
r6726 | rudolfkoenig | 2014-10-09 19:43:44 +0200 (Thu, 09 Oct 2014) | 2 lines
09_FileLog.pm: Fix bogus eventType data (Forum #27662)

Hat aber nichts direkt mit FileLog zu tun, sondern mit kaputten Zeilen in eventTypes.
Das wiederum konnte ich weder nachvollziehen, noch fixen.

[mimue]

Habs eigentlich gefixed:

Na ja, sagen wir mal so: in der neuen Version von Heute sind die Meldungen weniger geworden
Statt 56 nur noch 8 -16

Code Auswählen Erweitern

# $Id: 92_FileLog.pm 6751 2014-10-12 11:31:37Z rudolfkoenig $
# $Id: 91_eventTypes.pm 6428 2014-08-20 11:51:27Z rudolfkoenig $

Es tritt übrigens auch auf, wenn ich in DEF an dem Dateinamen etwas verändere.

mimue

[rudolfkoenig]

Kann es nicht nachvollziehen, obwohl ich es eine Weile lang versucht habe.
Habe dafuer einen Bug mit removeRegexPart in der Detail-Ansicht behoben und eingecheckt.

[mimue]

Kann es nicht nachvollziehen, obwohl ich es eine Weile lang versucht habe.

Also ich kann es fest reproduzieren, einfachste Möglichkeit: In einem bestehenden FileLog  DEF öffnen und mit modify FileLog_... bestätigen.
Hat mir greade einen Burst von 44 Meldungen beschert.

Was kann ich helfen um es einzugrenzen ?

Code Auswählen Erweitern

Plattform Raspberry Pi B+, Debian Wheezy
perl 5, version 14, subversion 2 (v5.14.2) built for arm-linux-gnueabihf-thread-multi-64int,
$Id: fhem.pl 6730 2014-10-09 19:21:23Z rudolfkoenig $
$Id: 92_FileLog.pm 6767 2014-10-15 05:26:57Z rudolfkoenig $

mimue

[rudolfkoenig]

Hast du den Teil mit "obwohl ich es eine Weile lang versucht habe" gelesen?

[mimue]

Hast du den Teil mit "obwohl ich es eine Weile lang versucht habe" gelesen?

Ich habe es zumindest versucht

Falls Du das

Code Auswählen Erweitern

Habe dafuer einen Bug mit removeRegexPart in der Detail-Ansicht behoben und eingecheckt.

meinst, das habe ich noch nicht probiert, da ich es nicht mit dem besprochenen Problem in Verbindung gebracht habe. Werde ich gleich nachholen und berichten.

mimue

Also gut: update auf

Code Auswählen Erweitern

$Id: 92_FileLog.pm 6769 2014-10-15 17:03:30Z rudolfkoenig $

Beliebige FileLog Definition wählen, DEF aktivieren, ohne Änderung mit modify FileLog_... bestätigen,

4x

Code Auswählen Erweitern

2014.10.16 11:59:08 1: PERL WARNING: Use of uninitialized value $a[0] in hash element at ./FHEM/92_FileLog.pm line 353.
2014.10.16 11:59:08 1: PERL WARNING: Use of uninitialized value $a[0] in hash element at ./FHEM/92_FileLog.pm line 354.

biem nächsten Versuch mit anderem FileLog

8x

Code Auswählen Erweitern

2014.10.16 12:05:06 1: PERL WARNING: Use of uninitialized value $a[0] in hash element at ./FHEM/92_FileLog.pm line 353, <FH> line 40397.
2014.10.16 12:05:06 1: PERL WARNING: Use of uninitialized value $a[0] in hash element at ./FHEM/92_FileLog.pm line 354, <FH> line 40397.

[mimue]

Kann es nicht nachvollziehen, ...

Na ja im Quelltext von 92_FileLog.pm steht ja die Lösung bereits drin: Zeile 349

Code Auswählen Erweitern

     $a[1] = "" if(!defined($a[1]));

Wenn man davor

Code Auswählen Erweitern

     $a[0] = "" if(!defined($a[0]));

einfügt ist es weg. Warum sollte man auch als gottgegeben annehmen, daß eine Variable etwas enthält ?

mimue

[rudolfkoenig]

Mag alles sein, ich moechte aber vorher wissen, was das Problem verursacht.

Kannst du die Ausgabe von "get eventTypes list" _im Problemfall_ hier anhaengen?

[mimue]

Kannst du die Ausgabe von "get eventTypes list" _im Problemfall_ hier anhaengen?

Code Auswählen Erweitern

eventTypes clear
socat Sun Oct .* .*:.*:.* .* : .* pts/.* .*:.*:.* socat

socat state: Sun Oct .* .*:.*:.* .* : .* pts/.* .*:.*:.* socat

Das taucht zwar nicht unmittelbar im Zusammenhang mit den FileLog-Meldungen auf, hat mich aber veranlasst den at querySocat mal abzuschalten. (disable 1)

Nach anschließendem Neustart war der Effekt weg.

Der AT prüft ob ein bestimmtes Skript noch läuft, falls nicht, wird es erneut gestartet. Logging ist dabei (aus meiner Sicht) nicht im Spiel.

Code Auswählen Erweitern

DEF +*00:01:00 { my $t = localtime(time);; my $a = `ps -u fhem | grep socat`;; fhem "set socat $t : $a";; if ("$a" eq "") {fhem "\x22(socat -u TCP:192.168.178.1:1012 - | ./bin/fhem-readcallmonitor)\x22; set socat $t : started"}}

socat ist ein Dummy, der mir anzeigt ob und wann das Skript neu gestartet wurde.

Aktiviere ich den AT wieder, ist auch der Effekt wieder voll da.

mimue

[rudolfkoenig]

Aaah: du generierst Events mit Newlines drin, das hat bisher keiner gewagt.
Ich habe eventTypes geaendert, damit bei solchen Events alles ab der zweiten Zeile ignoriert wird.

[mimue]

Aaah: du generierst Events mit Newlines drin, das hat bisher keiner gewagt.

Ich habe eventTypes geaendert, damit bei solchen Events alles ab der zweiten Zeile ignoriert wird.

Aber was hat das jetzt konkret mit 92_FileLog.pm zu tun ? Der Effekt tritt ja (für mich sichtbar) nur bei Manipulationen an den FileLog DEFs auf.

mimue

[rudolfkoenig]

Das FileLog Detailfenster ruft get eventTypes list auf, um die select-listen fuer "set addRegexpPar" anbieten zu koennen.
Diese Liste ist korrupt, falls einzelne Eintraege Mehrzeiler sind.

[mimue]

Das FileLog Detailfenster ruft get eventTypes list auf, um die select-listen fuer "set addRegexpPar" anbieten zu koennen.

Danke

mimue

[betateilchen]

Aaah: du generierst Events mit Newlines drin, das hat bisher keiner gewagt.

Das hast Du bloß noch nicht bemerkt, mein GDS Modul macht das nämlich schon immer.
Deshalb habe ich dort von Anfang an ein Attribut eingebaut, mit dem man solche mehrzeiligen events (genauer: die gesamte Erzeugung der entsprechenden Readings) bei Problemen abschalten kann.