Hallo!
Seit Anfang dieses Jahres friert mein FHEM permanent (in der Regel alle 1.5 – 2 Stunden) ein.
Symptome:
FHEM antwortet nicht mehr beim WEB- und auch nicht beim fronthem(Smartvisu)-Zugriff, Schaltaktionen werden nicht ausgeführt, Logs werden nicht nicht mehr geschrieben.
Der Perl-FHEM-Prozess läuft jedoch, als wäre alles ok. Allerdings mit 100% CPU:
pi@raspberrypi ~ $ top
top - 19:06:10 up 8 days, 21:05, 3 users, load average: 1.07, 0.97, 0.61
Tasks: 168 total, 2 running, 166 sleeping, 0 stopped, 0 zombie
%Cpu(s): 15.5 us, 10.4 sy, 0.0 ni, 74.0 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem: 882772 total, 859700 used, 23072 free, 239740 buffers
KiB Swap: 20481000 total, 0 used, 20481000 free. 347744 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23549 fhem 20 0 64516 59248 7460 R 100.0 6.7 12:30.46 perl
23873 pi 20 0 5112 2436 2052 R 1.0 0.3 0:00.61 top
19583 fhem 20 0 41012 18860 7460 S 0.3 2.1 0:22.89 python
1 root 20 0 24216 3160 1772 S 0.0 0.4 0:40.02 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.35 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 1:09.20 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:+
7 root 20 0 0 0 0 S 0.0 0.0 2:27.82 rcu_sched
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root rt 0 0 0 0 S 0.0 0.0 0:00.28 migration/0
10 root rt 0 0 0 0 S 0.0 0.0 0:00.25 migration/1
11 root 20 0 0 0 0 S 0.0 0.0 0:12.65 ksoftirqd/1
13 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:+
14 root rt 0 0 0 0 S 0.0 0.0 0:00.21 migration/2
15 root 20 0 0 0 0 S 0.0 0.0 0:09.91 ksoftirqd/2
17 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/2:+
18 root rt 0 0 0 0 S 0.0 0.0 0:00.23 migration/3
Und der Prozess lässt sich auch nicht mehr mit /etc/init.d/fhem stop beenden – lediglich killall perl –s 9 beendet den Perl-Prozess, anschließend lässt sich FHEM wieder wie gewohnt starten und läuft einwandfrei – jedoch lediglich für 1.5 – 2 Stunden....
Nach langer Suche habe ich den Fehler mit meiner 1-Wire Installation in Zusammenhang bringen können:
Ich steuere meine Gartenberegnung und Pooltechnik über 1-Wire. Hierbei setze ich den USB-1-Wire Busmaster (FT232RL, DS2480B) und die 8-Fach Relaiskarte von Denkovi ein (DS2408) sowie DS18B20 Thermofühler.
define myOWFS OWServer localhost:4304
attr myOWFS nonblocking 1
attr myOWFS room 1-Wire
define 1W_Relais_TS OWDevice 29.46B417000000
attr 1W_Relais_TS DbLogExclude .*
attr 1W_Relais_TS IODev myOWFS
attr 1W_Relais_TS model DS2408
attr 1W_Relais_TS room 1-Wire
define Bewaesserung_Rasen readingsProxy 1W_Relais_TS:PIO.1
attr Bewaesserung_Rasen icon sani_sprinkling
attr Bewaesserung_Rasen room Bewässerung
attr Bewaesserung_Rasen setFn {"PIO.1 $CMD"}
attr Bewaesserung_Rasen setList on off
attr Bewaesserung_Rasen valueFn {$LASTCMD}
attr Bewaesserung_Rasen webCmd on:off
Dieses Setup lief letztes Jahr absolut problemlos. Nun aber habe ich die ständigen FHEM-Blockaden.
Wenn ich das 1-Wire Device OWServer deaktiviere, läuft FHEM wieder wie eh und je.
Testweise habe ich daher die 10_OWServer und 11_OWDevice mal gegen Versionen aus einem Backup aus dem letzten Jahr ausgetauscht, die definitiv liefen – das behebt den Fehler jedoch nicht.
Im Logfile habe ich zu 1-Wire lediglich
2017.05.23 06:18:11 3: myOWFS: Opening connection to OWServer localhost:4304...
2017.05.23 06:18:11 3: myOWFS: Successfully connected to localhost:4304.
2017.05.23 06:18:12 3: myOWServer: Opening connection to OWServer localhost:4304...
2017.05.23 06:18:12 3: myOWServer: Successfully connected to localhost:4304.
2017.05.29 13:54:12 1: PERL WARNING: Smartmatch is experimental at ./FHEM/11_OWDevice.pm line 581, <$fh> line 284.
Macht es Sinn, die 1-Wire Hardware auszutauschen (kann überhaupt bei defekten 1-Wire-Komponenten das FHEM so grundlegend blockiert werden?) oder kann ich den Fehler Softwareseitig weiter eingrenzen?
Viele Grüße
thorschtn
Eine gross angelegte Update- und Umbau-Aktion gestern Abend scheint das Problem gelöst zu haben. Ich werde das jetzt mal ein, zwei Tage beobachten. Sollte sich das Thema tatsächlich erledigt haben, folgt hier noch eine kurze Dokumentation der ausgeführten Schritte....