JeeLink über Ser2Net / Fhem friert ein wenn USB Device nicht verfügbar

[fast-eddy]

Hallo zusammen,

mein Master Pi mit FHEM steht im Keller, daher möchte ich einige meiner Interfaces (CUL/FS20 und JeeLink/LaCrosse) via ser2net im Haus verteilen, um die Reichweite zu verbessern.
Die Umstellung hat soweit auch reibungslos funktioniert. Wenn allerdings ein Remote Device ausfällt (wie z.B. in den letzten Tagen durch Blitzschlag oder schlicht Wackelkontakt...) hängt sich FHEM auf.
Auch wenn das Remote-USB-Device wieder verfügbar ist, fängt sich FHEM nicht wieder und muss von Hand neugestartet werden.

Hat jemand eine Idee woran das liegen könnte oder wie ich das verhindern kann. Timout Parameter bei der Definition o.ä.?

Meine Definition in /etc/ser2net.conf sieht so aus

Code Auswählen Erweitern

#JeeLink
2003:raw:0:/dev/ttyUSB0:57600 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE


Die Device Definition in FHEM folgendermassen:

Code Auswählen Erweitern

define Remote.JeeLink JeeLink 192.168.178.25:2003
attr Remote.JeeLink flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
attr Remote.JeeLink group Gateways
attr Remote.JeeLink room SYSTEM

Bin für jede Hilfe dankbar...

Gruß,
Ralf

EDIT: Sobald das Remote USB Device abgezogen wird friert FHEM ein und lässt sich dann auch über "sudo /etc/init.d/fhem stop" nicht stoppen oder neu starten

[fast-eddy]

... bin ich denn wirklich alleine mit diesem Problem?

Habe gesehen dass es unter RFXtrx ein ähnliches Verhalten gab https://forum.fhem.de/index.php/topic,15137.msg97910.html#msg97910
Hier hat eine kleine Anpassung des Moduls 45_TRX.pm von Willi das Problem anscheinend gelöst.

Für den Fall dass ich mit dieser Fragestellung in einem Themenbereich (z.B. SlowRF oder CUL) besser aufgehoben bin, könnte dann einer der Moderatoren den Beitrag bitte verschieben?

Danke und Grüße,
Ralf

[CQuadrat]

Nicht nur beim RFXtrx sondern auch beim KM271:
https://forum.fhem.de/index.php/topic,23278.msg446077.html#msg446077

Das scheint ein generelles Problem mit per ser2net eingebundenen IO-Devices zu sein.

[fast-eddy]

Hi Christoph,

danke für Dein Feedback aber meine CUL laufen stabil über ser2net bzw. verursachen beim Abziehen keinen FHEM Freeze.
Deshalb und aufgrund der zitierten RFXtrx Threads vermute ich, dass es eher das LaCrosse Modul bzw. in Deinem Fall das
KM271 Modul die Übeltäter sind.

Daher bin ich zum Schluss gekommen dass meine Frage hier wohl im flaschen Forum gelandet ist.
Könnte einer der Moderatoren den Beitrag bitte in den LaCrosse/JeeLink Bereich (Sonstige Systeme?) verschieben ?

Danke!
Ralf

[justme1968]

ich habe an einem remote rasberry pi drei unterschiedliche cul, einen jeelink und einen panstamp.

das geschilderte problem ist bis jetzt weder beim  abziehen noch beim neu starten des rasberry aufgetreten.

kannst du mal ein strace -p <pid> an das nicht reagierende FHEM hängen und schauen was genau passiert?

gruss
  andre

[fast-eddy]

Hallo Andre,

danke für Deine Unterstützung.

Was genau meinst Du mit

schauen was genau passiert?

Die Console generiert mit strace -p <PID> eifrig Output (was auch immer...?).
Aber sobald ich den Jeelink abziehe geht nichts mehr!

Dann hilft nur noch sudo kill <pid>
Oder wolltest Du einen bestimmten Auszug des Consolen Outputs?

CU,
Ralf

[justme1968]

ja. genau. was genau gibt das strace aus wenn du den cul oder jeelink abziehst.

[fast-eddy]

... hmmm - gar nicht so einfach den Teil zu extrahieren der ab dem Zeitpunkt geschrieben wird nachdem ich den JeeLink abziehe.
Ich hoffe der für Dich wichtige Teil ist enthalten. Bin echt mal gespannt was du da rauslesen kannst... 

Btw. Wie bereits beschrieben tritt das Problem nur mit meinem JeeLink auf. Der CUL geht zwar auch auf state:disconnected kann
aber mit reopen problemlos wiederbelebt werden. Ein FHEM Freeze verursacht der CUL zumindest nicht.   

Code Auswählen Erweitern

