"Disconnected"-Probleme bei DevIo

[Thorsten Pferdekaemper]

Hi,
bei dem von mir betreuten HM485-Modul beklagen manche Nutzer, dass es Disconnects gibt, die mit (zumindest scheinbar) unabhängigen anderen Modulen zusammenhängen. Ich habe momentan die Vermutung, dass die Disconnects von fhem selbst (bzw. DevIo.pm) hervorgerufen werden. Ich schließe auch nicht aus, dass das Modul irgendetwas bei der Verwendung von DevIo.pm falsch macht.
Das Problem scheint zu sein, dass wenn ein anderes Modul (oder irgend eine andere Funktion) Probleme mit einer TCP-Verbindung hat oder irgend etwas mit einer TCP-Verbindung macht, was lange dauert, "mein" Modul auf "Disconnected" geht.
Hat jemand eine Idee, nach was ich da schauen könnte?

(Details dazu auch hier: https://forum.fhem.de/index.php/topic,62073.0.html).
Gruß,
   Thorsten

[rudolfkoenig]

backup laeuft im Hintergrund, wenn es direkt in FHEMWEB gestartet wird, sonst nicht (ja, ich finde das auch komisch)

Eine Beeinflussung durch andere Module halte ich fuer unwahrscheinlich. Ein disconnected gibt es typischerweise dann, wenn select meldet, dass auf dem FD was los ist, sysread aber nichts bekommt. Ich gehe davon aus, dass das Problem im verlinkten Fall wiederholbar ist, indem man das Backup per at/DOIF/telnet startet. Ein parallel dazu abgesetztes "strace -p <fhem-pid>" koennte Denkanstoesse liefern.

[Thorsten Pferdekaemper]

Hi Rudi,
danke nochmal für die schnelle Antwort. Ich habe inzwischen die Vermutung, dass das Device, um das es geht, ein regelmäßiges "Keepalive"-Signal braucht. Normalerweise wird das von FHEM gesendet, aber wenn irgendetwas zu lange blockt, dann eben nicht mehr. In dem Fall schließt das Device die Verbindung von seiner Seite aus. Es sieht so aus, als ob das Schließen der Verbindung vom select als "Aktivität" gewertet wird und sozusagen ein "ready to read" zurückgibt.
Der read kommt dann natürlich mit "nichts" zurück und das Device wird auf "disconnected" gesetzt.
Klingt das irgendwie sinnvoll?
Gruß,
   Thorsten

[rudolfkoenig]

Was du schreibst, ist korrekt. Das FHEM Framework hat z.Zt. fuer das Problem keine gute Loesung parat, ausser alle zu bitten, nicht lange zu blockieren, was nicht immer funktioniert.

[Thorsten Pferdekaemper]

Hi,
da kann das FHEM-Framework eigentlich nichts dafür. ...oder anders gesagt: FHEM ist nun mal Single-Threaded und das ist (meiner Meinung nach) gut so. Für Sachen, die länger dauern, gibt es ja BlockingCall.
Danke&Gruß,
    Thorsten