Mehrere USB-Geräte einbinden: Unterschied zwischen den Versionen

Aus FHEMWiki
(Erste Version)
 
Zeile 60: Zeile 60:
=== CP2102 ===
=== CP2102 ===
Für Linux ist [http://cp210x-program.sourceforge.net/ hier] ein in Python-Tool verfügbar.
Für Linux ist [http://cp210x-program.sourceforge.net/ hier] ein in Python-Tool verfügbar.
Beispiel für die gleichzeitige Nutzung von drei Modulen (eines davon mit bereits geänderter Kennung):
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
  lsusb
Zeile 75: Zeile 75:
  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_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
  lrwxrwxrwx 1 root root 13 Jun  9 16:33 usb-Silicon_Labs_Multi_TTL_RS485_0003-if00-port0 -> ../../ttyUSB0


== Links ==
== Links ==

Version vom 17. September 2018, 11:48 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


Info blue.png
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" zu 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.


Clock - Under Construction.svg An dieser Seite wird momentan noch gearbeitet.


(Needs Editing)


Windwos

Clock - Under Construction.svg An dieser Seite wird momentan noch gearbeitet.


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

Links