OWFS und FHEM hängen sich gelegentlich auf

Begonnen von dama, 26 Januar 2017, 22:14:01

Vorheriges Thema - Nächstes Thema

dama

Ich brauche einen Tipp von einem OWFS Experten...

Mein Setup erstmal:

  • Raspi 2 mit Raspbian
  • FHEM 5.7
  • USB-1wire Adapter von Denkovi
  • DS2408 Board (8-Kanal-Schalter) ebenfalls von Denkovi

Ich habe das Relais-Board als FHEM-Device eingerichtet und es arbeitet prinzipiell wie es soll.
On-top habe ich eine kleine .net Applikation entwickelt, mit deren Hilfe man die einzelnen Kanäle des Relais-Boards schalten kann. Weil dadurch letzten Endes Stromstoßrelais geschaltet werden, muss ich immer den DS2408 Kanal kurz einschalten und gleich wieder ausschalten. Jeder Schaltvorgang in der .net Applikation hat also folgende Sequenz zur Folge:

User klickt Button --> HTTP Request an FHEM mit PIO.BYTE=x (d.h. einschalten des betreffenden Kanals) --> Warte 400ms --> HTTP Request an FHEM mit PIO.BYTE=0 (ausschalten des Kanals)
Eine solche Sequenz ist in sich synchronisiert, d.h. es wird immer gewartet, bis der HTTP-Request zurückkommt, bevor der nächste Schritt gemacht wird.

Das funktioniert im Prinzip ebenfalls wie es soll, AAABER gelegentlich bleibt die ganze Sache leider hängen. Das kann man insbesondere provozieren, wenn man die einzelnen Kanäle manuell ganz schnell (z.B. im Sekundentakt) hintereinander schaltet. Der Effekt ist dann immer, dass sowohl der FHEM HTTP Server nicht erreichbar ist (Port 8083) als auch der OWFS Server (Port 2121). In einem solchen Fall erholen sie sich leider nicht mehr, sondern man muss den Raspi am besten rebooten.

Ich habe leider nahezu keine Ahnung von 1wire und OWFS. Kann mir jemand einen Tipp geben, wie ich mich der Problemursache nähern kann?
Kann man irgendwo ein Logging einschalten? Mache ich irgendwo einen Gedankenfehler? Muss ich evtl. OWFS Timing Settings anpassen?

Danke & Grüße
dama





Dr. Boris Neubert

Hallo,

ich habe keine Idee, wo das Problem herkommt. Aber ich würde an Deiner Stelle nicht über HTTP sondern über eine Socket-Verbindung auf Port 7072 (FHEM-Konsole) mit FHEM kommunizieren.

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

papa

Hast Du zufällig nonblocking beim OWServer-Device aktiviert ? Damit hatte ich auf dem BananaPi extreme Probleme. Bei mir war es meist der Zugriff auf einem DS2413. Wenn der geschalten werde sollte, ging FHEM in eine Endlosschleife. Nach Löschen des Attribute nonblocking läuft alle stabil.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

dama

Danke für eure Antworten.

Nonblocking habe ich bereits ausprobiert. Zuerst lief es mit nonblocking=0 und es kam zu Hängern. Nun habe ich vor einigen Tagen das nonblocking auf 1 gesetzt und es passiert immer noch. Möglichweise sogar öfter als zuvor. Ist im Moment eine Spekulation, weil der Zeitraum zu kurz ist.

@Boris: Die Idee mit Kommunikation über den telnet Port ist eine gute Idee. Werde ich mal ausprobieren. 

papa

Zitat von: dama am 29 Januar 2017, 14:50:24
Nonblocking habe ich bereits ausprobiert. Zuerst lief es mit nonblocking=0 und es kam zu Hängern. Nun habe ich vor einigen Tagen das nonblocking auf 1 gesetzt und es passiert immer noch. Möglichweise sogar öfter als zuvor. Ist im Moment eine Spekulation, weil der Zeitraum zu kurz ist.

Lösche das nonblocking Attribute mal ganz weg. Der Code testet auf die Existenz des Attributes.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

dama

#5
Hallo,

ich muss das Thema nochmal aufwärmen.

Ich habe zwischenzeitlich den Vorschlag von Boris befolgt und die Kommunikation zum FHEM Server auf Telnet umgestellt. Leider tritt immer noch der gleiche Effekt auf wie weiter vorher beschrieben. Schnelles Schalten der einzelnen Kanäle hintereinander erzeugt nach ein paar Klicks Delays von mehreren Sekunden und schlussendlich einen Hänger.

Hängen tut konkret FHEM (WEB-Oberfläche) und auch owhttpd (localhost:2121) und berappelt sich auch nicht von alleine (d.h. nach irgendeinem Timeout).

Jetzt die Frage an einen Linux-Experten: Wie würdet ihr so eine Situation versuchen zu diagnostizieren? Ich persönlich bin leider zu wenig bewandert in Linux als dass ich das notwendige Handwerkszeug dafür hätte... Gibt es sowas wie SysInternals Process Monitor unter Linux? Ich würde mir gerne mal die Aktivitäten des w1 Treibers bzw. von OWFS zum Beispiel gerne mal ansehen, um zu verstehen was ich evtl. falsch mache.

FHEM-Log, dmesg und top habe ich bereits bemüht, aber nichts sachdienliches darin gefunden.
top zeigt, dass sich das System quasi langweilt mit 0-2% CPU Last

Dr. Boris Neubert

@dama: ich würde zunächst außerhalb von FHEM mit dem owserver kommunizieren, um herauszufinden, ob das Problem durch das FHEM-Modul verursacht wird. Für Programme siehe hier: http://owfs.org/index.php?page=Programs (owwrite, owtap, owmon).
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!