Hallo,
ich habe entsprechend der Anleitung von hexenmeister
(nach http://s6z.de/cms/index.php/homeautomation/fhem/23-fhem-watchdog (http://s6z.de/cms/index.php/homeautomation/fhem/23-fhem-watchdog)
und
http://forum.fhem.de/index.php/topic,17221.msg112845.html#msg112845 (http://forum.fhem.de/index.php/topic,17221.msg112845.html#msg112845))
vor längerer Zeit einen Mechanismus zum Re-Start von FHEM bei schwerwiegenden Problemen aufgesetzt. Das Ganze hat bisher sehr gut funktioniert und bei bestimmten Problemen (z.B. Modul welches bei Störungen des Internet FHEM ,,beendet") FHEM wiederbelebt.
Seit heute Nacht löst das at,
# Routine zur regelmäßigen Änderungen des Wertes des Dummy-Objektes
define tickHeartbeat at +*00:01:00 {tickHeartbeat('FHEM_Server_Heartbeat');;}
attr tickHeartbeat alignTime 00:00
welches den ,,Lebenszeichen"-Dummy inkrementiert, nicht mehr aus. Dies führt, dann erwartungsgemäß zum ständigen Neustart.
Das Kommando (aus 99_myUtils.pm)
{tickHeartbeat('FHEM_Server_Heartbeat');;}
in dem at, erhöht, wenn man es manuell aufruft, den Dummy.
Explizite
set tickHeartbeat active
und
attr tickHeartbeat disable 0
ändern nichts an dem Zustand.
An dem Mechanismus habe ich schon längere Zeit nicht geändert. Ich war gestern Abend eher auf der Suche nach der Ursache für einen plötzlichen Totalausfall von 1-Wire und owserver.
Im LOG-File sind keine relevanten Einträge.
Hat jemand einen Tipp für eine weitere Fehlersuche?
Grüße,
Mario
"attr tickHeartbeat verbose 5", und Log pruefen.
{tickHeartbeat('FHEM_Server_Heartbeat');;} kann man auch in der Eingabezeile ausfuehren, und pruefen, ob die Funktion ihre Arbeit erledigt.
Danke für die Antwort! Ja, auf die nahe liegenden Sachen kommt man manchmal nicht...
Den manuellen Aufruf der PERL-Methode hatte ich ja schon getestet.
Mal sehen was verbose bringt.
Danke,
Mario
Hallo,
leider bekomme ich mit verbose=5 auch nicht mehr Log-Einträge. Da bei mir aber zur gleichen Zeit auch andere Dinge in FHEM ausgefallen sind habe auch dort nachgesehen. Es sieht so aus, als ob alle mit Timern angetrieben Funktionen nicht mehr laufen ein zum Test angelegtes at läuft ebenso wenig wie alle andere at, WeekdayTimer etc. Weiterhin werden alle 1-Wire-Sensoren nicht mehr gepollt und andere Readings verschiedener Module werden nicht aktualisiert. In meinem kleinen Modul zur Ankopplung einer Lüftungsanlage konnte ich direkt sehe, dass die über InternalTimer getriggerte Methode zum Update der Readings nicht mehr gerufen wird.
Ich habe mal die in InternalTimer aus fhem.pl verwendete Methode gettimeofday() manuell aufgerufen. Sie liefert jeweils plausible fortlaufende Werte.
Ich bin mit meinem Debugging-Latein am Ende. Ein auf Verdacht durchgeführtes Update brachte keine Verbesserung. Das war auch nicht zu Erwarten, ad ich zum Zeitpunkt des ersten Auftretens der Symptome auch kein update durchgeführt hatte.
Gruß,
Mario
Ich vermute, dass irgendein Modul Amok laeuft: entweder wird FHEM komplett blockiert, oder die InternalTimer-Liste wurde geleert. Kann man sich per telnet/HTTP mit FHEM verbinden?
Ja, Zugriff funktioniert wie immer. Ich hatte heute nur 2 mal die Situation, dass FHEM bei 100% Rechenzeit eines Kerns nicht mehr reagierte.
Ich konnte das Problem beheben!
Ursache war das Fehlen eines über I²C (RPII2C) angebundenen Luftdrucksensors (BMP 180), den ich bei der Fehlersuche im 1-Wire-System entfernt hatte. Die Definition des zugehörigen Device (I2C_BMP180) führte zu den o.g. Erscheinungen. Eventuell kann man im entsprechenden Modul mehr Toleranz gegen solche Fälle nachrüsten.
@Rudolf: Danke für den Impuls. Ich habe nacheinander alle Devices ausschließen und so den Verursacher finden können. Da hat mir die Organisation in einigermaßen sinnvoll geordnete Include-CFG-Dateien sehr geholfen (..falls mal wieder die Diskussion pro und contra CFG-Files aufkommen sollte ;).
Grüße,
Mario
RPII2C verwendet kein select oder fork (weder direkt, noch ueber die bekannten Fhem-Dienste), d.h. es kann sich beim kommunizieren mit dem Endgeraeten verklemmen, und damit FHEM komplett (mit FHEMWEB und telnet) stoppen.
Ich kann immer noch nicht vorstellen, wieso die at's nicht funktioniert haben sollen, aber FHEMWEB/telnet.