FHEM 5.0 / DOCKSTAR / CUL V3: CUL device reappear wird nicht erkannt

[Juergen Lennefer]

Hallo,

mein neuer FHEM 5.0 auf dem Dockstar läuft immer noch im Probebetrieb,
weil ich aus zeitlichen Gründen noch nicht alle Funktionen von meinem
alten FHEM 4.1 umziehen konnte.

Die schönen neuen Plotfunktionen in PGM2 genieße ich in der
Zwischenzeit aber, sodass es mir prompt auffällt, wenn FHEM@dockstar
nichts mehr liefert. Das ist jetzt schon min. 2-mal passiert, dann
hängt sich CUL kurz ab (warum auch immer) und FHEM meldet: "/dev/
ttyACM0 disconnected, waiting to reappear"

Dann passiert nichts mehr, auch wenn /dev/ttyACM0 wieder da ist. Ich
muss dann immer FHEM stoppen und wieder starten. Als Workaround habe
ich mir einen Watchdog dafür gebastelt, aber das kann ja nicht die
Lösung sein.

Habe das eben nochmal simuliert:

CUL abgesteckt:
syslog: Nov 5 19:30:50 fhz kernel: [686315.263433] usb 1-1.2: USB
disconnect, address 5
fhemlog: 2010.11.05 19:30:50 1: /dev/ttyACM0 disconnected, waiting to
reappear

CUL eingesteckt:
syslog: Nov 5 19:30:57 fhz kernel: [686322.415960] usb 1-1.2: new
full speed USB device using orion-ehci and address 6
Nov 5 19:30:57 fhz kernel: [686322.578157] usb 1-1.2: New USB device
found, idVendor=03eb, idProduct=204b
Nov 5 19:30:57 fhz kernel: [686322.585154] usb 1-1.2: New USB device
strings: Mfr=1, Product=2, SerialNumber=0
Nov 5 19:30:57 fhz kernel: [686322.592617] usb 1-1.2: Product: CUL868
Nov 5 19:30:57 fhz kernel: [686322.596508] usb 1-1.2: Manufacturer:
busware.de
Nov 5 19:30:57 fhz kernel: [686322.707346] usb 1-1.2: configuration
#1 chosen from 1 choice
Nov 5 19:30:57 fhz kernel: [686322.737075] cdc_acm 1-1.2:1.0:
ttyACM0: USB ACM device
fhemlog: nichts!!!

Kennt das jemand? Ich habe hier im Forum nur die Probleme mit CUN
gefunden, aber da hat FHEM das Wiederverbinden mitbekommen.

Gruß,
Jürgen

[Rudolf Koenig]

> Kennt das jemand? Ich habe hier im Forum nur die Probleme mit CUN
> gefunden, aber da hat FHEM das Wiederverbinden mitbekommen.

Ich habe solche Probleme mit meinem CUL nicht, aber da ich unlaengst eine neue
Version der USB.html eingecheckt (und gelesen) habe, sind mir da genau diese
Meldungen aufgefallen: http://www.koeniglich.de/fhem/USB.html

[Juergen Lennefer]

Interessanterweise hat FHEM 4.1 auf meinem alten Server mit dem
FHZ1300PC den "reappear" immer mitbekommen ...
Also auch wenn des Device USB-bedingt verschwindet und wieder
erscheint, sollte FHEM das doch erkennen, oder?

[Rudolf Koenig]

> Also auch wenn des Device USB-bedingt verschwindet und wieder
> erscheint, sollte FHEM das doch erkennen, oder?

Eigentlich ja, man muss z.Bsp. fuer ein Firmware-Update fhem nicht mal stoppen.
Manche Distributionen neigen dazu, dem "neuen" CUL andere Namen zu geben.
Kannst Du bitte pruefen, ob das der Fall ist? Was steht denn im fhem-log drin?
Wenn nichts, dann wuerde mir das Output von "strace -p <fhem-pid>"
weiterhelfen.

[Juergen Lennefer]

