Hallo,
ich habe seit kurzem ein Problem mit meinem USB300.
Ca 6 Monate lang lief alles Problemlos, musste jedoch letzte Woche meinen NUC mit Debian neu aufsetzen.
root@nuc:~# ls -l /dev/serial/by-id
insgesamt 0
lrwxrwxrwx 1 root root 13 Okt 24 14:59 usb-FTDI_FT232R_USB_UART_A600I1JN-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Okt 24 14:59 usb-SHK_NANO_CUL_433-if00-port0 -> ../../ttyUSB1
An ttyUSB0 hängt der SignalDuino
An ttyUSB hängt der USB300
Wenn ich nun den USB300 mit define USB300 TCM ESP3 /dev/ttyUSB1@57600 einfüge, sieht erstmal alles ok aus.
Nach einem Neustart, bleibt FHEM jedoch ohne weitere Fehlermeldung hängen und ich kann des Prozess nur auf Unix-Ebene zurücksetzen.
Erst wenn ich das Device aus der Config wieder lösche, startet FHEM wie gewohnt.
Jetzt habe ich einfach mal ein getBaseID nach dem Anlegen versucht, auch da schmiert FHEM sofort ohne Rückmeldung und Logeintrag ab.
Ich weiß echt nicht mehr weiter...
PS: ich hab zwei von den Sticks, beide zeigen in FHEM das gleiche Verhalten
Hier noch ein list, unmittelbar nach dem Anlegen:
Internals:
BaseID 00000000
CFGFN
DEF ESP3 /dev/ttyUSB1@57600
DeviceName /dev/ttyUSB1@57600
FD 16
LastID 00000000
MODEL ESP3
NAME USB300
NOTIFYDEV global
NR 878
NTFY_ORDER 50-USB300
PARTIAL
STATE opened
TYPE TCM
READINGS:
2018-10-24 16:31:37 state opened
Attributes:
Ich bin auf diesem Gebiet nicht der letzte Experte, aber: nano-cul klingt nach Signalduino, und FTDI nach einem Enocean Stick.=> Ich wuerde USB0 und USB1 tauschen
Manchmal sieht man echt den Wald vor Bäumen nicht!
Alles steht klar da, aber wenn man schon daran herumdocktert, sieht man die einfachsten Dinge nicht mehr.
Vielen Dank, Rudi, das war es. Alles läuft.
Zitat von: Loki am 24 Oktober 2018, 19:11:34
Manchmal sieht man echt den Wald vor Bäumen nicht!
Alles steht klar da, aber wenn man schon daran herumdocktert, sieht man die einfachsten Dinge nicht mehr.
Vielen Dank, Rudi, das war es. Alles läuft.
Es läuft genau bis zum nächsten reboot, umstecken, neuinstallation oder usb-reset...
Deswegen sollte man ttyUSBx auch nicht benutzen (ausser evtl. für einen ersten schnellen Test), sondern by-path oder by-id verwenden oder eine Übersetzung mit udevd in den immger gleichen vorzugsweise sprechenden Device-Namen veranlassen...