Potentieller Fehler in module: "70_STV.pm"

[tinyfhem]

o  FHEM-5.5 auf Raspberry Pi
o  Bisher eine Samsung TV Remote Control konfiguriert
o  Grundsaetzlich funktioniert die Konfiguration, das TV laesst sich steuern
o  Nach dem druecken einer Taste (nachdem viele solcher Aktionen vorher funktionierten) haengt der fhem.pl process komplett
o  Am Web-UI kommt keine Rueckmeldung, Sanduhr rotiert
o  Im xterm kann kein "/etc/init.d/fhem stop" ausgefuehrt werden, das command haengt dann ebenfalls, kann aber mit Ctrl-C abgebrochen werden

Habe folgendes versucht:

root@raspberrypi:/opt/fhem/log# ps axw|grep fhem
2226 ?        S      0:20 perl fhem.pl fhem.cfg
root@raspberrypi:/opt/fhem/log# strace -p 2226
Process 2226 attached - interrupt to quit
write(11, "=\"FW_cmd('/fhem?XHR=1&cmd.rc_sam"..., 4890

An dieser Stelle hing der Process fuer ca 15min, danach kam ein "-1 ETIMEDOUT (Connection timed out)"
und der process wuerde terminiert, vermtutlich durch das zuvor ausgefuehrte /etc/init.d/fhem stop

Ist das ein bekanntes Problem? Kann ich zusaetzliche Informationen bereitstellen um das Problem besser zu verstehen?

[Gerhard]

Hi tinyfhem,

nein, das Problem ist meines Wissens nicht bekannt.

Du kannt dein Problem unter "Multimedia" -> "Fhem -> SamsungTV" (http://forum.fhem.de/index.php/topic,12988.120.html) posten (maintainer sind UliM u. Zwiebel).

Gerhard

[Zwiebel]

Hallo Tinyfhem,

ich könnte mir das verhalten vorstellen wenn der Samsung TV nicht antwortet. Timeout ist 5 Sekunden spätestens dann sollte FHEM wieder normal weiter arbeiten.
Kannst du das nachstellen? Kann es nicht vielleicht etwas anderes sein? Was gibt es noch ausser dem STV?

@ Gerhard - Wir sollten nicht alles in diesem Tread behandeln.

Gruß
Zwiebel

[tinyfhem]

ich denke man muss davon ausgehen, dass das angesprochene device (in diesem Fall Samsung-TV) mal nicht antwortet und ein timeout ist dafuer sicher eine gute Loesung. 5s erscheinen mir plausibel. Bisher konnte ich das Problem nicht reproduzieren. Ich werde es versuchen, und wenn es wieder vorkommt, mache ich erstmal kein /etc/init.d/fhem stop und warte, ob und wann dann ein timeout passiert.

Bisher war nichts anderes konfiguriert, es sind meine ersten Versuche mit fhem Im Moment experimentiere ich mit EnOcean sensors/actuators aber nichts davon war zum Zeitpunkt des Fehlers konfiguriert.

[tinyfhem]

jetzt habe ich wieder so eine Situation. Der fhem process haengt komplett, laesst sich nicht mit "/etc/init.d/fhem stop" terminieren und strace sagt:

Code Auswählen Erweitern


root@raspberrypi:/opt/fhem# ps axw|grep fhem
7629 pts/0    S      0:09 perl fhem.pl fhem.cfg
7698 pts/0    S+     0:00 grep fhem
root@raspberrypi:/opt/fhem# strace -p 7629
Process 7629 attached - interrupt to quit
read(5,

und da haengt er nun schon seit mehreren Minuten. Ausloesender Faktor war ein "get <device> counter", wobei <device> ein intelligenter Zaehler der EnBW ist, der ueber das "SML" Module eingebunden ist. Also ich denke da ist was faul in der low level communication uebers Netzwerk. Ich vermute fd "5" ist ein socket descriptor und ich wundere mich, warum da hart ein read aufgesetzt ist und kein select() ... mit entsprechendem timeout, so dass der process wieder kontrolle bekommt und der read() nicht ewig im kernel geblocked ist. Weiss nicht wie PERL das implementiert, bzw wie man dieses Verhalten aus PERL raus steuern kann aber so hats jedenfalls keinen Sinn. Habe jetzt nach ueber 15min ein kill -9 7629 abgesetzt, wenigstens dieses signal wurde behandelt und ich kann fhem nun wieder neu starten. Ok, dieser intelligente Zaehler ueber das SML Modul isf fuer mich nicht sonderlich von Bedeutung, aber nun ist das schon in zwei Modulen passiert, zuerst in STV, dann in SML. Ich hoffe das ist jetzt hier nicht OT weil es nicht mehr nur um STV sondern SML geht aber ich dachte es hat auch wenig Sinn, jetzt das ganze nochmal an anderer Stelle zu reporten. Oder sollte ich doch?

[Zwiebel]

Hallo tinyfhem,

STV und SML sind beide von mir. 
Hast du mal in die fhem.log geschaut? im SML wird die abfrage über den Intervall über non Blocking gemacht. Aber die get <device> counter nicht.  Vielleicht sollte ich da noch nacharbeiten.

Hast du sonnst Probleme mit dem Netzwerk? Kannst du etwas zu deiner Topologie sagen?

Gruß
Zwiebel

[tinyfhem]

Hallo tinyfhem,

STV und SML sind beide von mir. 
Hast du mal in die fhem.log geschaut? im SML wird die abfrage über den Intervall über non Blocking gemacht. Aber die get <device> counter nicht.  Vielleicht sollte ich da noch nacharbeiten.

Hast du sonnst Probleme mit dem Netzwerk? Kannst du etwas zu deiner Topologie sagen?

Gruß
Zwiebel

Muss gestehen, ich habe nicht in den log geschaut, weil ich implizit davon ausging, dass in dem Zustand, in dem der Process ja in einem system call hing, eh nix mehr in den log geschrieben werden kann. Da mag ich mich geirrt haben. Werde beim naechsten "hang" da reinschauen und berichten. Bzgl. network:  Die ganze Bude ist mit Cat6 verkabelt und steckt in einem HP Procurve GBE switch. Allerdings, der EnBW Zaehler haengt mit dem von denen gelieferten PowerLine Adapter drin. Vielleicht sollte ich da auch noch ein Cat6 hinlegen und den PLC ausbauen? Allerdings das andere Problem mit dem STV wuerde das ja nicht loesen. Der Samsung haengt im WLAN, das ueber einen Apple Airport bereitgestellt wird. Der Samsung hat aber auch ein RJ45, der muesste nicht zwangslaeufig funken. Zum testen kann ich den auch mal da reinstecken.

Uebrigens: Ein "get enbw counter" liefert bei mir generell ein "energy_Get: no such reading: counter", auch im good case, wenn es keinen hang gibt. Die vom Module periodisch ausgelesenen Werte sind alles plausibel, also DAYPOWER, MONTHPOWER, TOTALPOWER, YEARPOWER, avgPower,lastPower,maxPower,minPower .... das sieht alles gut aus. Mit der zusaetzlichen Beobachtung, dass sich die aufgelaufenen Werte (TOTALPOWER) auf den letzten, am Zaehler selbst gemachten reset beziehen und nicht die wirklich total aufgelaufenen Werte sind. Ob der Zaehler selbige ueberhaupt rausrueckt?