Mehrere USB-Geräte einbinden: Unterschied zwischen den Versionen
Ansgru (Diskussion | Beiträge) K (→FreeBSD) |
Ansgru (Diskussion | Beiträge) K (→FreeBSD) |
(kein Unterschied)
|
Aktuelle Version vom 31. März 2024, 09:47 Uhr
Problembeschreibung
Nutzt man an einem FHEM-Server mehrere USB-Geräte, insbesondere als Interface, ist es wichtig, diese so einzubinden, dass sie von FHEM jeweils korrekt angesprochen werden. Hierzu ist eine eindeutige Addressierung im USB-System erforderlich.
Linux
Hintergrund
In einem Linux-System erfolgt die Einbindung zunächst häufig über allgemeine Standardpfade wie /dev/ttyUSB0 oder /dev/ttyACM0. Steckt man im laufenden Betrieb ein weiteres Interface ein, erscheint dieses ohne Neustart des Rechners erst einmal unter dem nächsten freien Standardpfad, also z.B. /dev/ttyUSB1. Allerdings kann es sein, dass die Zuordnung beim nächsten Systemstart genau umgekehrt ist, sich also das Gerät, das unter /dev/ttyUSB1 zu finden war, nunmehr unter /dev/ttyUSB0 zu erreichen ist. Hierdurch funktionieren die Geräte nicht mehr, wenn sie in FHEM über diese allgemeinen Schnittstellenbezeichnungen in der DEF eingebunden waren. Dies gilt vor allem dann, wenn diese völlig unterschiedliche Funktionen haben, andere Baud-Raten verwenden oder andere Initialisierungscodes erwarten.
Ensprechendes gilt, wenn die Geräte später entfernt werden und/oder danach ggf. an einem anderen USB-Port verwendet.
Da die Geräte im Verlauf der Einbindung in das USB-System einige Informationen austauschen, gibt es mehrere Möglichkeiten, dieses unerwünschte Verhalten zu unterbinden.
Nutzen der Serial ID
Um dies zu umgehen, kann man sie über ihre Serial-ID in FHEM einbinden.
Dieser Befehl zeigt die Serial-ID:
ls -l /dev/serial/by-id
Hier die Beispielausgabe eines CUL868, JeeLink, RFXtrx und eines CUL433
user@xxxx:~# ls -l /dev/serial/by-id lrwxrwxrwx 1 root root 13 Jan 9 23:34 usb-busware.de_CUL868-if00 -> ../../ttyACM0 lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0-> ../../ttyUSB0 lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-RFXCOM_RFXtrx433_A1WZWL5Y-if00-port0-> ../../ttyUSB1 lrwxrwxrwx 1 root root 13 Jan 9 21:29 usb-busware.de_CUL433-if00 -> ../../ttyACM1
Damit lässt sich folgende Definition erstellen:
z.B. für einen CUL868
define CUL868 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134
oder einen JeeLink
define Jeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0@57600
Problemfälle: by-id
Bei CULs von Busware lassen sich nur CUL433 und CUL868 unterscheiden. Zwei CUL868 haben z.B. immer die gleiche Serial-ID. Entsprechendes gilt, wenn man mehrere Produkte mit gleicher "by-id"-Kennung nutzt. Dies betrifft z.B. Arduino-Nano-Klone mit CHG340/CHG341 USB-Serial-Wandler (/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0), CP2102-Wandler (10c4:ea60) oder Prolific-Produkte.
Lösungsansätze sind weiter unten aufgeführt, man kann in solchen Fällen jedoch auch die problematischen Geräte über die Angaben einbinden, welche man über :ls -l /dev/serial/by-path
erhält.
Das Vorgehen entspricht im Übrigen dem für "by-id".
udev-Rules
Man kann mittels udev-Rules auch die Angaben zur Serial-ID und/oder der py-path dazu nutzen, den jeweiligen Geräten einen eindeutigen Namen zuzuweisen. Detaillierte Erläuterungen zu udev:
Windows
Links zur Anbindung von USB-COM-Port-Geräten
- COM-PORT Einstellungen unter Windows 10 ändern - bebilderte Anleitung
- Nicht angeschlossene Geräte unter Windows loswerden
- ComPortMan - Windows-Dienst zur Kontrolle über die Zuordnung von COM-Ports
- FTDI Application Note Re-Assigning COM Port Numbers Using the Windows Registry
FreeBSD
Hintergrund
USB zu seriell Adapter (z.B. für RS485/Modbus, Arduinos etc) tauchen unter FreeBSD als /dev/cuaU* Geräte auf. Das macht es schwierig, sie in FHEM einzubinden da sich beim Umstecken etc. der Gerätename ändern kann und dann der Adapter z.B. nicht mehr unter cuaU0 sondern unter cuaU1 etc. zu finden ist.
Nutzen der Serial ID
Unter Linux haben die Adapter eine eindeutige Kennung (z.B. als /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A10KVD0Q-if00-port0). In FreeBSD kann man das wie folgt nachbauen:
> cat /usr/local/etc/devd/rs485.conf attach 1000 { match "sernum" "AB0LHFXT|AB0MG4RO|A10KVD0Q"; action "ln -sf /dev/cua$ttyname /dev/waveshare_$sernum && ln -sf /dev/cua$ttyname.lock /dev/waveshare_$sernum.lock && ln -sf /dev/cua$ttyname.init /dev/waveshare_$sernum.init"; }; notify 1000 { match "sernum" "AB0LHFXT|AB0MG4RO|A10KVD0Q"; match "type" "DETACH"; match "subsystem" "DEVICE"; action "rm /dev/waveshare_$sernum && rm /dev/waveshare_$sernum.init && rm /dev/waveshare_$sernum.lock"; };
In diesem Beispiel sind die Adapter mit Seriennummer AB0LHFXT, AB0MG4RO oder A10KVD0Q eindeutig als /dev/waveshare_Seriennummer ansprechbar und lassen sich entsprechend in FHEM einbinden.
Die Seriennummer (oder zur Not auch der USB Pfad für Adapter, die keine Seriennummer haben (wie z.B. CH340 Chips)) lässt sich mit
usbconfig -d ugen1.11 dump_all_desc
herausfinden wenn das Gerät bereits eingesteckt ist oder aber mit einem laufenden
cat /var/run/devd.pipe
und dann einem anschliessen des Gerätes.
ECMD
Regelmässiges Abfragen scheinen dazu zu führen, dass FHEM hängt.
Hilfsmittel
CUL-firmware modifizieren
Für Original CULs sowie Klone auf ATMega32U4-Basis kann man die Kennung im Quellcode der culfw ändern, unter der sich der Microkontroller später im USB-System anmeldet.
FTDI-Chips
FTDI-Wandler sollten eigentlich von Hause aus mit einer eindeutigen Seriennummer versehen sein. Sollte dies nicht der Fall sein, kann man dies nachholen. FTDI bietet hierzu ein Tool an, unter Linux kann man hierfür ft232r_prog verwenden. Allerdings kann es insbesondere bei der Windows-Software von FTDI zu Problemen kommen, wenn es sich um einen geklonten Chip handelt.
CP2102
Für Linux ist hier ein in Python-Tool verfügbar. Beispiel für die gleichzeitige Nutzung von drei Modulen (eines davon mit bereits geänderter Kennung - dieses wird in "by-id" gelistet, das andere (noch) nicht):
lsusb Bus 002 Device 017: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light Bus 002 Device 015: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light Bus 002 Device 016: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
ls -l /dev/serial/by-path lrwxrwxrwx 1 root root 13 Jun 9 16:33 pci-0000:00:1d.0-usb-0:1.1.2:1.0-port0 -> ../../ttyUSB2 lrwxrwxrwx 1 root root 13 Jun 9 16:33 pci-0000:00:1d.0-usb-0:1.1.3:1.0-port0 -> ../../ttyUSB0 lrwxrwxrwx 1 root root 13 Jun 9 16:33 pci-0000:00:1d.0-usb-0:1.1.4:1.0-port0 -> ../../ttyUSB1 ls -l /dev/serial/by-id lrwxrwxrwx 1 root root 13 Jun 9 16:33 usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB2 lrwxrwxrwx 1 root root 13 Jun 9 16:33 usb-Silicon_Labs_Multi_TTL_RS485_0003-if00-port0 -> ../../ttyUSB0