[Gelöst] FHEM hängt sich nach einigen Stunden auf / stürzt ab

[NehCoy]

Hallo!

Ich bin hier echt am verzweifeln! 
Bin absoluter Neuling, was FHEM angeht und habe mein Problem bereits im KNX-Bereich von diesem Forum gepostet, aber da hat sich bis jetzt noch niemand gemeldet. In der Hoffnung, dass es nicht KNX spezifisch ist frage ich hier noch mal nach, ob jemand mir helfen kann, den Fehler zu finden, warum sich FHEM nach einigen Stunden einfach aufhängt / abstürzt.   
FHEM habe ich auf einem Raspberry PI nach dieser Anleitung installiert, KNX nach der Anleitung in der FHEM-Wiki. Die KNX-Busankopplung erfolgt über TPUART USB Modul von busware.de.
Habe alle Logfiles deaktiviert, um auszuschließen, dass irgendein "Datenstau" (ist nur eine langsame Class 4 SD-Karte im Pi)  beim Schreiben der Logfiles zum Absturz führt.

Der Absturz zeichnet sich dadurch aus, dass die Webseite von FHEM weder für den PC (Port 8083), Smartphone (Port 8084) noch Tablet (Port 8085) aufgerufen werden kann.
Die grüne Status-LED des TPUART EIB/KNX blickt nur sehr schwach in ca. 500ms Rythmus. Der Pi ist über das Netzwerk erreichbar und kann Über einen SSH-Tunnel neu gestartet werden.
Nach einem Reboot leuchtet die Status LED wieder hell und FHEM ist auch wieder erreichbar.
Ist das Logfile aktiv sieht man, wann FHEM ungefähr ausgestiegen ist, da die zyklischen Statusmeldungen in der Form

Code Auswählen Erweitern

2014.01.25 15:02:22 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:02:22 3: TUL EIB refused message: 9c11142205e20080ff
2014.01.25 15:02:22 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:02:22 3: TUL EIB refused message: 9c11142205e20080ff
2014.01.25 15:02:22 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:02:22 3: TUL EIB refused message: 9c11142205e20080ff
2014.01.25 15:03:14 2: EIB EIB_4206 0644
2014.01.25 15:03:14 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:03:14 3: TUL EIB refused message: 9c11162206e300800644
2014.01.25 15:03:14 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:03:14 3: TUL EIB refused message: 9c11162206e300800644
2014.01.25 15:03:14 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:03:14 3: TUL EIB refused message: 9c11162206e300800644
2014.01.25 15:04:47 2: EIB EIB_4200 060f
2014.01.25 15:04:47 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:04:47 3: TUL EIB refused message: 9c11112200e30080060f
2014.01.25 15:04:47 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:04:47 3: TUL EIB refused message: 9c11112200e30080060f
2014.01.25 15:04:47 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:04:47 3: TUL EIB refused message: 9c11112200e30080060f
2014.01.25 15:05:52 2: EIB EIB_4101 15
2014.01.25 15:05:52 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:05:52 3: TUL EIB refused message: 9c110e2101e2008015
2014.01.25 15:05:52 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:05:52 3: TUL EIB refused message: 9c110e2101e2008015
2014.01.25 15:05:52 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:05:52 3: TUL EIB refused message: 9c110e2101e2008015
2014.01.25 15:06:23 2: EIB EIB_4202 0c40
2014.01.25 15:06:23 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:06:23 3: TUL EIB refused message: 9c11172202e300800c40
2014.01.25 15:06:23 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:06:23 3: TUL EIB refused message: 9c11172202e300800c40
2014.01.25 15:06:23 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:06:23 3: TUL EIB refused message: 9c11172202e300800c40
2014.01.25 15:06:33 2: EIB EIB_4203 ff
2014.01.25 15:06:33 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:06:33 3: TUL EIB refused message: 9c11172203e20080ff
2014.01.25 15:06:33 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:06:33 3: TUL EIB refused message: 9c11172203e20080ff
2014.01.25 15:06:33 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:06:33 3: TUL EIB refused message: 9c11172203e20080ff
2014.01.25 15:07:35 2: EIB EIB_4109 ff
2014.01.25 15:07:35 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:07:35 3: TUL EIB refused message: 9c11092109e20080ff
2014.01.25 15:07:35 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:07:35 3: TUL EIB refused message: 9c11092109e20080ff
2014.01.25 15:07:35 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:07:35 3: TUL EIB refused message: 9c11092109e20080ff
2014.01.25 15:08:37 2: EIB EIB_4207 ff
einfach aufhören. Eine richtige Absturz- oder Fehlermeldung gibt es leider nicht.

