Mehrere USB-Geräte einbinden - Versionsgeschichte

Ansgru: /* FreeBSD */

2024-03-31T08:47:38Z

FreeBSD

← Nächstältere Version		Version vom 31. März 2024, 10:47 Uhr
Zeile 83:		Zeile 83:
	:<code>cat /var/run/devd.pipe </code>		:<code>cat /var/run/devd.pipe </code>
	und dann einem anschliessen des Gerätes.		und dann einem anschliessen des Gerätes.

			=== ECMD ===
			Regelmässiges Abfragen scheinen dazu zu führen, dass FHEM hängt.

	== Hilfsmittel ==		== Hilfsmittel ==

Ansgru: Hinzufügen FreeBSD

2024-03-31T08:42:33Z

Hinzufügen FreeBSD

@@ Zeile 56: / Zeile 56: @@
 * [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 ==

Beta-User: Hinweise auf externe Dienste eingefügt

2020-06-29T08:40:30Z

Hinweise auf externe Dienste eingefügt

← Nächstältere Version		Version vom 29. Juni 2020, 10:40 Uhr
Zeile 1:		Zeile 1:
	== Problembeschreibung ==		== Problembeschreibung ==
	Nutzt man an einem FHEM-Server mehrere USB-Geräte, insbesondere als [[Interface\|Interface]], ist es wichtig, diese so einzubinden, dass sie von FHEM jeweils korrekt angesprochen werden. Hierzu ist eine eindeutige Addressierung im USB-System erforderlich.		Nutzt man an einem FHEM-Server mehrere USB-Geräte, insbesondere als [[Interface\|Interface]], ist es wichtig, diese so einzubinden, dass sie von FHEM jeweils korrekt angesprochen werden. Hierzu ist eine eindeutige Addressierung im USB-System erforderlich.
			{{Hinweis\|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 ==		== Linux ==

Krikan: /* udev-Rules */ - externe Wiki-Seiten verlinkt

2018-10-09T07:28:44Z

udev-Rules: - externe Wiki-Seiten verlinkt

← Nächstältere Version		Version vom 9. Oktober 2018, 09:28 Uhr
Zeile 44:		Zeile 44:
	=== udev-Rules ===		=== 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.		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.
	~~{{Baustelle}}~~		Detaillierte Erläuterungen zu udev:
	~~(Needs Editing)~~		* [https://wiki.debian.org/udev https://wiki.debian.org/udev]
			* [https://wiki.ubuntuusers.de/udev/ https://wiki.ubuntuusers.de/udev/]
			* [https://wiki.archlinux.de/title/Udev https://wiki.archlinux.de/title/Udev]

	== Windows ==		== Windows ==

Krikan: /* Windwos */ - Links zur Anbindung von USB-COM-Port Geräten

2018-10-09T07:17:18Z

Windwos: - Links zur Anbindung von USB-COM-Port Geräten

← Nächstältere Version		Version vom 9. Oktober 2018, 09:17 Uhr
Zeile 48:		Zeile 48:


	== ~~Windwos~~ ==		== Windows ==
	~~{{Baustelle}}~~		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 ==

Beta-User: typo

2018-09-17T11:13:03Z

typo

← Nächstältere Version		Version vom 17. September 2018, 13:13 Uhr
Zeile 35:		Zeile 35:
	:<code>define Jeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0@57600</code>		:<code>define Jeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0@57600</code>

	{{Hinweis\|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.}}		{{Hinweis\|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 ===		=== Problemfälle: by-id ===

Beta-User: Hinweis auf sinnvollerweise nicht zu ändernde Angaben eingefügt

2018-09-17T11:09:54Z

Hinweis auf sinnvollerweise nicht zu ändernde Angaben eingefügt

← Nächstältere Version		Version vom 17. September 2018, 13:09 Uhr
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
			{{Hinweis\|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).}}

	== Links ==		== Links ==

Beta-User: /* CP2102 */

2018-09-17T10:48:17Z

CP2102

← Nächstältere Version		Version vom 17. September 2018, 12:48 Uhr
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 ==

Beta-User: Erste Version

2018-09-17T10:10:14Z

Erste Version

Neue Seite

== Problembeschreibung ==
Nutzt man an einem FHEM-Server mehrere USB-Geräte, insbesondere als [[Interface|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:

:<code>ls -l /dev/serial/by-id</code>

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

:<code>define CUL868 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134</code>

oder einen JeeLink

:<code>define Jeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0@57600</code>

{{Hinweis|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|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 :<code>ls -l /dev/serial/by-path</code> 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.
{{Baustelle}}
(Needs Editing)

== Windwos ==
{{Baustelle}}

== 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 [http://rtr.ca/ft232r/ 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 [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):

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 ==
<references />
[[Kategorie:FAQ]]
[[Kategorie:Other Components]]
[[Kategorie:FHEM-Verwendung]]