FHEMWEB nicht erreichbar (da fhem CPU zu 100% auslastet?)

[thobo]

Hallo zusammen,

ich habe schon einiges versucht und gelesen, komme aber leider nicht weiter. Also ist es Zeit für meine erste Anfrage im Forum.
Ich betreibe seit ca. 6 Monaten erfolgreich ein fhem auf einem RPI 2 mit 2 selbst gelöteten CULs und einen gekauften JeeLink. Hinzu kommt noch der Homepilot, den ich über die Module von "Thomas" angebunden habe. Nun stehe ich vor der Herausforderung kostengünstig 9 Schaltmöglichkeiten im Keller haben zu wollen und zwar "sicher" d.h. bi-direktional oder direkt vom RPI heraus.

Also habe ich mir gedacht, ich setze ein 2. fhem mit einen 2. RPI 2 auf und nutze FHEM2FHEM im LOG Modus. Dazu dann noch die Arduino Relais über die GPIOs anbinden und fertig. Kosten -> ca. 50 Euro. Fand ich für 9 sicher geschaltete Kanäle ok.

Gesagt getan. Hab einen 2. Pi bestellt und alles neu aufgesetzt. Die GPIOs dem Wiki entsprechend konfiguriert und FHEM2FHEM eingerichtet. Alles läuft !! :-D Die Freude war groß, also ab in den Keller und dort schonmal testen, ob dort WLAN empfangen wird oder ob ich ein Kabel runter schmeißen muss.

Und nun geht's los.
Ich komme nach dem boot des PIs im Keller nicht mehr aufs FHEMWEB, noch reagiert das 2. fhem auf die EVENTS des 1. Ich vermutete das Netzwerk, aber selbst wieder oben angekommen bleibt es dabei, nichts geht mehr.

Also hab ich mich auf die Suche gemacht.
Folgendes habe ich bereits probiert / herausgefunden.

Der Pi ist ganz normal über SSH erreichbar!

Viel mehr hab ich zunächst nicht feststellen können, ein Stoppen und Starten von fhem hat keine Besserung gebracht.

Selbst die Wiki Seite bei FHEMWEB Problemen konnte mir nicht wirklich weiter helfen.

