Mehrere USB-Geräte einbinden: Unterschied zwischen den Versionen
K (typo) |
Krikan (Diskussion | Beiträge) K (→Windwos: - Links zur Anbindung von USB-COM-Port Geräten) |
||
Zeile 48: | Zeile 48: | ||
== | == Windows == | ||
Links zur Anbindung von USB-COM-Port-Geräten | |||
* [https://www.uhlenbrock.de/de_DE/service/faq/software/I23A3243-001.htm!ArcEntryInfo=0004.18.I23A3243&NewServerName=zeta COM-PORT Einstellungen unter Windows 10 ändern - bebilderte Anleitung] | |||
* [http://heise.de/-2150736 Nicht angeschlossene Geräte unter Windows loswerden] | |||
* [https://www.uwe-sieber.de/comportman.html ComPortMan - Windows-Dienst zur Kontrolle über die Zuordnung von COM-Ports] | |||
* [https://www.ftdichip.com/Support/Documents/AppNotes/AN_132_Re-Assigning_COM_Port_Numbers_Using_Registry.pdf FTDI Application Note Re-Assigning COM Port Numbers Using the Windows Registry] | |||
== Hilfsmittel == | == Hilfsmittel == |
Version vom 9. Oktober 2018, 08:17 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.
An dieser Seite wird momentan noch gearbeitet. |
(Needs Editing)
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
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