Ich bekomme seit Tagen diese Meldung und kann nicht nachvollziehen wo sie herkommt. Ein globel stacktrace 1bringt scheinbar auch keine Antwort. Hier mal Auszüge aus dem Log rund um die Meldung:
2017.04.13 12:08:13 3: Device Bad.Fenster added to ActionDetector with 028:00 time
2017.04.13 12:09:58 3: CUL_HM set Bad.Fenster getConfig
2017.04.13 12:10:14 3: Device Bad.Fenster added to ActionDetector with 028:00 time
Use of uninitialized value $val in pattern match (m//) at fhem.pl line 3977.
Use of uninitialized value $val in pattern match (m//) at fhem.pl line 3977.
2017.04.13 10:02:25 1: HMLAN_Parse: HMLAN1 new condition disconnected
2017.04.13 10:02:25 1: HMLAN_Parse: HMLAN1 new condition init
2017.04.13 10:02:25 1: 192.168.2.27:1000 reappeared (HMLAN1)
2017.04.13 10:02:25 1: HMLAN_Parse: HMLAN1 new condition ok
Use of uninitialized value $val in pattern match (m//) at fhem.pl line 3977.
Use of uninitialized value $val in pattern match (m//) at fhem.pl line 3977.
2017.04.13 08:01:55 3: ABFALL_UPDATE
2017.04.13 08:01:58 3: CALVIEW KL.Etienne.Arbeit.Ansicht - CALENDAR:KL.Etienne.Arbeit triggered, updating CALVIEW KL.Etienne.Arbeit.Ansicht ...
2017.04.13 08:02:26 3: CALVIEW KL.Anja.Ansicht - CALENDAR:KL.Anja triggered, updating CALVIEW KL.Anja.Ansicht ...
Use of uninitialized value $val in pattern match (m//) at fhem.pl line 3977.
Use of uninitialized value $val in pattern match (m//) at fhem.pl line 3977.
Das sind nur die letzten drei gewesen. Kann da keinen Zusammenhang erkennen.
Hier der Auszug aus der fhem.pl:
sub
ReadingsNum($$$;$)
{
my ($d,$n,$default,$round) = @_;
my $val = ReadingsVal($d,$n,$default);
$val = ($val =~ /(-?\d+(\.\d+)?)/ ? $1 : "");
$val = round($val,$round) if($round);
return $val;
}
Bau bitte in fhem.pl/ReadingsNum() vor der Zeile 3977 folgendes ein:
if(!defined($val)) {
Log 1, "ERROR in ReadingsNum: undefined val for in $d/$n, default is $default";
stacktrace();
$val = "";
}
Hat sich generell irgendwas am init Verhalten von FHEM geändert?
Ich habe neuerdings auch einige Fehler die anscheinend dadurch entstehen dass http Anfragen zu früh passieren und Attribute zu früh abgefragt werden.
Habe es eingebaut und neugestartet. Werde es weiter beobachten.
Scheine den Verantwortlichen gefunden zu haben:
Use of uninitialized value $default in concatenation (.) or string at fhem.pl line 3979.
2017.04.13 14:06:06 1: ERROR in ReadingsNum: undefined val for in Homemode/.humidity, default is
2017.04.13 14:06:06 1: stacktrace:
2017.04.13 14:06:06 1: main::ReadingsNum called by ./FHEM/22_HOMEMODE.pm (1698)
2017.04.13 14:06:06 1: main::HOMEMODE_ReadingTrend called by ./FHEM/22_HOMEMODE.pm (2493)
2017.04.13 14:06:06 1: main::HOMEMODE_Weather called by ./FHEM/22_HOMEMODE.pm (131)
2017.04.13 14:06:06 1: main::HOMEMODE_Notify called by fhem.pl (3379)
2017.04.13 14:06:06 1: main::CallFn called by fhem.pl (3300)
2017.04.13 14:06:06 1: main::DoTrigger called by fhem.pl (4264)
2017.04.13 14:06:06 1: main::readingsEndUpdate called by ./FHEM/59_Weather.pm (293)
2017.04.13 14:06:06 1: main::Weather_RetrieveDataFinished called by FHEM/YahooWeatherAPI.pm (236)
2017.04.13 14:06:06 1: main::YahooWeatherAPI_RetrieveDataFinished called by FHEM/HttpUtils.pm (438)
2017.04.13 14:06:06 1: main::__ANON__ called by fhem.pl (682)
Use of uninitialized value $default in concatenation (.) or string at fhem.pl line 3979.
2017.04.13 14:06:06 1: ERROR in ReadingsNum: undefined val for in Homemode/.temperature, default is
2017.04.13 14:06:06 1: stacktrace:
2017.04.13 14:06:06 1: main::ReadingsNum called by ./FHEM/22_HOMEMODE.pm (1698)
2017.04.13 14:06:06 1: main::HOMEMODE_ReadingTrend called by ./FHEM/22_HOMEMODE.pm (2494)
2017.04.13 14:06:06 1: main::HOMEMODE_Weather called by ./FHEM/22_HOMEMODE.pm (131)
2017.04.13 14:06:06 1: main::HOMEMODE_Notify called by fhem.pl (3379)
2017.04.13 14:06:06 1: main::CallFn called by fhem.pl (3300)
2017.04.13 14:06:06 1: main::DoTrigger called by fhem.pl (4264)
2017.04.13 14:06:06 1: main::readingsEndUpdate called by ./FHEM/59_Weather.pm (293)
2017.04.13 14:06:06 1: main::Weather_RetrieveDataFinished called by FHEM/YahooWeatherAPI.pm (236)
2017.04.13 14:06:06 1: main::YahooWeatherAPI_RetrieveDataFinished called by FHEM/HttpUtils.pm (438)
2017.04.13 14:06:06 1: main::__ANON__ called by fhem.pl (682)
Werde aber nicht ganz schlau drauß. Also Homemode zieht sich von Yahoo Wetterdaten, die nicht numerisch sind? Dh ich muss den Homemode Maintainer anschreiben und drauf hinweisen?
Ich mische mich hier mal ein, da es wohl um HOMEMODE geht.
Zur Trendberechnung nutze ich ein unsichtbares Reading.
Bei der Abfrage mit ReadingsNum übergebe ich als default "undef" damit ich danach prüfen kann ob der Rückgabewert defined ist.
Das hat bisher auch immer funktioniert. Leider sehe ich aber in der Funktion ReadingsNum nicht dass der default Wert undef irgendwie abgefangen bzw. auch wieder zurück gegeben wird.
Ich denke die Ergänzung einer Zeile in ReadingsNum könnte das Problem lösen:
sub
ReadingsNum($$$;$)
{
my ($d,$n,$default,$round) = @_;
my $val = ReadingsVal($d,$n,$default);
return undef if(!defined($val));
$val = ($val =~ /(-?\d+(\.\d+)?)/ ? $1 : "");
$val = round($val,$round) if($round);
return $val;
}
Weiß aber nicht wie kompatibel es dabei bleibt.
Gruß
Dan
Habs eingebeut und eingecheckt.
Bin etwas unsicher, aber es steht nirgendwo, dass default nicht undef sein kann, und man kann es so von allen anderen Zahlen unterscheiden.
Dann danke ich fürs Lösen und werde morgen ein Update mache und schauen, ob der Fehler noch kommt.
Zitat von: rudolfkoenig am 13 April 2017, 21:06:28
Habs eingebeut und eingecheckt.
Bin etwas unsicher, aber es steht nirgendwo, dass default nicht undef sein kann, und man kann es so von allen anderen Zahlen unterscheiden.
Danke! 8)
Ich habe auch noch nirgends gelesen dass man nicht undef übergeben darf.
M.E. ist das auch der einfachste Weg um herauszufinden ob ein Reading wirklich existiert,
Gruß
Dan
Konsequenterweise sollte das dann auch mit in AttrNum aufgenommen werden. 8)
Gruß
Dan
Jaja, versteck dich ruhig hinter die Sonnenbrille, die letzte "konsequenterweise" Aenderung hat 3 oder 4 Beschwerden wegen Fehler im Log zur Folge gehabt :)
Ich glaube in diesem Fall aber eher weniger, habs deswegen auch eingecheckt.
Zitat von: rudolfkoenig am 14 April 2017, 17:04:08
Jaja, versteck dich ruhig hinter die Sonnenbrille, die letzte "konsequenterweise" Aenderung hat 3 oder 4 Beschwerden wegen Fehler im Log zur Folge gehabt :)
Ich glaube in diesem Fall aber eher weniger, habs deswegen auch eingecheckt.
Merci...
Gruß
Dan