/dev/tty... vs /dev/serial/by-id
-
Dieses ist im Bezug auf diesen Post von @Thomas-Braun
Da wurde sich darüber beschwert das ich etwas ketzerisch von 'einigen Experten im Forum' geschrieben habe.
Ich wollte das Thema nicht mit einer Grundsatzdiskussion belasten, aber trotzdem nochmal klarstellen warum ich diese Gebetsmühlenartige widerholung von
/dev/tty...ist veraltet, nimmdev/serial/by-id..kritisiere:- Beides funktioniert. Wenn jemand behauptet das nur eines von beidem geht dann stimmt auf dem System etwas systematisch nicht. Das eine ist nichts weiter als ein symlink auf das andere
- Für den Einsatz von beidem gibt es gute Gründe, die in der eingesetzten Hardware zu finden sind. Es ist halt nicht so das
/dev/serial/by-id/...in allen (ioBroker relevanten) Einsatzfällen besser ist. Das Gegenteil ist der Fall.
Wann ist es besser
/dev/serial/by-idals/dev/tty...zu nutzen ?- Wenn mehrere USB Schnittstelle mit vergleichbarer Signatur (
..ttyUSB0,..ttyUSB1und so weiter) genutzt werden. Nur in diesem Fall kann es passieren das bei einem Neustart die Verbindung zwischen/dev/tty...und der Hardware wechselt, sprich nach einem Reboot gehört z.Bsp./dev/ttyUSB0' zu dem Gerät welches vorher/dev/ttyUSB1` hatte.
Wann ist es besser
/dev/tty...zu nutzen ?- Wenn VM oder Container genutzt werden. Hier muss sowieso die korrekte USB Hardware an VM oder Container weiter gegeben werden. Sprich, der Umweg über den symlink verkompliziert die Geschichte nur
- Wenn das USB Gerät möglicherweise durch ein baugleiches anderes ersetzt werden soll, ohne das die Konfiguration angepasst werden muss - das geht mit dem
/dev/serial/by-id/...nicht (setzt aber voraus das genau 1 USB Device mit passender Signatur eingesetzt wird.
Wann ist es egal:
- wenn sowieso nur ein USB Device mit entsprechender Signatur im Einsatz ist.
Unter den Randbedingungen ist die Fixierung auf den deutlich längeren (und oft genug auch fehlerträchtigen) Pfad als 'den richtigen' Weg dann doch zumindest fragwürdig.
Und das die
/dev/tty...Schnittstellen in naher Zukunft entfallen sehe ich eher nicht.A.
-
Wobei sich auch jederzeit das LinkTarget ändern kann.
Ist zuletzt bei den Netzwerkinterfaces passiert. Wenn der Kerneltreiber umgeschrieben wird stehst du da.
Das System der dynamisch an die Situation angepassten Links 'by-id' dürfte sich in absehbarer aber Zeit eher nicht ändern.Man stellt das halt meiner Meinung nach direkt von vorneherein wie empfohlen ein, auch wenn man ein simples Setup mit nur einem USB-Stick hat. Dann ist man da schon richtig aufgestellt, wenn sich das Setup mal ändern sollte. Das ganze ist auch losgelöst vom zigbee-Adapter zu betrachten, es gibt ja auch noch andere Dinge, die über diese Schiene laufen.
Und wenn ich eine andere Hardware verwende, dann kann ich auch (wenn ich um die 'richtige' Einstellung weiß) dann auch den Eintrag 'by-id' an die andere Hardware anpassen. Ich muss mich ja eh mit den Einstellungen nochmal beschäftigen und schauen ob es nun läuft.
-
@asgothian Aus eigener Erfahrung: /dev/tty… funktioniert genau dann und 100% immer fehlerfrei, wenn es genau ein Gerät unter /dev/tty… gibt. Das bekommt dann immer die gleiche Nummer und es passt. Wenn man aber zwei Geräte anbeschlossen hat, dann kann es durchaus sein, dass die nach einem Reboot mal einfach die Nummer tauschen und schon passt es nicht mehr. Ich hatte das mal mit zwei CUL, einer für 433 und einer für 868. Mal war der eine unter /dev/ttyUSB0 und der andere USB1 und irgendwann mal grad andersrum. Genau deshalb empfehle auch ich /dev/serial/by-id… zu verwenden, denn das bleibt immer gleich.
Gruss, Jürgen
-
Ich sehe das ganze rein aus Praktischer Sicht eines Nutzers. Man sieht nicht was sich hinter tty/USBx für ein Gerät verbirgt, die by-id ist in der Regel Sprechend.
Also ist das selbst erklärend und man sieht sofort ob es richtig eingestellt ist.
Denn genau das Problem hatte ich mehrfach bei Benutzern die sich mit Linux wenig bis gar nicht ausgekannt haben, es war nicht ersichtlich das sich was geändert hat.
Da ist es auch Unerheblich was technisch die bessere Wahl währe.Aber alleine das wir darüber Diskutieren sollte ein eindeutiger Hinweis darauf sein, dass die Auswahl des richtigen USB Geräts in manchen Adaptern komplizierter ist als nötig.
Die Adapter sollten selbst alle passenden Geräte suchen, den Optimalen Pfad wählen und diese mit eindeutigem Namen Anzeigen. Was da im Hintergrund läuft oder über welchen Pfad das Gerät angesprochen wird sollte für den Benutzer egal sein. -
Aus ganz ähnlichen Überlegungen heraus schreibt man ja auch z. B. nach Möglichkeit nicht mehr direkt in irgendwelche Configs rein, sondern verwendet DropIn-Dateien. Dann ist es nämlich ähnlich egal, ob und was sich in der eigentlichen Config ggfls. geändert hat, die Einstellung aus service.d/01-Config oder wie auch immer das heißt greift immer, auch über Upgrades hinweg.
Und zumindest bei meiner Hardware ist der 'by-id'-Link auch sprechender:
/dev/serial/by-id/usb-Silicon_Labs_slae.sh_cc2652rb_stick_-_slaesh_s_iot_stuff_00_12_4B_00_23_93_2C_A8-if00-port0erkenne ich eher als das gewünschte Zigbee-Gerät als /dev/ttyUSB0
Ich hab das Ding nämlich bei slaesh erworben.Ich würde z. B. auch im DropDown-Menü für die Geräteauswahl auch nur die Links 'by-id' anbieten. (Die Liste ist übrigens bei meiner Instanz leer).
Es ist also nur ein Punkt neben den ganzen anderen Parametern, die ich ja auch für eine erfolgreiche Kommunikation mti dem Gerät setzen muss. Den StackType/Firmware muss ich ja beispielsweise auch anpacken, wenn sich das beim neuen Stick geändert haben sollte. -
@thomas-braun sagte in /dev/tty... vs /dev/serial/by-id:
Aus ganz ähnlichen Überlegungen heraus schreibt man ja auch z. B. nach Möglichkeit nicht mehr direkt in irgendwelche Configs rein, sondern verwendet DropIn-Dateien. Dann ist es nämlich ähnlich egal, ob und was sich in der eigentlichen Config ggfls. geändert hat, die Einstellung aus service.d/01-Config oder wie auch immer das heißt greift immer, auch über Upgrades hinweg.
Da kann ich Dir nicht folgen. Auch die Drop-In Dateien müssen ja dann zu der jeweiligen Hardware passen. Um bei dem Beispiel zu bleiben - 2 an sich baugleiche Sticks haben dann (unnötigerweise) trotzdem unterschiedliche drop-in Dateien.
Und zumindest bei meiner Hardware ist der 'by-id'-Link auch sprechender:
/dev/serial/by-id/usb-Silicon_Labs_slae.sh_cc2652rb_stick_-_slaesh_s_iot_stuff_00_12_4B_00_23_93_2C_A8-if00-port0erkenne ich eher als das gewünschte Zigbee-Gerät als /dev/ttyUSB0
Ich hab das Ding nämlich bei slaesh erworben.Sprechender, ja. Aber in einer Auswahlbox kaum anzuzeigen, weil viel zu lang. Welchen Teil davon soll ich denn dann anzeigen ? die IEEE (
00_12_4B_00_23_93_2C_A8- die spricht nicht), den Anfang (usb-Silicon_Labs_slae.sh_cc2652rb- der ist nicht eindeutig, i.e. wenn du 2 hast oder der Stick 2 Ports hat hast du 2x den gleichen Eintrag in der Liste)
Das dann auch noch automatisch so einzukürzen das es- einfach zu erkennen ist
- sich einfach gemerkt werden kann
- halbwegs universell ist
Ist dann nicht mehr trivial.
Ich denke der Konflikt wird klar.
Ich würde z. B. auch im DropDown-Menü für die Geräteauswahl auch nur die Links 'by-id' anbieten. (Die Liste ist übrigens bei meiner Instanz leer).
Da müsstest du im Log nachschauen, bzw. schauen ob der Adapter da schon läuft. Die Liste lässt sich nur füllen wenn der Adapter als Basis läuft (ein Grund für den 'zigbee automatisch starten' haken.). Sollte dann die Liste immer noch leer sein und im Log auch nichts stehen dann bräuchte ich mehr Infos zu deinem System um das zu verbessern.
Es ist also nur ein Punkt neben den ganzen anderen Parametern, die ich ja auch für eine erfolgreiche Kommunikation mti dem Gerät setzen muss. Den StackType/Firmware muss ich ja beispielsweise auch anpacken, wenn sich das beim neuen Stick geändert haben sollte.
Genau: WENN. Aber das hat der Nutzer ja in der Hand. Ich habe z.Bsp. 2 Sonoff Sticks sowie ein TI Debug board - die nutzen die gleiche Hardware, die PanID und ExtPanID sind so konfiguiert das es mit allen 3 sofort geht. Wenn es also um Ausfallsicherheit geht, dann sorgt man dafür das da alles gleich ist. Hab ich mir angewöhnt noch bei den alten cc2531, die gerne mal ihre Firmware getötet haben. Da einen 2. / 3. liegen zu haben (geflasht mit allem) heisst zigbee Instanz widerherstellen ist trivial. Abstecken, Anstecken, klappt. (ok, sauberer wäre Anhalten, abstecken, anstecken, starten - aber zumeist reicht Ab/An.)
Mit den Sonoffs kann ich wieder ganz nach Belieben umstecken. Auch wenn ich das bisher nicht gebraucht hab.
A.
-
@wildbill sagte in /dev/tty... vs /dev/serial/by-id:
@asgothian Aus eigener Erfahrung: /dev/tty… funktioniert genau dann und 100% immer fehlerfrei, wenn es genau ein Gerät unter /dev/tty… gibt. Das bekommt dann immer die gleiche Nummer und es passt. Wenn man aber zwei Geräte anbeschlossen hat, dann kann es durchaus sein, dass die nach einem Reboot mal einfach die Nummer tauschen und schon passt es nicht mehr. Ich hatte das mal mit zwei CUL, einer für 433 und einer für 868. Mal war der eine unter /dev/ttyUSB0 und der andere USB1 und irgendwann mal grad andersrum. Genau deshalb empfehle auch ich /dev/serial/by-id… zu verwenden, denn das bleibt immer gleich.
Gruss, Jürgen
genau das schrieb ich ja oben. 2 Geräte auf /dev/ttyUSBx ist der Fall wo /dev/serial/by-id klar die bessere Lösung ist.
A.
-
@thomas-braun sagte in /dev/tty... vs /dev/serial/by-id:
Wobei sich auch jederzeit das LinkTarget ändern kann.
Ist zuletzt bei den Netzwerkinterfaces passiert. Wenn der Kerneltreiber umgeschrieben wird stehst du da.
Das System der dynamisch an die Situation angepassten Links 'by-id' dürfte sich in absehbarer aber Zeit eher nicht ändern.Ja, das kann passieren. Und nein, das mit dem by-id ist davor genausowenig gefeit wie die direkten Link Targets. Ist also meiner Meinung nach ein leeres Argument.
Beide können eine Änderung erfahren - wenn das passiert hat man pech gehabt.
@thomas-braun sagte in /dev/tty... vs /dev/serial/by-id:
Und wenn ich eine andere Hardware verwende, dann kann ich auch (wenn ich um die 'richtige' Einstellung weiß) dann auch den Eintrag 'by-id' an die andere Hardware anpassen. Ich muss mich ja eh mit den Einstellungen nochmal beschäftigen und schauen ob es nun läuft.
Es geht nicht darum "eine andere" Hardware sondern "eine andere Instanz der gleichen Hardware" zu verwenden - da muss ich nicht umkonfigurieren. Wenn es vorher lief und richtig konfiguriert war läuft es hinterher auch.
-
Mir sind das zu viele WENNs.
Ein einmal sauber eingerichteter Link 'by-id' landet IMMER zu 100% auf dem definierten Gerät.Wenn ich auf /dev/ttyXYZ gehe, dann kann da mit unterschiedlicher Wahrscheinlichkeit auch ein anderes Gerät liegen. Das hat der Nutzer nämlich nicht in der Hand, das entscheidet udev/der Kernel.
-
@jey-cee sagte in /dev/tty... vs /dev/serial/by-id:
Aber alleine das wir darüber Diskutieren sollte ein eindeutiger Hinweis darauf sein, dass die Auswahl des richtigen USB Geräts in manchen Adaptern komplizierter ist als nötig.
Die Adapter sollten selbst alle passenden Geräte suchen, den Optimalen Pfad wählen und diese mit eindeutigem Namen Anzeigen. Was da im Hintergrund läuft oder über welchen Pfad das Gerät angesprochen wird sollte für den Benutzer egal sein.Dem stimme ich voll zu. Das ist aber insbesondere OS / Distributionsübergreifend kaum zu realisieren - zumindest im Zigbee Adapter. Der Wildwuchs ist da zu gross und die Identifikation klappt nur bedingt.
Wenn alle nur auf Debian arbeiten würden könnte es noch gehen, wenn denn alle Signaturen im Adapter hinterlegt würden, oder wenn die Firmwares entsprechende Abfragen sauber unterstützen. Die Tatsache das das Onboarding bei Z2M nur in einem Teil der Fälle wirklich klappt ist da durchaus sprechend.
A.
-
@asgothian sagte in /dev/tty... vs /dev/serial/by-id:
Und nein, das mit dem by-id ist davor genausowenig gefeit wie die direkten Link Targets.
Das stimmt ja nun nicht. Wenn entschieden wird, das ein Chipsatz statt auf /dev/ttyUSBx besser auf /dev/ttyACM aufgehobe ist, dann wird das im Treiber und/oder in der udev-Regel so angepasst. Könnte z. B. bei einer neuen Version von systemd passieren. Der 'by-id'-Link zeigt dann aber automagisch auf die andere Geräte-Datei, ganz ohne mein Zutun.
Das setzt nur voraus, das man einmalig bei der Einrichtung auch diesen Link angibt. -
@thomas-braun sagte in /dev/tty... vs /dev/serial/by-id:
Der 'by-id'-Link zeigt dann aber automagisch auf die andere Geräte-Datei, ganz ohne mein Zutun.
so lange bis entschieden wird das die Struktur der /dev/..../by_id vielleicht doch besser anders aufgebaut werden sollte. Auch da ist eine Konfiguration / regel / software hinter. Da haben sich Leute was bei gedacht. So wie auch bei der USB / AMA / ACM einodnung. Wer sagt mir das die Meinungen da so bleiben ?
Und im Ernst - mir ist bisher noch kein USB Gerät von USB zu AMA zu ACM gesprungen. (Edit : Klarstellung - bei Beibehalten der gleichen Distro)
A.
-
@asgothian Flexibilität, Fluch und Segen.
-
@jey-cee sagte in /dev/tty... vs /dev/serial/by-id:
@asgothian Flexibilität, Fluch und Segen.
Exakt.
-
@thomas-braun sagte in /dev/tty... vs /dev/serial/by-id:
Mir sind das zu viele WENNs.
Ein einmal sauber eingerichteter Link 'by-id' landet IMMER zu 100% auf dem definierten Gerät.Wenn ich auf /dev/ttyXYZ gehe, dann kann da mit unterschiedlicher Wahrscheinlichkeit auch ein anderes Gerät liegen. Das hat der Nutzer nämlich nicht in der Hand, das entscheidet udev/der Kernel.
Dem kann ich zu 100% zustimmen. Insbesondere dem 1. Teil: Dir sind das zu viele Wenns.
Das reicht mir aber nicht die Behauptung aufzustellen das diese Einstellung die richtige ist die alle benutzen sollen
A.
-
@asgothian sagte in /dev/tty... vs /dev/serial/by-id:
Da haben sich Leute was bei gedacht.
Ja, und das Ergebnis ist vorhersagbar. Im Gegensatz zur direkten Geräte-Datei, die kann mal hier und mal da landen.
Deswegen hat man ja auch vor einiger Zeit diese sehr sperrigen 'predictable network interfaces' eingeführt.
Die sind nämlich genauso stabil und vorhersehbar wie die by-id-Links.
Das ganze ist für Endanwender aber zugegeben auch zunächst komplizierter als einfach /dev/eth0 anzusprechen (Und davon auszugehen, dass die Netzwerkkarte schon da liegen wird, hat sie ja sonst auch immer).
Der Auslöser für diese Umstellung waren aber ganz ähnliche Überlegungen. Man will eine stabile, ganz eindeutige Adressierung der Geräte haben.Kannst du hier sehr ausführlich erklärt nachlesen:
https://systemd.io/PREDICTABLE_INTERFACE_NAMES/
Lässt sich 1:1 auf die seriellen USB-Interfaces anwenden. Die Problematik ist die gleiche.Aus dem obigen Link:
Does this have any drawbacks? Yes, it does. Previously it was practically guaranteed that hosts equipped with a single ethernet card only had a single eth0 interface. With this new scheme in place, an administrator now has to check first what the local interface name is before they can invoke commands on it, where previously they had a good chance that eth0 was the right name.
Ersetze eth0 durch ttyUSBx dann passt es. Eine 'good chance that ttyUSB0 was the right name' reicht nicht aus, man will ja genau das bestimmte Gerät treffen. Und das geht nur über dessen ID.
-
@asgothian sagte in /dev/tty... vs /dev/serial/by-id:
Und im Ernst - mir ist bisher noch kein USB Gerät von USB zu AMA zu ACM gesprungen. (Edit : Klarstellung - bei Beibehalten der gleichen Distro)
jetzt sag ich doch was dazu, gerade nach dem edit:
lang ist's her, da hatte ich keine Ahnung von /by-id/ & co, und nur 1 USB Gerät. selbst da lief es manchmal nach Neustart nicht, erst nach erneutem Neustart.
seit ich /by-id/ kenne nutze ich es, und weder bei der Umstellung von USB0 nach AMA0 usw. habe ich nie Probleme gehabt, und auch beim Umzug von verschiedenen Hardware nicht.
Mittlerweile nutze ich einen aktiven Hub mit 4 USB Geräten und kann die Hardware und die Distro wechseln und brauche nur den Hub umzustecken -
Im weiteren verweise ich nur noch auf die Anleitung von zigbee2mqtt, wie man das richtig konfiguriert.
Da haben die sich mit Sicherheit nämlich auch was bei gedacht, das so "umständlich" über 'by-id' anzulegen:https://www.zigbee2mqtt.io/guide/configuration/adapter-settings.html#basic-configuration
-
Also ich denke, das der Standard schon eher die persistente Benennung von Interfaces/Hardwares etc. sein sollte.
Die Experten haben eher Ahnung wo sie suchen sollen, falls sich da mal eine Interface ID ändert.
Die meisten User hier, haben aber davon keine Ahnung, warum das selbe Gerät plötzlich USB1 und nicht mehr wie immer USB0 heißt. Dann kann man denen sicherlich von irgendwelchen Race Conditions im Kernel erzählen, weil sie evtl eine Software/Treiber installiert haben, die da einen Einfluss hat. Ihr werdert das aber auch nicht für den User analysieren. Helfen tuts dem User ebenfalls nicht. Schlauer werden sie dadurch nur bedingt.Viele hier sind von Linux schon überfordert und sind froh, das sie einigermaßen die Befehle abgetippt bekommen, die sie irgendwo finden. Ich glaube das habt ihr alle fast täglich hier schon erlebt.
-
@oliverio sagte in /dev/tty... vs /dev/serial/by-id:
Die Experten haben eher Ahnung wo sie suchen sollen, falls sich da mal eine Interface ID ändert.
Der Punkt ist: Die Experten müssen erst gar nicht in solchen Fällen suchen, weil sie nämlich gleich die persistenten Links verwenden und somit auch nie in diese 'Falle' tappen.