Herr Tostmann, vom Ingenieurbüro Tostmann und Inhaber von busware.de, verweist für die Lösung des Problems auf die FHEM Community.

Könnt ihr mir bitte helfen, die Fehlerursache zu identifizieren/zu finden und das Problem zu lösen?

Vielen Dank für eure Hilfe und Unterstützung!

Grüße
Neh Coy

[UliM]

Moin,
mit EIB kenn ich mich nicht aus - es wird doch aber oft von seltsamen Effekten beim RPi bercihtet, wenn dessen Stromversorgung über den Standard-Mini-USB erfolgt, da dann nur 500mA für RPi incl aller angeschlossenen Geräte zur Verfügung stehen.
Kannst Du das ausschließen? Hast Du mal Stromversorgung über die regulären USB-Anschlüsse versucht?
Gruß, Uli

[NehCoy]

Hallo UliM!

Danke für den Hinweis, aber ich wage es, die Spannungsversorgung auszuschließen.
Der Raspberry wird über ein eigens für ihn angeschafftes Netzteil versorgt:
http://www.amazon.de/Steckernetzteil-Micro-USB-1200mA-Raspberry-Pi/dp/B008XI52BS

Kann man irgendwie, irgendwo auslesen, warum/wo FHEM hängen bleibt?

Gruß
NehCoy

[Wernieman]

Wenn FHEM sich auf dem Raspi aufhänhgt, wie sieht es mit der uptime aus?

Mich wundert, das fhem "weg" sein soll, aber der Rapsi noch läuft.

P.S: wenn fhem "weg" ist, was sagt, per ssh, ein "ps aux | grep fhem"?

[NehCoy]

Nun bin ich völlig perplex! 
Als ich gestern Abend nachschauen wollte läuft der Raspberry und FHEM, als ob es nie Probleme gegeben hätte.
Mir ist aber aufgefallen, dass inzwischen 11 neue KNX Devices gefunden wurden.
Wo die auch immer her kamen. Habe die Unterlagen mit den ganzen Adressen vom Elektriker noch nicht bekommen.
Habe jetzt auch für diese neuen Geräte die Logfiles deaktiviert. Bin mal gespannt, wie das weiter geht.

Ich beobachte weiter und melde mich wieder.

Danke.

[Carsten]

Hallo,

wenn du den TUL direkt im Raspi stecken hast, würde ich empfehlen, einen aktives (!) USB-Hub dazwischen zu klemmen. Der Raspi hat nicht genügend Reserven um stromhungrige USB-Geräte zu versorgen. Das führt dann manchmal zu seltsamen Effekten.

Gruß
Carsten

[strauch]

Also ich kann nur empfehlen die Stromversorgung genau unter die Lupe zu nehmen. Ich hatte vor kurzem auch jede Menge Fehler in fhem, die letztendlich am netzteil lagen, war auch ein simples 6€ Teil mit 1,2Ampere. Hier hat mir dann einer den Tipp gegeben ein phihong Netzteil zu kaufen, ist zwar Teuer erspart aber ne Menge ärger und 2-3 billig Netzteile sind auch so teuer. Ich hab mir jetzt das hier bestellt:
http://www.reichelt.de/PSC-12R-050/3/index.html?&ACTION=3&LA=446&ARTICLE=111197
jetzt such ich noch nach einem Adapter von hohlstecker-buchse auf micro-usb. ansonsten, muss ich was basteln.

[Joachim]

@ strauch

Wenn möglich, den Pi nicht über den micro-USB Port speisen!
http://www.forum-raspberrypi.de/Thread-info-stromversorgung-raspberry-pi
entweder über den normalen USB-Port oder über die GPIO-Pinleiste.

@ all
bevor man sich irgendwelche neuen Netzteile kauft, kann man auch aus einem vorhandenen PC (Netzteil) die 5V abzweigen.
Wenn der Pi dann stabil rennt, dann Vernünftiges Netzteil für den Pi kaufen.

Gruß Joachim

[strauch]

@joachim, danke für den Tipp, dann werde ich einfach noch eine Buchse bestellen, ein Loch ins Raspberrygehäuse bohren und das mit Kabeln auf die Pfostenstecker packen: http://www.reichelt.de/HEBL-21/3/index.html?&ACTION=3&LA=446&ARTICLE=8524

[NehCoy]