Also das Device ist vor wie nach dem "disappear" /dev/ttyACM0.
Und FHEM erkennt nur den "disappear", danach nichts mehr, alles tot im
Logfile, bis auf die Befehle, die ich von externen Scripts schicke
(Heizungs-Mischer an oder aus alle 15min).
Und das USB-Kabel ist ein 3m-Kabel mit 2 Ferritkernen von Busware, der
CUL hat sogar die HF-Abschirmung und eine Lamda-1/2-Antenne. Andere
USB-Devices hängen nicht an diesem Bus, an dem Dockstar nur noch der
1GB-Stick mit dem Debian-Squeeze-OS drauf.

Den Trace mit strace schicke ich dir gleich per Mail.

Und nach dem Blick in den Trace war dann alles klar.

Ich hatte den User fhem mal in die Gruppe dialout gepackt, bei
irgendeiner Neuinstallation des fhem.5.0.deb Packages ist das wohl
wieder rausgeflogen?!

Und da das Device /dev/ttyACM0 nur root oder der Gruppe dialout
Schreibrecht gibt, war das nach dem Reappear verboten (warum auch
immer es vorher gekalppt hat).

Neuer Versuch:

2010.11.05 21:55:43 1: /dev/ttyACM0 disconnected, waiting to reappear
2010.11.05 21:56:02 0: Server shutdown
2010.11.05 21:56:06 3: CUL opening CUL1 device /dev/ttyACM0
2010.11.05 21:56:06 3: CUL device opened
2010.11.05 21:56:06 2: FHEMWEB port 8083 opened
2010.11.05 21:56:06 2: FHEMWEB port 8084 opened
2010.11.05 21:56:11 0: Server started (version 5.0 from 2010-08-15
($Id: fhem.pl,v 1.111 2010-09-30 13:12:27 rudolfkoenig Exp $), pid
13833)


Klappt! Danke für den Hinweis auf's tracen, Rudi.

Gruss,
Jürgen

[Juergen Lennefer]

Nochmal eine Ergänzung. Das Log unten sah mir doch komisch aus, und da
habe ich festgestellt, dass mein watchdog noch lief und zugeschlagen
hat.

Ohne den Watchdog funktioniert es doch nicht, d.h. die Gruppenrechte
reichen FHEM nicht!

root@fhz:~# ls -l /dev/ttyACM0
crw-rw---- 1 root dialout 166, 0 Nov 5 22:04 /dev/ttyACM0
root@fhz:~# grep fhem /etc/group
dialout:x:20:fhem
fhem:x:999:
root@fhz:~# su fhem
fhem@fhz:/root$ groups
fhem dialout

Warum geht das nicht?
Wenn ich chmod 666 /dev/ttyACM0 machen, erkennt FHEM sofort das
Device, geht also über die other-Rechte da ran. Komisch!

Gruß,
Jürgen

[Juergen Lennefer]

Schön ist das ja nicht, aber die Lösung ist, eine udev-Regel zu
setzen, die dann gleich auch ala Wiki einen Symlink anlegt:

# cat /etc/udev/rules.d/10-cul.rules
KERNEL=="ttyACM*", ATTRS{product}=="CUL868", SYMLINK+="cul868",
OWNER="fhem", GROUP="fhem", MODE="660"

Ergebnis:
# ls -l /dev/cul868
lrwxrwxrwx 1 root root 7 Nov 5 22:24 /dev/cul868 -> ttyACM0
# ls -l /dev/ttyACM0
crw-rw---- 1 fhem dialout 166, 0 Nov 5 22:26 /dev/ttyACM0

Und schon klappt's auch mit der Nachbarin (warum die Gruppe nicht
gesetzt wird, ist dann jetzt auch egal), und ohne Wachhund ;-)

Gruß,
Jürgen

[dossidr]

Hallo Zusammen,

das gleiche Problem hatte ich auch auf meinem Sheeva laufend unter
Debian Lenny.
Nach der Umleitung durch Deinen Trick mit udev, ist es auch i.O.
Super Experten hier im Forum.
Danke vielmals.

Gruß

Denny