Mehrere USB-Geräte einbinden

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.

Sofern neben FHEM noch weitere Dienste auf der Server-Hardware aktiv sind, die auf Hardware an USB-Schnittstellen zugreift (z.B. ein HM-IP-USB-Stick für eine virtualisierte CCUx oder ConBee-Dongles für deconz bzw. USB-Dongles für zigbee2mqtt betr. ZigBee), empfiehlt es sich, auch bei diesen Diensten nach Möglichkeiten zu forschen, die von diesen angesprochenen USB-Geräte auch von deren Seite eindeutig zu adressieren.

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

Nutzt man die "by-id"-Methode, empfiehlt es sich, dies für alle USB-Geräte zu verwenden. Ist man gezwungen, "by-path" zu verwenden, sollte man letzteres auf die problematischen Geräte beschränken und eindeutige Geräte weiter mit "by-id" addressieren.

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:

• https://wiki.debian.org/udev
• https://wiki.ubuntuusers.de/udev/
• https://wiki.archlinux.de/title/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

Dabei sollte nicht die VID oder PID verändert werden, Änderungen der Seriennummer oder der Produktkennung (product-string) sind jedoch gefahrlos möglich, ebenso die der Herstellerkennung (vendor-string), die allerdings ein --force-eeprom erfordert (Linux).