Ihr habt also das Netzteil in Verdacht, das ich verwende:
http://www.amazon.de/Steckernetzteil-Micro-USB-1200mA-Raspberry-Pi/dp/B008XI52BS !? 

Verwunderlich ist, dass es zu sporadischen Fehlern kommt erst nach etlichen Stunden kommt - und in den letzten 24 Stunden gar nicht.
Und das der Pi von der instabilen Stromversorgung selbst nicht betroffen ist.
Ich würde da nämlich dann einen Reset erwarten, der auch dazu führt, dass dann FHEM neu gestartet wird und somit wieder ansprechbar ist. Es stürzt(e) ja aber nur FHEM ab, oder hängte sich auf.
Letzteres könnte wiederum von einer instabilen Spannung daher rühren, dass das TPUART USB Modul in einen ungültigen Zustand kommt und FHEM dann in irgendeiner Leseschleife hängen bleibt.

Dann könnte man so was aber versuchen in einer zukünftigen Version von FHEM softwareseitig abzufangen und das TPUART USB Modul neu starten/initialisieren...

Oder denke ich jetzt da so falsch?

Gruß
NehCoy

[Joachim]

NehCoy,
lese Dir den Link von mir durch, da werden die Probleme, die auftreten können eigentlich sehr anschaulich erklärt.
Der Pi selbst braucht nur 3,3V, die er intern mit einem StepDown Wandler herstellt, der USB-Hub, an dem auch das Lan hängt braucht 5V.
Wenn hier Instabilitäten auftreten kommt es zu mekwürdigen Phänomenen.
Wenn Du mir das nicht glaubst, mach weiter wie bisher.

Gruß Joachim

[strauch]

Also ich hatte folgende Symptome die mit einem neuen Netzteil verschwunden sind:

Empfangsprobleme mit meinem CUL für Homematic.
Absturz nach speichern der fhem.cfg
Irgendeine Änderung vorgenommen und danach nicht mehr ansprechbar.
Manchmal wurden Dinge nicht richtig geschaltet oder nicht darauf reagiert (notify)

Zum Schluss dann ganz extrem:
Keine Bildschirmausgabe aber ansprechbar per LAN
Bildschirmausgabe aber nicht mehr ansprechbar per LAN
Dateisystem mit Fehlern so das der Raspberry nicht mehr durchstartete

[NehCoy]

Hallo Jaochim,

deinen Link habe ich durchgelesen.

Dennoch stellt sich mir die Frage, ob ein -durch einen Spannungseinbruch verursachter- unzulässiger Zustand des TPUART USB Moduls dazu führt, das FHEM hängen bleibt und ob so ein Fall/Zustand durch eine Anpassung der Firmware erkannt werden und durch einen Neustart des USB Moduls behoben werden kann.

Gruß
NehCoy

[Joachim]

Aus eigener Erfahrung:
Ja, FHEM bleibt hängen, sogar soweit, dass sämtliche Standartmöglichkeiten von Linux, einen Prozess zu killen, nicht mehr greifen! Interessanterweise läuft eventuell der Pi ansonsten sauber weiter, wie von Strauch schon geschrieben wurde.
Ob man FHEM dahingehend anpassen kann? Natürlich, ist aber nach meinem dafürhalten den Aufwand nicht wert. Außerdem ist es nicht das Problem von FHEM, wenn es auf einem instabilen System läuft, dann müssen die Ursachen und nicht die Symptome beseitigt werden.

Gruß Joachim

[NehCoy]

Ja, FHEM bleibt hängen, sogar soweit, dass sämtliche Standartmöglichkeiten von Linux, einen Prozess zu killen, nicht mehr greifen! Interessanterweise läuft eventuell der Pi ansonsten sauber weiter, wie von Strauch schon geschrieben wurde.

Was ja auch genau meine Erfahrung ist.

Ob man FHEM dahingehend anpassen kann? Natürlich, ist aber nach meinem dafürhalten den Aufwand nicht wert. Außerdem ist es nicht das Problem von FHEM, wenn es auf einem instabilen System läuft, dann müssen die Ursachen und nicht die Symptome beseitigt werden.

Jain. Zwar mag jetzt die Spannungsversorgung die Ursache für das Aufhängen des TPUART USB Moduls und FHEM sein, aber war sagt, dass nicht ein anderes Ereignis ebenfalls dazu führt. Es ist doch noch nur gut, wenn FHEM so stabil läuft, dass es solche "Probleme" erkennt, meldet, protokolliert und "Gegenmaßnahmen" ergreift.
Zumindest sehe ich das so.