Guten Morgen liebe Gemeinde,
ich habe kürzlich mein FHEM zum Spaß noch einmal mit Jessie auf dem RPi2 neu aufgesetzt und mit Backup eingespielt. Es läuft auch prima aber 1-2 mal am Tag hängt er sich vollkommen weg. Im Log sehe ich zuletzt noch im Sekundentakt abwechselnd:
PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4400.
Timeout for PRESENCE_DoLocalBluetoothScan reached, terminated process 8320
Nachgeschaut und hierum gehts wohl um die dritte Zeile in dieser Funktion:
foreach my $d (sort keys %defs) {
my $h = $defs{$d};
$h->{DBH}->{InactiveDestroy} = 1 if($h->{TYPE} eq 'DbLog');
TcpServer_Close($h) if($h->{SERVERSOCKET});
if($h->{DeviceName}) {
require "$attr{global}{modpath}/FHEM/DevIo.pm";
DevIo_CloseDev($h,1);
}
}
Beim Inaktiv schalten scheint also etwas schief zu gehen. Im KernelLog sehe ich zur gleichen Zeit einen Restart
Hat jemand eine Idee?
Danke euch und ein sonniges Wochenende
ciao Carlo
Viel wahrscheinlicher ist es, dass versehentlich ein unvollstaendiges device (ohne TYPE) angelegt wurde, durch ein Zugriff auf $defs{Etwas}. "Etwas" kriegt man raus durch
{ join(",",grep { !defined($defs{$_}{TYPE}) } keys %defs) }
(eingegeben in der Kommandozeile).
Oh Gott du hast recht, da ist ein Zeichen versehentlich gelöscht und schon kann er es natürlich nicht mehr finden. Verdammt! 1000 Dank, >4 Stunden suche mit einem Befehl gelöst :)
Danke Rudolf, die Essenseinladung steht noch ;)
ciao Carlo
Hallo zusammen,
ich habe eine ähnliche Fehlermeldung:
PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518
Die Eingabe von:
{ join(",",grep { !defined($defs{$_}{TYPE}) } keys %defs) }
in der FHEM Kommandozeile ergibt keine Ausgabe
Gruß
Markus
Wenn die Warnung mit einer aktuellen fhem.pl erzeugt wurde bedeutet das, dass eine DbLog Instanz kein DBH Internal hat, weil z.Bsp. keine Verbindung zur DB existiert. Ich habe nun diesen Fall auch abgefangen, ab morgen ist es per update verfuegbar.
Offenbar gibt es aktuell neue Probleme an dieser Stelle.
https://forum.fhem.de/index.php/topic,58090.0.html
Hi,
mir bringt die Zeile { join(",",grep { !defined($defs{$_}{TYPE}) } keys %defs) } folgende Ausgabe:
T: 8.5 H: 56 BAT: ok,T: 8.4 H: 56 BAT: ok
Finde das seltsam weil das kein Device ist. Sieht aus wie meldungen zu meinem Temp Sensor.
Jemand eine Idee was ich damit jetzt mache?
Gruß,
Stefan
Das Gezeigte kann von sowas wie $defs{$EVENT} kommen.
Hi rudolfkoenig,
danke für die Antwort.
Leider verstehe ich sie nicht ganz, bin noch relativ neu hier.
Ich wüsste jetzt kein Event bei mir auf die Oregon Sensoren oder habe ich das falsch verstanden?
Wie könnte ich das nun lösen?
Vielen Dank,
Stefan
Weiss ich leider auch nicht genau.
Oh, ok. Trotzdem danke.
Ich hoffe mal dass sich in den anderen 3 Themen dazu noch was tut.
Bei mir hat es erstmal ein wegstellen des Sensors gelöst.
A-cul empfängt ihn nicht mehr.
Eine Lösung ist das natürlich nicht wirklich.
Wenn sich gar nichts mehr tut bei den anderen 3en werde ich mal genauer analysieren und mit Bjoern kontakt aufnehmen.
Irgendwie muss es trotz allem mim a-cul bei mir zu tun haben.
Gruß,
Stefan
Zitat von: rudolfkoenig am 27 November 2016, 16:10:32
Weiss ich leider auch nicht genau.
Ist es denkbar, daß das 41_OREGON.pm Modul die Ursache ist?
https://github.com/RFD-FHEM/RFFHEM/blob/dev-r33/FHEM/41_OREGON.pm
Ich habe dort vor kurzem was geändert:
https://github.com/RFD-FHEM/RFFHEM/commit/4b9c2534209f7387a85b782b5848804a062bf8f5
@stefanru
Hast Du mal getestet ob der Fehler auch auftritt, wenn Du den Oregon Sensor nur mit dem Signalduino oder nur mit dem a-cul empfängst?
Gruß Ralf
Hi Ralf9,
danke für die Antwort!
Wenn er nur vom Signaludino empfangen wird ist der Fehler verschwunden.
Andersherum hab ichs noch nicht probiert.
Kann ich da nochwas für dich testen?
Ob deine Änderung der Grund sein kann weiß ich nicht genau.
Ich habe mich noch nicht so sehr mit dem pm code beschäftigt.
Gruß,
Stefan
Welche Sensoren hast Du sonst noch die so ein event
T: 8.5 H: 56 BAT: ok
erzeugen?
Von meinem Verständnis her, dürfte das Oregon Modul nicht die Ursache sein.
Ich kenne mich aber nicht so gut in Perl und fhem aus, das ich es als Ursache ausschliesen kann.
Gruß Ralf
Hi Ralf,
eigentlich nur den Oregon.
Ic habe noch einen TCM. Device GT_WT_02_183 - CODE CUL_TCM97001_183.
Den empfange ich aber nur 3 mal am Tag da er hinterm Haus ist und der macht zur Zeit auch keine Probleme.
Seit dem ich den Oregon soweit weg gehängt habe das er nur vom Signaludino empfangen wird gibts keine Probleme mehr.
Ich habe den Cul mit longid 1 und Signaludino mit longid 0 laufen.
Die sollten sich doch nicht in die quere kommen?
Kann gern nochmal rumspielen.
Orgenon sensor mit Cul und mit sduino und mit beiden wenn das hilft?
Gruß,
Stefan
Zitat von: stefanru am 28 November 2016, 21:01:38
Ich habe den Cul mit longid 1 und Signaludino mit longid 0 laufen.
Die sollten sich doch nicht in die quere kommen?
Normalerweise dürfte es egal sein, aber sicher weiß ich es nicht.
Sauberer dürfte es sein wenn der Oregon Sensor nur vom sduino oder vom cul empfangen wird. Evtl gibt es eine Möglichkeit beim cul das Oregon Protokoll rauszunehmen.
Beim sduino kann über das Attribut whitelist_IDs ganz einfach das Oregon Protokoll rausgenommen werden.
Gruß Ralf
Ah ok,
das klingt gut um mein Problem zu Lösen.
Da die Verbindung mim sduino super läuft würde ich schauen ob ich es aus dem Cul rausbekomme.
Dann habe ich eindeutig keine Fehler.
Vielen Dank!