read(33, "", 4096)                      = 0
select(40, [33], NULL, NULL, {1, 0})    = 1 (in [33], left {0, 999989})
read(33, "", 4096)                      = 0
gettimeofday({1465932712, 42904}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1465932712, 44000}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
write(4, "2016.06.14 21:31:52 1: 192.168.1"..., 94) = 94
close(33)                               = 0
gettimeofday({1465932712, 46928}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1465932712, 48089}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1465932712, 64214}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1465932712, 66086}, NULL) = 0
select(40, [6 7 8 9 11 12 13 22 25 31 36], [36], NULL, {0, 43488}) = 1 (out [36], left {0, 43435})
write(36, "\27\3\3\0\220W0\306W8\352\255\307>gC'\361rMQCn\24\320\340&{4\212\331\355"..., 149) = 149
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ea56384) = -1 ENOTTY (Inappropriate ioctl for device)
_llseek(5, 0, 0x7ea563d0, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ea56384) = -1 ENOTTY (Inappropriate ioctl for device)
_llseek(5, 0, 0x7ea563d0, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
fcntl64(5, F_SETFD, FD_CLOEXEC)         = 0
fcntl64(5, F_GETFL)                     = 0x2 (flags O_RDWR)
fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
connect(5, {sa_family=AF_INET, sin_port=htons(2003), sin_addr=inet_addr("192.168.178.25")}, 16) = -1 EINPROGRESS (Operation now in progress)
select(8, NULL, [5], NULL, {3, 0})      = 1 (out [5], left {2, 999986})
connect(5, {sa_family=AF_INET, sin_port=htons(2003), sin_addr=inet_addr("192.168.178.25")}, 16) = 0
fcntl64(5, F_GETFL)                     = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(5, F_SETFL, O_RDWR)             = 0
setsockopt(5, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
gettimeofday({1465932712, 75706}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1465932712, 76704}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
write(4, "2016.06.14 21:31:52 1: 192.168.1"..., 71) = 71
gettimeofday({1465932712, 78715}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
select(8, [5], NULL, NULL, {1, 0})      = 1 (in [5], left {0, 999986})
read(5, "", 4096)                       = 0
select(8, [5], NULL, NULL, {1, 0})      = 1 (in [5], left {0, 999989})
read(5, "", 4096)                       = 0
gettimeofday({1465932712, 81561}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1465932712, 82542}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
write(4, "2016.06.14 21:31:52 1: 192.168.1"..., 94) = 94
close(5)                                = 0
gettimeofday({1465932712, 85349}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1465932712, 86511}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1465932712, 100525}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0


[justme1968]

das schaut zumindest auf der ersten blick noch nicht auffällig aus...

kannst du mal ein fhem nur mit dem jeelink konfigurieren und es dort testen? siehst du einen unterschied in der ausgabe vor und nach dem abziehen ?

an welcher stelle hast du etwa abgezogen?

gruss
  andre

[fast-eddy]

kannst du mal ein fhem nur mit dem jeelink konfigurieren und es dort testen?

... so, damit alles isoliert nachvollziehbar ist habe ich ein jungfreuliches FHEM aufgesetzt und nur den Remote JeeLink konfiguriert.
Leider das gleiche Bild    JeeLink abgezogen -> FHEM tot !

an welcher stelle hast du etwa abgezogen?

... ziemlich genau an der Stelle als diese Zeile in der Konsole angezeigt wurde:

select(40, [33], NULL, NULL, {1, 0})    = 1 (in [33], left {0, 999989})

also ganz am Anfang des Konsolenauszuges den ich an angehängt habe.

siehst du einen unterschied in der ausgabe vor und nach dem abziehen ?

Die Ausgabe hört sofort mit Abziehen des JeeLink auf, es gibt also keinen Unterschied zu erkennen 

Um ausschließen zu können, dass mein JeeLink der Übeltäter ist habe ich das ganze Szenario auch mit einem anderen Stick (JeeLink Clone) ausprobiert
- > Leider gleiches Ergebnis d.h. es liegt nicht am Stick und ob original JeeLink oder Clone macht auch keinen Unterschied.

Ich hoffe das hilft dir trotzdem weiter. Auf jeden Fall trotzdem schon mal vielen Dank für Deine Hilfe!!!

CU,
Ralf

[fast-eddy]

Zur Sicherheit habe ich eben noch mal schnell den JeeLink lokal angelegt um zu sehen wir es sich dort verhält.
Also wenn ich den lokal definierten JeeLink abziehe passiert gar nichts! D.h. er geht nur auf state:disconnected.
Sobald ich den Stick wieder einstecke wechselt er sofort wieder auf state:initialized und kann genutzt werden.
Works as expecteted ...strange!!

CU,
Ralf

[fast-eddy]

Oben genanntes Testszenario auch nochmal mit CUL nachgesetellt. D.h. Plain FHEM via ser2net mit CUL verbunden und dann CUL abziehen
-> FHEM stürtzt in diesem Fall NICHT ab - der CUL geht nur in denZustand "disconnected" über (was ja OK ist)
-> Nach Wiedereinstecken des CUL bleibt dieser zwar im state:disconnected , kann aber über ein reopenwieder aktiviert werden

Allem Anschein nach scheint es wohl doch eher ein Problem des JeeLink-Moduls zu sein. @justme1968 oder hast Du aus dem Konsolenmitschnitt was rasulesen können?

CU,
Ralf

[justme1968]

ich schaue es mir in ruhe an wenn ich zuhause bin.

gruss
  andre

[fast-eddy]

... super!
Danke Dir schon mal im Voraus...

[rudolfkoenig]

Ich habe DevIo.pm wg. ser2net gerade geaendert, siehe https://forum.fhem.de/index.php?topic=54732

Hoffentlich bedeutet das nicht, dass FHEM mit CUL jetzt auch abstuerzt , bei mir ist das bisher nicht der Fall.