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

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