Irgendwann bin ich dann über einen Eintrag von Boris und Rudolf König von 2011 gestoßen und habe so einige Dinge herausfinden können. s.u.
(https://groups.google.com/forum/#!topic/fhem-users/K5OiCGY5a28)

- Seit dem weiß ich, dass mein System zu nahezu 100% ausgelastet ist und so lange dies der Fall ist, komme ich nicht auf die Website.
- fhem versucht auf ttyAMA0 zuzugreifen ist nur MEINE Vermutung, da ich die 5 in den unendlichen Selects so interpretiere. Selbst ein chmod auf 770 hat nichts gebracht.
- Im Log steht übrigens während dieser Zeit nichts drin, fhem beschäftigt sich mit sich selbst. Davor und danach sieht es allerdings komisch aus. Interpretieren kann ich es aber leider nicht zu 100%.

Ich habe es allerdings 1 mal geschafft (über einen simplen Ping auf die eigene IP, was aber wahrscheinlich nur zufällig war, da nicht reproduzierbar) den Loop zu beenden. Danach war dann fhem (bis zu nächsten) reboot des PI über FHEMWEB erreichbar.

Ich habe das ganze in die Kategorie Anfängerfragen gehängt, da FHEMWEB in der Regel Anfängerfragen sind und ich mich auch als solcher einstufe. Allerdings glaube ich nicht, dass dieses Problem einem typischen Anfänger passiert!! Ich hoffe meine Entscheidung war dennoch ok.

Vielleicht hat von euch jmd. eine Idee, was ich noch probieren könnte.
Falls Ihr weitere Daten benötigt, sagt einfach bescheid.

Vielen Dank
Thomas

RPi 2 Model B
Genutzte GPIOs 2, 3, 4, 9, 10, 11, 17, 22, 27
Raspian Jessie
fhem 5.7


$ ps auxwww | grep fhem
fhem       537 99.7  1.3  17280 13116 ?        R    09:43  25:10 perl fhem.pl fhem.cfg
thobo-pi   719  0.0  0.2   4776  1980 pts/0    S+   10:08   0:00 grep --color=auto fhem

$ sudo strace -p 537
Process 537 attached
select(8, [5], NULL, NULL, {5, 0})      = 1 (in [5], left {4, 999993})
read(5, "", 255)                        = 0
select(8, [5], NULL, NULL, {5, 0})      = 1 (in [5], left {4, 999993})
read(5, "", 255)                        = 0
select(8, [5], NULL, NULL, {5, 0})      = 1 (in [5], left {4, 999995})
read(5, "", 255)                        = 0

$ sudo ls -l /proc/537/fd
insgesamt 0
lr-x------ 1 root root 64 Mai  4 09:44 0 -> /dev/null
l-wx------ 1 root root 64 Mai  4 09:44 1 -> /opt/fhem/log/fhem-2016-05.log
l-wx------ 1 root root 64 Mai  4 09:44 10 -> /opt/fhem/log/fhem-2016-05.log
l-wx------ 1 root root 64 Mai  4 09:44 2 -> /opt/fhem/log/fhem-2016-05.log
lr-x------ 1 root root 64 Mai  4 09:44 3 -> /etc/group
l-wx------ 1 root root 64 Mai  4 09:44 4 -> /opt/fhem/log/fhem-2016-05.log
lrwx------ 1 root root 64 Mai  4 09:44 5 -> /dev/ttyAMA0
lrwx------ 1 root root 64 Mai  4 09:44 6 -> socket:[1899]
lrwx------ 1 root root 64 Mai  4 09:44 7 -> socket:[1900]
lrwx------ 1 root root 64 Mai  4 09:44 8 -> socket:[1901]
lrwx------ 1 root root 64 Mai  4 09:44 9 -> socket:[1902]

$ sudo ls -l /dev/ttyAMA0
crw--w---- 1 root tty 204, 64 Mai  4 09:42 /dev/ttyAMA0

$ grep fhem /etc/group
tty:x:5:thobo-pi,fhem


die letzten Zeilen des Logs
2016.05.04 09:17:03 3: Can't connect to 192.168.178.55:7072: Das Netzwerk ist nicht erreichbar
2016.05.04 09:17:03 1: Including ./log/fhem.save
2016.05.04 09:17:03 1: usb create starting
2016.05.04 09:17:04 3: Probing CUL device /dev/ttyAMA0
2016.05.04 09:17:04 3: Probing TCM_ESP3 device /dev/ttyAMA0
2016.05.04 09:17:04 3: Probing FRM device /dev/ttyAMA0
2016.05.04 09:42:51 1: Including fhem.cfg
2016.05.04 09:42:51 3: telnetPort: port 7072 opened
2016.05.04 09:42:52 3: WEB: port 8083 opened
2016.05.04 09:42:52 3: WEBphone: port 8084 opened
2016.05.04 09:42:52 3: WEBtablet: port 8085 opened
2016.05.04 09:42:52 2: eventTypes: loaded 618 events from ./log/eventTypes.txt
2016.05.04 09:42:52 3: FHEM2FHEM opening RemoteFhem at 192.168.178.55:7072
2016.05.04 09:42:52 3: Can't connect to 192.168.178.55:7072: Das Netzwerk ist nicht erreichbar
2016.05.04 09:42:52 1: Including ./log/fhem.save
2016.05.04 09:42:52 1: usb create starting
2016.05.04 09:42:53 3: Probing CUL device /dev/ttyAMA0
2016.05.04 09:42:53 3: Probing TCM_ESP3 device /dev/ttyAMA0
2016.05.04 09:42:53 3: Probing FRM device /dev/ttyAMA0

[Ralle]

Hallo Thomas,
du schreibst das du den PI über ssh erreichen kannst und das du vermutest das er 100% Last hat.
Hier bietet sich der Linux Befehl top an.
Damit siehst du schon mal ob dem wirklich so ist und wer der "Schuldige" ist.
Dann würde ich den schuldigen Dienst oder Tast erst mal beenden.
Wenn sich hier FHEM als der Schuldige herausstellt kann es eingentlich ja nur an der Konfiguration liegen (fhem.cfg)
Würde dann in der Verzeichnisstruktur diese cfg unter /opt/fhem mal gegen eine saubere (leere)  tauschen.

[thobo]

Hi Ralle,

ich habe es leider etwas unsauber formuliert. fhem ist tatsächlich die Ursache (das habe ich bereits herausgefunden), das sieht man auch an meinen angehängten Daten. Die Frage ist wieso!? In meiner fhem.cfg steht so gut wie nichts drin, außer das was ich tatsächlich haben möchte. Schließlich habe ich das System komplett neu aufgesetzt. Aber der Vollständigkeit halber hänge ich meine fhem.cfg mal an.

Viele Grüße
Thomas


attr global userattr cmdIcon devStateIcon devStateStyle icon sortby webCmd widg$
attr global autoload_undefined_devices 1
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 3

define telnetPort telnet 7072 global
attr telnetPort globalpassword xxxxxxxx
attr telnetPort password xxxxxxxx

define WEB FHEMWEB 8083 global
attr WEB basicAuth xxxxxxxxxxxxxxxxxxxxxxxxxx=

define WEBphone FHEMWEB 8084 global
attr WEBphone basicAuth xxxxxxxxxxxxxxxxxxxxxxxxxx=
attr WEBphone stylesheetPrefix smallscreen
define WEBtablet FHEMWEB 8085 global
attr WEBtablet basicAuth xxxxxxxxxxxxxxxxxxxxxxxxxx=
attr WEBtablet stylesheetPrefix touchpad

# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog

define autocreate autocreate
attr autocreate filelog ./log/%NAME-%Y.log
define eventTypes eventTypes ./log/eventTypes.txt

# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
define gpio2 dummy
attr gpio2 webCmd on:off
define gpio2n notify gpio2 {\
if ("$EVENT" ne "off") {\
  system("sudo fhem-gpio.sh 2 0 &");;\
} else {\
  system("sudo fhem-gpio.sh 2 1 &");;\
};;\
}
define RemoteFhem FHEM2FHEM 192.168.178.55:7072 LOG:.* xxxxxxxxxx
define gpio3n notify gpio3 {\
if ("$EVENT" ne "off") {\
  system("sudo fhem-gpio.sh 3 0 &");;\
} else {\
  system("sudo fhem-gpio.sh 3 1 &");;\
};;\

... ab hier geht es mit den restlichen GPIOs so weiter.

[Ralle]

Na dann würde ich doch mal ab der Position

Code Auswählen Erweitern

# Disable this to avoid looking for new USB devices on startup alles rausnehmen und erst mal schauen ob fhem dann läuft.

[thobo]

Hi Ralle,

habe die eine Zeile hinter dem Kommentar ebenfalls auskommentiert und siehe da, FHEMWEB ist wieder da. Das ist eine Umgehung, die für mich aktuell funktioniert. DANKE!!!

Die Frage ist, was an der dieser Zeile

define initialUsbCheck notify global:INITIALIZED usb create

falsch sein soll?? Schließlich ist sie so vorkonfiguriert gewesen und dafür da, neue USB Geräte hinzu zu fügen. Falls dem noch jmd. auf den Grund gehen möchte, ich stehe gerne für Tests bereit.
Ansonsten kann das Thema gerne geschlossen werden (oder mache ich das selber?)

Nochmal vielen Dank
Thomas

[franky08]

Such mal hier im Forum, dass ist schon sehr oft berichtet worden, dasshalb, wenn deine usb geräte eh scho definiert sind, dass usb create auzukommentieren oder zu disablen.