FHEM stürzt nach Button-Drücken ab

Begonnen von schulle, 17 Juni 2017, 17:20:40

Vorheriges Thema - Nächstes Thema

schulle

Hallo zusammen,

seit neuestem funktioniert FHEM bei mir nicht mehr. Sobald ich einen Button betätige (z.B. Beleuchtung an/aus) stürzt FHEM ab und lässt sich nicht mehr laden. Ich muss dann den kompletten Raspi neustarten. Wenn ich jedoch einfach die Reiter an der linken Seite anklicke, gibt es keine Probleme.

Leider kann ich keine ausführlichere Fehlerbeschreibung geben. Gibt es ggf. Anhaltspunkte nach denen ich suchen kann? Gegebenenfalls liegt es an der neuen FHEM Version?

Kann ich eventuell der Log-Datei schon Fehler erkennen?

Sorry für die schmalen Informationen.

Viele Grüße,

schulle
__________________________________
UPDATE:

Ich habe noch ein wenig herumgeklickt und es scheint als würden nur die Bereiche faxen machen, die mittels EIBD auf mein KNX-System zugreifen. Andere Bereiche wie Webcam oder Internetradio, die nichts mit KNX zu tun haben, scheinen davon unberührt.

MKeY

in der Log datei solltest du schon etwas erkennen können, poste doch mal das, was passiert (sollte ja mit Zeitstempel möglich sein)
Wer Fehler findet, darf sie behalten!
RPi's, D1Mini
Homematic, Hue, Sonoff, Alexa, Xiaomi, ConBee
Prusa MK2.5, Prusa MK3S (MMU2S vorhanden, aber nervtötend)
Lowrider 2CNC

schulle

Also folgende Zeilen habe ich beim letzten Neustart erhalten:

017.06.17 21:21:59 1: Including fhem.cfg
2017.06.17 21:21:59 3: telnetPort: port 7072 opened
2017.06.17 21:22:00 3: WEB: port 8083 opened
2017.06.17 21:22:00 3: WEBphone: port 8084 opened
2017.06.17 21:22:00 3: WEBtablet: port 8085 opened
2017.06.17 21:22:00 2: eventTypes: loaded 385 events from ./log/eventTypes.txt
2017.06.17 21:22:00 0: Using EIB is deprecated. Please migrate to KNX soon. Module 10_EIB is not maintained any longer. If you still want to use the module EIB,
   please set the attribute useEIB to 1 within the tul-device. Please keep in mind, that 10_KNX has a changed syntax regarding the definition, arguments and readings. Please refer to the commandref.
   As well 10_EIB and 10_KNX are compatible to daemon eibd and knxd.
2017.06.17 21:22:00 3: TUL opening KNX device eibd:localhost
2017.06.17 21:22:00 3: TUL device opened
2017.06.17 21:22:02 2: ONKYO_AVR avr: Registering ONKYO_AVR for webhook URI ?/ONKYO_AVR ...
2017.06.17 21:22:02 3: Opening avr device 192.168.178.39:60128
2017.06.17 21:22:02 1: PERL WARNING: Useless use of numeric eq (==) in void context at ./FHEM/74_StreamRadio.pm line 112, <$fh> line 407.
2017.06.17 21:22:03 2: fronthem: ipc listener opened at port 16384
2017.06.17 21:22:04 1: Including ./log/fhem.save
2017.06.17 21:22:04 1: in INITIALIZED
2017.06.17 21:22:04 1: in INITIALIZED
2017.06.17 21:22:04 1: usb create starting
2017.06.17 21:22:05 3: Probing CUL device /dev/ttyAMA0
2017.06.17 21:22:05 3: Can't open /dev/ttyAMA0: Permission denied
2017.06.17 21:22:05 1: usb create end
2017.06.17 21:22:05 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2017.06.17 21:22:05 0: Featurelevel: 5.8
2017.06.17 21:22:05 0: Server started with 147 defined entities (fhem.pl:14348/2017-05-22 perl:5.020002 os:linux user:fhem pid:887)
2017.06.17 21:22:05 3: Can't connect to 192.168.178.39:60128: Illegal seek
2017.06.17 21:22:05 3: Can't connect to 192.168.178.39:60128: 192.168.178.39: No route to host
2017.06.17 21:22:05 3: ipc fronthem:127.0.0.1:52111 (ws): ws alive with pid 894


Hilft das in irgendeiner Weise weiter?

amenomade

Zitat2017.06.17 21:22:05 3: Probing CUL device /dev/ttyAMA0
2017.06.17 21:22:05 3: Can't open /dev/ttyAMA0: Permission denied
Wenn Du jetzt ein Gerät steuern willst, das über CUL kommunizieren soll, kann es nicht funktionieren.

(Ausserdem, sehe ich schwierig, ein webhook für ONKYO_AVR zu setzen, wenn ONKYO_AVR übers Netzwerk nicht erreichbar ist:
Zitat2017.06.17 21:22:05 3: Can't connect to 192.168.178.39:60128: 192.168.178.39: No route to host
aber ich glaub nicht, es ist dein Hauptproblem)
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

schulle

Hallo,

vielen Dank für die Antwort!

Ich bin leider nur ein "Anwender", deshalb die laienhaften Fragen. Ich nutze ein IP-Gateway als Schnittstelle zum KNX. Wird das Teil als trotzdem als CUL bezeichnet? Die Netzwerk-Verbindung zum Gateway steht zumindest. Wüsste auch nicht woher hier plötzlich Probleme kommen sollten.

