Moin Leute,
ich betreibe mein FHEM auf einem unpriviligiertem Linux-Container in Proxmox.
Bislang waren meine USB-Dongles (1wire,ZWave;CUL868 und HMUSB) via UDEV-Rules etc. nach klassischer Art in den LXC durchgeschliffen.
Dabei wurden den Devices ttyUSB0,ttyUSB1,ttyACM0 und ttyACM1 zugewiesen, und so auch in FHEM konfiguriert. Lief prima.
Mittlerweile ist dieses "umständliche" durchschleifen in Proxmox seit 8.2.0 vereinfacht, sprich, man fügt in der Webkonfig ein Device via Serial-ID hinzu, feddich.
Das habe ich gemacht, LCX neugestartet (HotPlug funktioniert hier nicht) und in FHEM in der Konfig statt "tty..." nun "/dev/serial/by-id/*** eingestellt. Das funktioniert auch prächtig, nur der HM-MOD-UART (HMUSB) wechselt ständig von "init" auf "disconnected". Der Status dabei ist immer "opened".
Da die üblichen Tricks hier unter Proxmox (Raspi, BT abschalten etc) nicht greifen, wollte ich mal in die Runde fragen, ob Ihr noch Tips habt ?
über
ls -l /dev/serial/by-id/ bekomme ich im LXC alle 4 Devices korrekt angezeigt.
pi@fhem:~$ sudo ls -l /dev/serial/by-id/
total 0
crw-rw-rw- 1 root root 166, 0 Feb 18 18:21 usb-0658_0200-if00
crw-rw-rw- 1 root root 166, 1 Feb 18 17:41 usb-busware.de_CUL868-if00
crw-rw-rw- 1 root root 188, 0 Feb 18 17:41 usb-FTDI_FT230X_Basic_UART_DN3XL6KW-if00-port0
crw-rw-rw- 1 root root 188, 1 Feb 18 18:21 usb-FTDI_FT232R_USB_UART_AH02Z25V-if00-port0
Moin,
klingt nach: da greift noch einer zu. Oder FHEM schießt mit initialUsbCheck den Stick ab.
Ich probiere das mal aus.
Gruß Otto
Danke, aber
attr initialUsbCheck disable 1
und der Dongle ist ausschließlich an den FHEM-LXC durchgeschliffen
Funktioniert bei mir nach einem reboot des lxc problemlos. Vor dem reboot (installation und dann erst USB gesteckt) stimmten die Rechte nicht.
Und ich bleibe bei meiner bisherigen Erfahrung: der Wechsel connect/disconnect deutet darauf hin, das zwei um die Schnittstelle kämpfen.
Edit noch eine Idee: zeig mal
ls -lha /dev/serial/by-id/
Hm, ok.
Aber ich steh da gerade auf dem Schlauch, denn ich habe die Devices in FHEM eindeutig zugewiesen. Den Rest macht ja Proxmox. Und auch da ist es alles eindeutig.
Wie gesagt, Hotplug funktioniert bei einem LXC nicht, somit erst anstecken, dann booten.
Zitat von: Otto123 am 18 Februar 2025, 19:10:16Edit noch eine Idee: zeig mal
ls -lha /dev/serial/by-id/
pi@fhem:~$ ls -lha /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 120 Feb 18 17:41 .
drwxr-xr-x 3 root root 60 Feb 18 17:41 ..
crw-rw-rw- 1 root root 166, 0 Feb 18 19:28 usb-0658_0200-if00 ## -> HMUSB
crw-rw-rw- 1 root root 166, 1 Feb 18 17:41 usb-busware.de_CUL868-if00 ## -> CUL868
crw-rw-rw- 1 root root 188, 0 Feb 18 19:28 usb-FTDI_FT230X_Basic_UART_DN3XL6KW-if00-port0 ## -> ZWave
crw-rw-rw- 1 root root 188, 1 Feb 18 19:30 usb-FTDI_FT232R_USB_UART_AH02Z25V-if00-port0 ## -> 1wire
Aaaber:
Wenn ich in der Proxmoxshell jetzt
root@pve:~# ls -lha /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 120 Feb 18 18:23 .
drwxr-xr-x 4 root root 80 Feb 18 17:25 ..
lrwxrwxrwx 1 root root 13 Feb 18 17:25 usb-0658_0200-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Feb 18 17:25 usb-busware.de_CUL868-if00 -> ../../ttyACM1
lrwxrwxrwx 1 root root 13 Feb 18 18:23 usb-FTDI_FT230X_Basic_UART_DN3XL6KW-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Feb 18 17:25 usb-FTDI_FT232R_USB_UART_AH02Z25V-if00-port0 -> ../../ttyUSB1Dann wäre der HMUSB = ttyACM0, aaaber in der alten Konfig war er nach ttyUSB0 eingebunden..... jetzt bin ich völlig neben der Spur
Edith:
Arrrgh, habe tatsächlich die IDs für ZWave und HMUSB vertauscht. Weil aber beide Devices in FHEM den Status opened/initialized hatten, wurde mir als Devstateicon auch "grün" angezeigt. Nur als jetzt ich auch per ZWave nix mehr schalten konnte.... war alles klar.
Danke für den Schubs @Otto123
Zu früh gefreut.... ich kann zwar jetzt wieder ZWave schalten, aber der ständige Wechsel von init/disconnected beim HMUSB bleibt.
@Otto123
Welche Rechte hast Du denn dem Dongle zugewiesen ?
Ich habe ihn mit "0666" eingebunden.
Gruppe und User sind jeweils "root".
Nach alt war es "nobody" und "nogroup"
Edith2:
Ich habe das Device im ProxmoxHost gelöscht, alles neu gebootet, dann erneut im HOST eingebunden und durchgereicht. JETZT bleibt die "cond" im Device@FHEM dauerhaft auf "ok"
Zitat von: Bartimaus am 18 Februar 2025, 20:22:07@Otto123
Welche Rechte hast Du denn dem Dongle zugewiesen ?
Ich habe ihn mit "0666" eingebunden.
Ich habe da gar nichts gemacht. Aber - der "Zauber" ist in der lxc .conf . In jedem privilegiertem Container steht dort:
Zitatlxc.cgroup2.devices.allow: c 188:* rwm
lxc.cgroup2.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/serial/by-id dev/serial/by-id none bind,optional,create=dir
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB1 dev/ttyUSB1 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM1 dev/ttyACM1 none bind,optional,create=file
Ich bin nicht sicher, aber am Ende hat der 5 te USB Stick ein Problem, oder schon der dritte USB / ACM.
Zitat von: Bartimaus am 18 Februar 2025, 19:41:48Dann wäre der HMUSB = ttyACM0, aaaber in der alten Konfig war er nach ttyUSB0 eingebunden..... jetzt bin ich völlig neben der Spur
Ich will dazu nochmal erklären, der HMUART über einen usb/seriell Adapter wird mMn immer ein USBx Gerät werden. ACM Geräte haben spezielle Chipsätze die sich dem System als Modem präsentieren.
Die typischen Chipsätze FTDI und CP210x melden werden als USB Geräte eingebunden.
Zu den Rechten, der normale Zustand ist bei /dev/serial/... das gilt auf dem Host genauso wie im LXC, wenn es anders ist muss man den LXC neu starten.
Zitatlrwxrwxrwx 1 root root 13 Feb 18 17:25 usb-xxx
Bei /dev/ttyXXX
Zitatcrw-rw---- 1 root dialout 188, 0 Feb 19 11:34 /dev/tty
Letzteres ist auch wichtig anzuschauen, denn es gibt Systeme da wird dialout durch eine andere Gruppe ersetzt. Der User, der die Schnittstelle verwenden will muss immer in der berechtigten Gruppe stecken.
Die Rechte an diesen Geräten kann man durch chown und chmod nicht dauerhaft manipulieren! Das geschieht durch udev.
Und Du hast jetzt schon 2 ACM und 2 USB Gerät "verbraucht", ich würde vermuten: Du musst beim nächsten USB seriell Stick die LXC conf anpassen. Und dies eventuell bei allen, denn es muss mMn eine Zuordnung zu einem ttyXXX Gerät geben.
Danke für die Erläuterung.
Das 5. Device wäre in der Tat mal interessant, habe da aber aktuell nichts in der Pipeline.
Beim Einbinden im ProxmoxHost kann man ja das Device auch als "read only" einbinden. An dieser Stelle wäre interessant, ob man das Device dann an mehrere LXC durchschleifen kann.
Oder werden Schaltvorgänge als "write" interpretiert ?
Bisher hatte ich die Devices ja klassisch, incl. Udev-Rules an den Container weitergereicht.
Im Container dann die Geräte via tty*** aus FHEM angesprochen. Gleichwohl konnte man im Container per "ls -la /dev/serial/by-id" deren ID auslesen, aber wenn ich FHEM (im Container) dann definiert habe "nutze" die Serial anstelle "tty*", dann hat das nicht funktioniert....
Dieses automatische Durchreichen hängt mWn an der Einstellung: Unprivileged Container no
Damit werden pauschal die oben genannten Einträge in der /etc/pve/lxc/nnn.conf gemacht.
In allen meinen privileged LXCs sehe ich dann auch die Schnittstellen und kann sie mit Sicherheit auch verwenden - aber: Immer nur einer zur gleichen Zeit! ;)
Zitat von: Otto123 am 18 Februar 2025, 23:36:36Ich habe da gar nichts gemacht. Aber - der "Zauber" ist in der lxc .conf . In jedem privilegiertem Container steht dort:
Zitatlxc.cgroup2.devices.allow: c 188:* rwm
lxc.cgroup2.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/serial/by-id dev/serial/by-id none bind,optional,create=dir
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB1 dev/ttyUSB1 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM1 dev/ttyACM1 none bind,optional,create=file
Ich bin nicht sicher, aber am Ende hat der 5 te USB Stick ein Problem, oder schon der dritte USB / ACM.
Diese Einträge habe ich in kein meiner Konfig-Dateien für meine priv. LXCs
Gleichwohl werden die Devices in der ProxmoxShell an ttyUSB/ACM durchgereicht....
In meiner Konfig steht nach neu folgendes:
dev0: /dev/serial/by-id/usb-0658_0200-if00,mode=0666
dev1: /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_DN3XL6KW-if00-port0,mode=0666
dev2: /dev/serial/by-id/usb-busware.de_CUL868-if00,mode=0666
dev3: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH02Z25V-if00-port0,deny-write=on,mode=0666
Zitat von: Bartimaus am 19 Februar 2025, 19:38:14Gleichwohl werden die Devices in der ProxmoxShell an ttyUSB/ACM durchgereicht....
hast Du wirklich in deinem lxc die Verbindung nach ttyUSB/ACM ich habe das mal versucht da bekommt man dann /dev/serial/by-id/xxx aber nix weiter. :(
Zitat von: Bartimaus am 20 Februar 2025, 17:45:04Guckst Du:
root@pve:~# ls -l /dev/serial/by-id/
total 0
lrwxrwxrwx 1 root root 13 Feb 18 17:25 usb-0658_0200-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Feb 18 17:25 usb-busware.de_CUL868-if00 -> ../../ttyACM1
lrwxrwxrwx 1 root root 13 Feb 18 20:46 usb-FTDI_FT230X_Basic_UART_DN3XL6KW-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Feb 18 17:25 usb-FTDI_FT232R_USB_UART_AH02Z25V-if00-port0 -> ../../ttyUSB1
root@pve:~#
über "Device passthrough" kann man jetzt auch Speicher an LXC durchreichen. Eben mal getestet
Muss ich mal mitlesen.
Zitat von: Bartimaus am 20 Februar 2025, 17:46:32root@pve:~# ls -l /dev/serial/by-id/
Das ist doch dein Host?!
Genau.
Hast Du Dein Device auch so wie ich über den ProxmoxHost an den LXC durchgereicht?
Ja, aber meine Frage war: wie sieht das durchgereichte Device in deinem LXC aus? Also
ls -lha /dev/serial/by-id/ in deinem lxc Container.
So
pi@fhem:~$ sudo ls -lha /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 120 Feb 18 20:50 .
drwxr-xr-x 3 root root 60 Feb 18 20:50 ..
crw-rw-rw- 1 root root 166, 0 Feb 20 21:46 usb-0658_0200-if00
crw-rw-rw- 1 root root 166, 1 Feb 20 16:25 usb-busware.de_CUL868-if00
crw-rw-rw- 1 root root 188, 0 Feb 20 21:46 usb-FTDI_FT230X_Basic_UART_DN3XL6KW-if00-port0
crw-rw-rw- 1 root root 188, 1 Feb 20 21:46 usb-FTDI_FT232R_USB_UART_AH02Z25V-if00-port0
pi@fhem:~$
Zitat von: Otto123 am 18 Februar 2025, 23:36:36Ich habe da gar nichts gemacht. Aber - der "Zauber" ist in der lxc .conf . In jedem privilegiertem Container steht dort:
Zitatlxc.cgroup2.devices.allow: c 188:* rwm
lxc.cgroup2.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/serial/by-id dev/serial/by-id none bind,optional,create=dir
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB1 dev/ttyUSB1 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM1 dev/ttyACM1 none bind,optional,create=file
Ich frage, weil das nach alter "Device Passthrough"-Logik aussieht. Nach neu sind diese Einträge in der LXC.conf überflüssig
Ok danke. Es wird also das Device so durchgreicht wie man es einträgt. Es gibt keinen Link zu ttyACM/USB.
Zitat von: Bartimaus am 20 Februar 2025, 21:50:31Ich frage, weil das nach alter "Device Passthrough"-Logik aussieht. Nach neu sind diese Einträge überflüssig
Kann sein. Ich habe meine LXC alle mit den https://community-scripts.github.io/ProxmoxVE/ installiert die machen das so wie gezeigt. Was jetzt besser ist weiß ich (noch) nicht. :)
Es ist zumindest einfach und ich muss gar nichts tun. Anstecken und fertig :) Die andere Methode (neue ...) ist selektiver, deswegen kam ich auf das Problem beim 5.ten Gerät.
Meine LXC habe ich auch via Scripten erstellt. Ist ne super Sache.
Nur dieses einfache "Device passthrough" gibts erst seit ProxMox 8.2.
Ist halt im Falle eines Restore aus dem Backup einfacher, weil man dann nicht noch zusätzlich an die eigene Udev-Rule denken muss, die nicht Teil des LXC-Backups ist.
Ob es ein Problem mit einem 5. Gerät gibt, ist noch nicht bewiesen............ :)
Zitat von: Bartimaus am 20 Februar 2025, 22:16:25an die eigene Udev-Rule denken muss
ich habe da keine eigene udev-Rule machen müssen. ???
Zitat von: Otto123 am 20 Februar 2025, 22:18:47Zitat von: Bartimaus am 20 Februar 2025, 22:16:25an die eigene Udev-Rule denken muss
ich habe da keine eigene udev-Rule machen müssen. ???
Ok, als ich das vor einem Jahr gemacht habe, war es es aufwändiger Prozess erstmal alle IDs, BUstypes etc zu ermitteln.
Ich denke, ohne die Udev-Rules sondern "nur" durch die neue Durchreich-Methode wird das Abstecken und Neustecken eines USB-Devices aber dann nicht adäquat im laufenden Betrieb verarbeitet, oder?
Bei mir ist es auch nach "alter" Art mit Udev-Rules gelöst, da kann ich (egal ob praxisnah und sinnvoll oder nicht) im laufenden Betrieb den Stick ziehen und wieder einstecken, er wird immer wieder ordnungsgemäß neu dem lxc übergeben.
Siehe auch https://forum.fhem.de/index.php?msg=1330613
Das habe ich noch nicht probiert, wozu auch ?
Da ein LxC nicht hotplug-fähig ist, müsste dieser eh neu gestartet werden, und das versuche ich zu vermeiden. Aber ich denke die Entwickler von Proxmox werden sich bei der Entwicklung der neuen Methode etwas dabei gedacht haben.
Ich mag schlanke Lösungen.
Zitat von: Bartimaus am 21 Februar 2025, 09:12:49Da ein LxC nicht hotplug-fähig ist, müsste dieser eh neu gestartet werden,
also nicht wirklich für die reale welt gedacht, oder? ;)
Das muss ich noch einmal nachtesten. Mit der "alten" Methode klappt(e) das m.W. für diesen konkreten Anwendungsfall sehr wohl. Am Host den Stick gezogen und wieder eingesteckt, konnte direkt (ohne Neustart) wieder im lxc verwendet werden. Aber ich teste noch einmal.
Zitat von: frank am 21 Februar 2025, 09:30:41Zitat von: Bartimaus am 21 Februar 2025, 09:12:49Da ein LxC nicht hotplug-fähig ist, müsste dieser eh neu gestartet werden,
also nicht wirklich für die reale welt gedacht, oder? ;)
Wieso? Im FHEM-LXC fummle ich nicht ständig rum.
Zitat von: Ralli am 21 Februar 2025, 09:41:36Das muss ich noch einmal nachtesten. Mit der "alten" Methode klappt(e) das m.W. für diesen konkreten Anwendungsfall sehr wohl. Am Host den Stick gezogen und wieder eingesteckt, konnte direkt (ohne Neustart) wieder im lxc verwendet werden. Aber ich teste noch einmal.
Ich meine, das hatte bei meinem damals nicht funktioniert. Für ein neues Device musst definitiv neu starten.
Zitat von: frank am 21 Februar 2025, 09:30:41also nicht wirklich für die reale welt gedacht, oder? ;)
naja ein HM-MOD-RPI-PCB auf dem Pi ist auch nicht hotplug fähig ;)
Aber ich habe mir das angeschaut.
Erster LXC privileged mit community Script installiert und damit die Konfiguration wie in #7 dargestellt, hat in der Tat nach einem ab- / anstecken der FTDI / HM-MOD-RPI-PCB keine Verbindung. Der Grund: die Rechte stimmen nicht (obwohl einbindung über serial/by-id/).
c--------- 0 root root 188, 1 Feb 21 10:33 /dev/ttyUSB1Ein
chmod 0660 /dev/ttyUSB1
chown root:dialout /dev/ttyUSB1behebt das Problem.
LXC führt seine Config offenbar nur beim restart aus? Ich habe dazu auch diesen Workaround (https://monach.us/automation/connecting-zwave-stick-under-lxc/) gefunden.
Zweiter LXC unprivileged mit der Konfiguration von Bartimaus, also Devices -> pass through, funktioniert ein ab / -anstecken des gleichen Adapters tadellos.
Offenbarer Grund: hier wird nicht extra gelinkt auf ttyUSB1 sondern ich habe die Einbindung mit root:dialout gemacht und damit wird das recht direkt vergeben:
crw-rw---- 1 root dialout 188, 1 Feb 21 11:05 usb-FTDI_FT232R_USB_UART_00000000-if00-port0Im "normalen" System wird dies immer zweistufig gemacht:
lrwxrwxrwx 1 root root 13 Feb 21 11:00 usb-FTDI_FT232R_USB_UART_00000000-if00-port0 -> ../../ttyUSB1
crw-rw---- 0 root dialout 188, 1 Feb 21 10:58 /dev/ttyUSB1Ergo: die Methode über Devices -> pass through ist die bessere :) So habe ich das eingebunden, GID 20 steht für dialout.
Screenshot 2025-02-21 111031.png
Danke für die Bestätigung Otto.
Ich sag ja, die "interne" Lösung aus dem ProxmoxKosmos ist die modernere Lösung.
Ich habe die Geräte aber nicht mit der Gruppe "dialout" eingebunden. Welche "Vorteile" hätte das gegenüber Root ?
Zitat von: Otto123 am 21 Februar 2025, 11:12:46Aber ich habe mir das angeschaut.
Erster LXC privileged mit community Script installiert und damit die Konfiguration wie in #7 dargestellt, hat in der Tat nach einem ab- / anstecken der FTDI / HM-MOD-RPI-PCB keine Verbindung. Der Grund: die Rechte stimmen nicht (obwohl einbindung über serial/by-id/).
c--------- 0 root root 188, 1 Feb 21 10:33 /dev/ttyUSB1Ein
chmod 0660 /dev/ttyUSB1
chown root:dialout /dev/ttyUSB1behebt das Problem.
LXC führt seine Config offenbar nur beim restart aus? Ich habe dazu auch diesen Workaround (https://monach.us/automation/connecting-zwave-stick-under-lxc/) gefunden.
Zweiter LXC unprivileged mit der Konfiguration von Bartimaus, also Devices -> pass through, funktioniert ein ab / -anstecken des gleichen Adapters tadellos.
Offenbarer Grund: hier wird nicht extra gelinkt auf ttyUSB1 sondern ich habe die Einbindung mit root:dialout gemacht und damit wird das recht direkt vergeben:
crw-rw---- 1 root dialout 188, 1 Feb 21 11:05 usb-FTDI_FT232R_USB_UART_00000000-if00-port0Im "normalen" System wird dies immer zweistufig gemacht:
lrwxrwxrwx 1 root root 13 Feb 21 11:00 usb-FTDI_FT232R_USB_UART_00000000-if00-port0 -> ../../ttyUSB1
crw-rw---- 0 root dialout 188, 1 Feb 21 10:58 /dev/ttyUSB1
Ergo: die Methode über Devices -> pass through ist die bessere :) So habe ich das eingebunden, GID 20 steht für dialout.
Screenshot 2025-02-21 111031.png
Hast Du denn jetzt die vorherigen Einträge aus dem LXC.conf/my-udev.rules auch entfernt ?
Zitat von: Bartimaus am 21 Februar 2025, 11:26:36Ich habe die Geräte aber nicht mit der Gruppe "dialout" eingebunden. Welche "Vorteile" hätte das gegenüber Root ?
Es wäre die "richtigere" Einbindung.
Du hast sie nicht über root eingebunden, du hast für ALLE eingebunden (0666) - das ist eigentlich immer unschön bzw. "das dünne Brett gebohrt" ;)
Außerdem hat die 20 nur zwei Zeichen beim eintragen, Du tippst 4. ;D :)) ;D :)) ;D :))
Zitat von: Bartimaus am 21 Februar 2025, 11:29:50Hast Du denn jetzt die vorherigen Einträge aus dem LXC.conf/my-udev.rules auch entfernt ?
Ich habe einen neuen LXC einfach unprivileged installiert. Der hat diese Einträge nicht, eigene udev rules hatte ich nie.
Ich habe es mit der "alten" Methode überprüft und nun auch mit der neuen Methode umgesetzt. Bei mir klappt das für meinen Anwendungsfall auch mit hotplug.
Config des lxc:
root@pve-n3:~# cat /etc/pve/lxc/109.conf
arch: amd64
cores: 4
dev0: /dev/serial/by-id/usb-SparkFun_SparkFun_Pro_Micro-if00,gid=20,uid=0
features: nesting=1
hostname: weather-fhem
memory: 512
net0: name=eth0,bridge=vmbr0,firewall=1,gw=10.0.0.1,...
onboot: 1
ostype: debian
rootfs: local-zfs:subvol-109-disk-0,size=8G
swap: 512
unprivileged: 1
Host vor dem Ziehen und nach dem Wieder-Einstecken des Sticks:
root@pve-n3:~# ls -la /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 60 Jan 30 07:38 .
drwxr-xr-x 4 root root 80 Jan 30 07:38 ..
lrwxrwxrwx 1 root root 13 Jan 30 07:38 usb-SparkFun_SparkFun_Pro_Micro-if00 -> ../../ttyACM0
root@pve-n3:~# ls -la /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 60 Feb 21 11:36 .
drwxr-xr-x 4 root root 80 Feb 21 11:36 ..
lrwxrwxrwx 1 root root 13 Feb 21 11:36 usb-SparkFun_SparkFun_Pro_Micro-if00 -> ../../ttyACM0
Lxc vor dem Ziehen und nach dem Wieder-Einstecken des Sticks:
root@weather-fhem:~# ls -la /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 60 Feb 21 11:29 .
drwxr-xr-x 3 root root 60 Feb 21 11:29 ..
crw-rw---- 1 root dialout 166, 0 Feb 21 11:32 usb-SparkFun_SparkFun_Pro_Micro-if00
root@weather-fhem:~# ls -la /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 60 Feb 21 11:29 .
drwxr-xr-x 3 root root 60 Feb 21 11:29 ..
crw-rw---- 1 root dialout 166, 0 Feb 21 11:36 usb-SparkFun_SparkFun_Pro_Micro-if00
Noch nicht einmal FHEM musste neu gestartet werden:
2025.02.21 11:36:25 1: /dev/serial/by-id/usb-SparkFun_SparkFun_Pro_Micro-if00 disconnected, waiting to reappear (SIGNALduino)
2025.02.21 11:36:37 3: Setting SIGNALduino serial parameters to 57600,8,N,1
2025.02.21 11:36:37 1: SIGNALduino/define: /dev/serial/by-id/usb-SparkFun_SparkFun_Pro_Micro-if00@57600
2025.02.21 11:36:37 1: SIGNALduino/init: /dev/serial/by-id/usb-SparkFun_SparkFun_Pro_Micro-if00@57600
2025.02.21 11:36:37 1: /dev/serial/by-id/usb-SparkFun_SparkFun_Pro_Micro-if00 reappeared (SIGNALduino)
2025.02.21 11:36:39 3: SIGNALduino/init: disable receiver (XQ)
2025.02.21 11:36:40 3: SIGNALduino/init: get version, retry = 0
2025.02.21 11:36:40 3: SIGNALduino/init: firmwareversion with ccBankSupport found -> send b?
2025.02.21 11:36:40 2: SIGNALduino: initialized. v3.5.3-ralf_13.02.25
2025.02.21 11:36:40 3: SIGNALduino/init: enable receiver (XE)
Last login: Thu Feb 20 21:46:22 2025 from 69.69.69.69
pi@fhem:~$ sudo ls -lha /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 120 Feb 21 11:38 .
drwxr-xr-x 3 root root 60 Feb 21 11:38 ..
crw-rw---- 1 root dialout 166, 0 Feb 21 11:38 usb-0658_0200-if00
crw-rw---- 1 root dialout 166, 1 Feb 21 11:38 usb-busware.de_CUL868-if00
crw-rw---- 1 root dialout 188, 0 Feb 21 11:38 usb-FTDI_FT230X_Basic_UART_DN3XL6KW-if00-port0
crw-rw---- 1 root dialout 188, 1 Feb 21 11:39 usb-FTDI_FT232R_USB_UART_AH02Z25V-if00-port0
Überzeugt :)
Mit 0660 und GID0 hatte ich Probleme, deswegen hatte ich auf 0666 geändert, so wie M.Kleine es empfohlen hatte.
Das Du ohne udev-rules eingebunden hattest, find ich interessant.
Bei dem von mir verwendeten FHEM-Proxmox-Installationsscript war das einbinden/durchreichen eines Devices an nen LXC noch "tricky".