[gelöst] HM-MOD-UART init/disconnected nach Umstellung von tty auf /dev/serial/by-id

[Bartimaus]

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

Code Auswählen Erweitern

ls -l /dev/serial/by-id/ bekomme ich im LXC alle 4 Devices korrekt angezeigt.

Code Auswählen Erweitern

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

[Otto123]

Moin,
klingt nach: da greift noch einer zu. Oder FHEM schießt mit initialUsbCheck den Stick ab.

Ich probiere das mal aus.

Gruß Otto

[Bartimaus]

Danke, aber

Code Auswählen Erweitern

attr initialUsbCheck disable 1
und der Dongle ist ausschließlich an den FHEM-LXC durchgeschliffen

[Otto123]

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

Code Auswählen Erweitern

ls -lha /dev/serial/by-id/

[Bartimaus]

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.

[Bartimaus]

Edit noch eine Idee: zeig mal

Code Auswählen Erweitern

ls -lha /dev/serial/by-id/

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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 -> ../../ttyUSB1
Dann 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

[Bartimaus]

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"

[Otto123]

@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:

lxc.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.

[Otto123]

Dann 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.

lrwxrwxrwx 1 root root  13 Feb 18 17:25 usb-xxx

Bei /dev/ttyXXX

crw-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.

[Bartimaus]

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....

[Otto123]

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!

[Bartimaus]

Ich habe da gar nichts gemacht. Aber - der "Zauber" ist in der lxc .conf . In jedem privilegiertem Container steht dort:

lxc.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:

Code Auswählen Erweitern

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

[Otto123]

Gleichwohl 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. 

[Bartimaus]

Guckst Du:

Code Auswählen Erweitern

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

[Ralli]

Muss ich mal mitlesen.

[Otto123]

root@pve:~# ls -l /dev/serial/by-id/

Das ist doch dein Host?!

[Bartimaus]

Genau.

Hast Du Dein Device auch so wie ich über den ProxmoxHost an den LXC durchgereicht?

[Otto123]

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.

[Bartimaus]

So

Code Auswählen Erweitern

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:~$

[Bartimaus]

Ich habe da gar nichts gemacht. Aber - der "Zauber" ist in der lxc .conf . In jedem privilegiertem Container steht dort:

lxc.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

[Otto123]

Ok danke. Es wird also das Device so durchgreicht wie man es einträgt. Es gibt keinen Link zu ttyACM/USB.

Ich 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.

[Bartimaus]

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............

 

[Otto123]

an die eigene Udev-Rule denken muss

ich habe da keine eigene udev-Rule machen müssen. 

[Bartimaus]

an 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.

[Ralli]

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

[Bartimaus]

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.

[frank]

Da ein LxC nicht hotplug-fähig ist, müsste dieser eh neu gestartet werden,

also nicht wirklich für die reale welt gedacht, oder? 

[Ralli]

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.

[Bartimaus]

Da 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.

[Bartimaus]

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.

Ich meine, das hatte bei meinem damals nicht funktioniert. Für ein neues Device musst definitiv neu starten.

[Otto123]

also 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/).

Code Auswählen Erweitern

c--------- 0 root root 188, 1 Feb 21 10:33 /dev/ttyUSB1Ein

Code Auswählen Erweitern

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 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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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.
Du darfst diesen Dateianhang nicht ansehen.

[Bartimaus]

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 ?

[Bartimaus]

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/).

Code Auswählen Erweitern

c--------- 0 root root 188, 1 Feb 21 10:33 /dev/ttyUSB1Ein

Code Auswählen Erweitern

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 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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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.
Du darfst diesen Dateianhang nicht ansehen.

Hast Du denn jetzt die vorherigen Einträge aus dem LXC.conf/my-udev.rules auch entfernt ?

[Otto123]

Ich 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.     

Hast 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.

[Ralli]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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)


[Bartimaus]

Code Auswählen Erweitern

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".