Der Onkyo ist derzeit nicht im Netzwerk, wahrscheinlich deswegen die Fehlermeldung...

amenomade

Zitat von: schulle am 17 Juni 2017, 22:10:07
Ich nutze ein IP-Gateway als Schnittstelle zum KNX. Wird das Teil als trotzdem als CUL bezeichnet? Die Netzwerk-Verbindung zum Gateway steht zumindest.
Ne, dann nicht. Ich kenne deine Infrastruktur nicht und KNX wenig. Wenn nix über den CUL vorgesehen ist, dann ist es nicht das Problem. Aber hast Du ein CUL überhaupt? Warum sonst diese Definition mit /dev/ttyAMA0 ?
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

schulle

Also um hier etwas Licht ins Dunkle zu bringen:

Ich habe ein KNX System, welches mittels IP-Gateway (ABB) mit meinem Netzwerk verbunden ist. Ich muss eingestehen, dass evtl. Code-Schnipsel eines CUL-Sticks (aus Test-Zwecken) evtl. noch vorhanden sind.

Was mich eigentlich wundert ist, dass von jetzt auf gleich, ohne mein Einwirken die komplette KNX-Schiene in FHEM einen Absturz bewirkt. Ich klicke auf "on" und plötzlich fängt der Browser an zu laden und FHEM ist nicht mehr erreichbar. Mit anderen Funktionen innerhalb der FHEM Oberfläche (die jedoch nichts mit KNX zu tun haben) gibt es das Problem nicht. Deshalb habe ich die KNX Geschichte als Vermutung. Da jedoch von FHEM keine direkten Fehlermeldungen ausgeworfen werden, tappe ich hier noch im Dunkeln. Gibt es ggf. eine Datei die im Hintergrund bei Abstürzen Logs aufzeichnet, um hier den Grund für einen Absturz ermitteln zu können?

MKeY

2017.06.17 21:22:00 0: Using EIB is deprecated. Please migrate to KNX soon. Module 10_EIB is not maintained any longer. If you still want to use the module EIB,
   please set the attribute useEIB to 1 within the tul-device. Please keep in mind, that 10_KNX has a changed syntax regarding the definition, arguments and readings. Please refer to the commandref.
   As well 10_EIB and 10_KNX are compatible to daemon eibd and knxd.


läuft dein KNX als EIB device? bin da leider unbewandert, aber das kommt mir komisch vor.
Was sagt denn der log vorm absturz (und nicht nur beim neustart)? da müsste man doch dann fehler finden!
Wer Fehler findet, darf sie behalten!
RPi's, D1Mini
Homematic, Hue, Sonoff, Alexa, Xiaomi, ConBee
Prusa MK2.5, Prusa MK3S (MMU2S vorhanden, aber nervtötend)
Lowrider 2CNC

amenomade

Zitat von: MKeY am 17 Juni 2017, 22:41:20
Was sagt denn der log vorm absturz (und nicht nur beim neustart)? da müsste man doch dann fehler finden!
Wollte gerade das gleiche fragen. Und mit verbose >=3 und auch
attr global stacktrace 1kann man vielleicht mehr sehen.

Wenn nix in der Log, kann man evtl. gucken, was auf dem Rechner blockt. Ist ein Prozess auf 100% CPU? Mach mal dann ein "top" im Terminal, wenn fhem "abstürzt"
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

schulle

Also,

im Log erhalte ich zwar mehr Informationen durch die Anpassungen (Verbose 5, stacktrace 1) aber keinerlei Fehler beim Absturz.

Top ergibt Folgendes:

1861 fhem      20   0  381956 377860   3956 R 100.0 39.9   0:58.72 perl



Also FHEM ist nach dem Klicken eines Buttons direkt bei 100%.


Ich habe das ganze Thema schon abkürzen und ein Backup aufspielen wollen, welches regelmäßig erstellt wird. Ich habe es gemäß Anleitung durchgeführt, jedoch ist der Stand von FHEM nach Neustart wieder der komplett aktuelle. Natürlich mit Abstürzen...

Restore Backup:

Unzip tar File
sudo gunzip FHEM-20150831_142456.tar.gz
Anschließend ist das *.gz File gelöscht und es gibt ein FHEM-20150831_142456.tar file.
Stop FHEM Server
entweder über WUI mit shutdown, oder via command mit sudo /etc/init.d/fhem stop
Restore tar File
wechseln in das fhem Verzeichnis cd /opt/fhem/
sudo tar –xf FHEM-20150831_142456.tar
Restart Raspberry
Command sudo reboot (oder shutdown –r now)




schulle

So, ich glaube ich habe einen großen Schritt in die richtige Richtung getan.

Ich habe ein Backup durchführen können und bin nun auf einem Stand von vor ein paar Wochen.

Jetzt habe ich im Dashboard ein Fehler-Pop Up, das ich auch vorher hatte, jedoch (Schande über mein Haupt) bisher ignoriert und somit vergessen habe. Ich glaube, genau hier könnte das Problem liegen.

Die Fehlermeldung sagt folgendes:
dashboard.js line 680:
Uncaught ReferenceError: fhemUrl is not defined



Die entsprechende Zeile in Dashboard.js sieht bei mir folgendermaßen aus:

dashboard_getData(fhemUrl + "?cmd=get "+$('#dashboard_define').text(), "config", "json", dashboard_buildDashboard);

Ich glaube wir sind dem Problem nun auf der Schliche.