Gelöst: FHEM friert ein (möglicherweise im Kontext OWServer/OWDevice)

Begonnen von thorschtn, 30 Mai 2017, 12:03:29

Vorheriges Thema - Nächstes Thema

thorschtn

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
NUC - FHEM & HA
MapleCUN, Homematic, 433MHz, AB440, 1-Wire Bewässerung & Pool, Jarolift (Signalduino), Signal Messenger, Denon AVR, LG WebOS, AmazonEcho, Jura S90 (ESP8266), Sonoff, Xiaomi Mii Sauger, Worx SO500i

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....
NUC - FHEM & HA
MapleCUN, Homematic, 433MHz, AB440, 1-Wire Bewässerung & Pool, Jarolift (Signalduino), Signal Messenger, Denon AVR, LG WebOS, AmazonEcho, Jura S90 (ESP8266), Sonoff, Xiaomi Mii Sauger, Worx SO500i