Hallo,
seit einiger Zeit habe ich das Problem, das fhem beim setzen eines Befehls über die CUL_HM_HM_OU_LED16 sofort abschmiert.
Im log via Putty erscheint beim setzen folgender Eintrag:
# Use of uninitialized value in numeric lt (<) at fhem.pl line 2806.
Can't use an undefined value as an ARRAY reference at ./FHEM/98_autocreate.pm line 140.
Nachdem ich autocreate in der fhem.cfg auskommentiert habe, läuft fhem ohne Absturz beim setzen eines Befehls über die CUL_HM_HM_OU_LED16.
In der CUL_HM_HM_OU_LED16 ist mir noch ein noReceiver Reading aufgefallen: src:1AC6BE 8002 01030200392A0000AA
Ich hoffe mir kann jemand helfen...
Grüße
Vermutlich wird ein komisches Ereignis (Event) von CUL_HM uf dem Weg geschickt, was an mehreren Stellen zu Problemen fuehrt.
> # Use of uninitialized value in numeric lt (<) at fhem.pl line 2806.
Habe eine potentielle Ursache in fhem.pl ausgebaut. Falls es nochmal auftreten soll, bitte vor diese Zeile 2806 (bzw. direkt unter dem foreach) folgendes einfuegen:
Log 1, "MISSING TIM: $duplicate{$oidx}{ION} $duplicate{$oidx}{MSG}" if(!defined($duplicate{$oidx}{TIM}));
und die Meldungen aus dem log uns mitteilen.
> Can't use an undefined value as an ARRAY reference at ./FHEM/98_autocreate.pm line 140.
Noch komischer: da wurde in der notify-Schleife (der alle potentiellen Empfaenger wie autocreate/FileLog/notify benachrichtigt) der Ereignis-Behaelter (ein Array) entfernt. Falls es nochmal auftritt, bitte in fhem.pl vor der Zeile 2492 (mit CallFn($n, "NotifyFn"...) folgendes einfuegen:
Log 1, "$n: ".int($hash->{CHANGED});
und dann FHEM mit verbose 5 starten und den Log (als .zip) posten.
Hi,
ich bin leider erst heute zum testen gekommen. Mit der neuen fhem.pl erscheinen keine Fehlermeldungen mehr auf der Konsole. Fhem stürzt dennoch ab.
Nach dem Eintrag von: Log 1, "MISSING TIM: $duplicate{$oidx}{ION} $duplicate{$oidx}{MSG}" if(!defined($duplicate{$oidx}{TIM}));
kam das in der Konsole:
# ./startfhem
......
Subroutine DispUpdate redefined at ./FHEM/99_myUtilsDisp.pm line 145, <$fh> line 6.
could not find ParserDetails.ini in /var/InternerSpeicher/fhem/lib/perl5/site_perl/5.12.2/XML/SAX
Can't use an undefined value as an ARRAY reference at ./FHEM/98_autocreate.pm line 140.
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 124.
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 124.
nach dem weiteren Eintrag von:Log 1, "$n: ".int($hash->{CHANGED});
kam das in der Konsole:
......
Use of uninitialized value in int at fhem.pl line 2492.
Can't use an undefined value as an ARRAY reference at ./FHEM/98_autocreate.pm line 140.
Ansonsten bin ich weiter ratlos... Mich wundern diese vielen noReceiver Einträge im log der Output Unit.
Die Komponenten neu gepairt habe ich auch schon mehrfach...
im Anhang der fhem log und der CUL-HM log
Grüße
Steven
Sorry, es sollte Log 1, "$n: ".int(@{$hash->{CHANGED}}); heissen, das @{} fehlt.
Ich vermute Du hast diese Zeile _NACH_ CallFn geschrieben (sonst verstehe ich die Welt nicht mehr), und
in der Notify CUL_HM_HM_LC_SW4_PCB_19BBEE_Sw_03IO wird readingsSingleUpdate() (indirekt?) aufgerufen.
Ich habe fhem.pl modifiziert, was das Problem vermeiden sollte.
Ich habe Log 1, "$n: ".int(@{$hash->{CHANGED}}); vor callFn eingefügt so wie beschrieben.
2491 next if(!defined($defs{$n})); # Was deleted in a previous notify
2492 Log 1, "$n: ".int(@{$hash->{CHANGED}});
2493 my $r = CallFn($n, "NotifyFn", $defs{$n}, $hash);
fhem schmiert weiterhin ab, sobald autocreate wieder definiert ist....
Das notify CUL_HM_HM_LC_SW4_PCB_19BBEE_Sw_03IO ruft eine Funktion auf, in der das hier steht:
sub DispCUL_HM_HM_LC_SW4_PCB_19BBEE_Sw_03()
{
my $lichtwz = $value{"SWAP_02"};
{if (Value("CUL_HM_HM_OU_LED16_1AC6BE") eq "Btn4 on (to HOMEMATIC)" and $lichtwz ne "off") {fhem ("set SWAP_02 off");;}
elsif (Value("CUL_HM_HM_OU_LED16_1AC6BE") eq "Btn4 on (to HOMEMATIC)" and $lichtwz eq "off") {fhem ("set SWAP_02 on");;}}
}
Grüße
in der Konsole kamen weiterhin die bereits genannten Fehler:
Can't use an undefined value as an ARRAY reference at fhem.pl line 2492.
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 124.
> Ich habe Log 1, "$n: ".int(@{$hash->{CHANGED}}); vor callFn eingefügt so wie beschrieben.
Das wuerde bedeuten, dass manchmal telnet (der zu dieser Zeitpunkt kein NotifyFn mehr hat), manchmal FHEMWEB (der Daten nur weitergibt) fuer das Problem verantwortlich ist -> ich kann das dann nicht nachvollziehen. In allen Faellen kam aber die oben erwaehnte CUL_HM_HM_LC_SW4_PCB_19BBEE_Sw_03IO als naechstes dran, was auch ausloest.
> Das notify CUL_HM_HM_LC_SW4_PCB_19BBEE_Sw_03IO ruft eine Funktion auf, in der das hier steht:
Das passt mir nur dann ins Bild, wenn weitere notifys gibt, die auf SWAP_02 triggern.
> fhem schmiert weiterhin ab, sobald autocreate wieder definiert ist....
Auch nach dem update von heute bzw. hast du fhem.pl gestern aus SVN geladen?
So ich habe heute morgen nach einem Update nochmal gestestet und nun tat fhem auch wieder mit autocreate sein Werk...
Ich hatte gestern wohl noch nicht die aktuelle fhem.pl
War jetzt fhem.pl die Ursache oder das komische Ereignis von CUL_HM?
vielen dank für die Hilfe und grüße aus Niederrad...
Wenn das Problem jetzt behoben ist, dann lag es daran, dass in einem von Geraet X ausgeloesten notify readings des gleichen Geraetes X (direkt oder indirekt ueber mehrere notifies) modifiziert wurden mit den readings*Update Funktionen.