Ich habe eine Pi5-8GB mit Trixie 64Bit installiert.
Unter Fhem wird ein nanoCUL per USB Schnittstelle als disconnected angezeigt.
Auf der Konsole ist aber die Verbindung vorhanden.
ls -al /dev/serial/by-id
insgesamt 0
drwxr-xr-x 2 root root 80 20. Mär 18:38 .
drwxr-xr-x 4 root root 80 20. Mär 18:38 ..
lrwxrwxrwx 1 root root 13 20. Mär 18:38 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 20. Mär 18:38 usb-FTDI_FT232R_USB_UART_AI03D834-if00-port0 -> ../../ttyUSB1
list nanoCUL868_OG2
Internals:
CFGFN /media/hdd/fhem/mycfg/schnittstellen_rasp01.cfg
CMDS
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D834-if00-port0@38400 0000
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D834-if00-port0@38400
FHTID 0000
FUUID 5c45b016-f33f-f4d2-81b3-74d1625f35df186e
NAME nanoCUL868_OG2
NR 324
NR_CMD_LAST_H 1
PARTIAL
STATE disconnected
TYPE CUL
devioNoSTATE 1
eventCount 3
initString X21
MatchList:
0:FS20V ^81..(04|0c)..0101a001......00[89a-f]...
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04......a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
C:Hideki ^P12#75[A-F0-9]{17,30}
C:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2026-03-13 18:35:44 cmds A B C E e F f G i K l M N R T t U V W X x Z
2026-03-20 18:44:32 state disconnected
2026-03-20 18:52:13 version No answer
XMIT_TIME:
1774028464.78818
Attributes:
alias nanoCUL868 - OG2 EDV-Raum
devStateIcon Initialized:usb@0CFB0C opened:usb@red disconnected:usb@red
group Schnittstellen USB
icon cul_868
model nanoCUL
rfmode SlowRF
room _FS20,_RxTx
sendpool nanoCUL868_AB_FR,nanoCUL868_AB_GAW,nanoCUL868_EG,nanoCUL868_OG1,nanoCUL868_OG2,nanoCUL868_WebCam
dmesg | grep FT
[ 1.444460] usb 3-1.2: Product: FT232R USB UART
[ 1.444462] usb 3-1.2: Manufacturer: FTDI
[ 3.483377] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 3.483458] ftdi_sio 3-1.2:1.0: FTDI USB Serial Device converter detected
[ 3.483506] usb 3-1.2: Detected FT232R
[ 3.536703] usb 3-1.2: FTDI USB Serial Device converter now attached to ttyUSB1
Vor der Aktualisierung auf Trixie funktionierte unter FHEM der nanoCUL noch.
Gibt es bei den USB-Schnittstellen auch Änderungen die FHEM betreffen?
fhem ist Mitglied der group plugdev?
Vermutlich ein Berechtigungsproblem.
Zitat von: Beta-User am 20 März 2026, 19:08:33fhem ist Mitglied der group plugdev?
Vermutlich ein Berechtigungsproblem.
An der Berechtigung kann es nicht liegen, da die andere USB-Schnittstelle funktioniert.
Ich vermute das es ein Problem mit dem
usb-FTDI_FT232R_USB_UART_AI03D834-if00-port0 gibt. Mit dem
usb-1a86_USB2.0-Serial-if00-port0 funktioniert die USB-Verbindung.
Ich quäle mich auch schon seit WOCHEN mit früher problemlos funktionierenden 2 aktiven Hubs und 7 Sticks mit der Migration auf Trixie.
Bei einem 3B schmiert einem dann gar die komplette LAN-Verbindung ab, was bei pihole-Nutzung als DNS der Supergau ist.
Fahre aktuell mit mehreren Systemen, also Split von 1 auf 3, was die Sache nicht übersichtlicher macht, aber der Ursachenfindung.[Auskotz Ende]
Dein Problem hatte ich bisher noch nicht. FHEM macht bei mir brav, was das OS an Futter hergibt. Wenn ein USB disconnected in FHEM ist, ist er das auch im OS.
Ich habe das umgekehrte Phänomen(bei einem Pi3B). IRGENDWANN kommen plötzlich keine Daten mehr. Weder im Syslog, noch, folgerichtig, gibt es einen disconnect-Hinweis in FHEM. Mal hilft ein unbind/bind des devices, mal des ganzen Hubs, mal ein restart des OS und worst case schlägt mein watchdog zu, nachdem das System unerreichbar geworden ist. Die neuste Variante ist, dass mir das OS das vorher noch funktionienierende unbind/bind mit "permission denied" verweigert. Natürlich sind die Berechtigungen unverändert. Gut, dass ich nicht mehr so viele Haare habe ;D
Mittlerweile habe ich mir einen 5er zugelegt. Mit 1 Hub u. 3 Sticks läuft er ganz passabel, da ja USB und LAN nun physisch getrennt sind.
Vielleicht hilft es irgendwie....Das unbind/bind funktioniert vom Prinzip her bei einem beispielhaften device so....
echo 1-1.4.7 | sudo tee /sys/bus/usb/drivers/usb/unbind > /dev/null
echo 1-1.4.7 | sudo tee /sys/bus/usb/drivers/usb/bind > /dev/null
Edit: mein Fehler. permission denied wegen vergessenem sudo für das tee. Habs korrigiert.
Ich habe eine Lösung gefunden.
Trixie 64bit und FHEM sind auf aktuellem Softwarestand.
Mit einem Pi5 und Trixie 64bit unterscheide FHEM anscheinend bei den Berechtigungen.
Für USB Schnittstellen reicht bisher die Berechtigung chmod -R a+w /dev/serial für FHEM.
Für die usb-FTDI ist das aber für FHEM zu wenig. Für diese muss ich jetzt die Berechtigung chmod -R 0777 /dev/serial verwenden.
Irgendetwas muss sich zwischen dem OS Trixie und FHEM geändert haben.
Interessant. Ist vielleicht bei mir der Grund, dass im Falle von Signalduinos, die selber versuchen wieder eine Verbindung herzustellen, deren "Heilungsversuch" zu einem korrupten System führt. Gucke ich mir mal näher an.... Danke.
Da hatte sich doch unter Trixie etwas mit der Gruppe der Serial Interfaces geändert. Da gab es mehrere Beiträge.
Z. B.
https://forum.fhem.de/index.php?action=profile;u=9868
Nachtrag, da falscher Link kopiert:
https://forum.fhem.de/index.php?msg=1319549
oder
https://forum.fhem.de/index.php?msg=1319535
schon komisch, Du meinst die Group plugdev ?(Dein Link ist falsch)
Sowohl auf einem neu aufgesetzten Pi3B, als auch Pi5 habe ich bereits
chmod -R 0777 /dev/serialUnd bei /dev/ttyUSBx sind owner root und Group dialout.
und plugdev ?
auf dem RPi5
sudo find / -group plugdev
/dev/bus/usb/001/003
find: '/proc/6557/task/6557/fd/5': No such file or directory
find: '/proc/6557/task/6557/fdinfo/5': No such file or directory
find: '/proc/6557/fd/6': No such file or directory
find: '/proc/6557/fdinfo/6': No such file or directory
und Rpi3
sudo find / -group plugdev
/dev/bus/usb/001/010
/dev/bus/usb/001/008
/dev/bus/usb/001/004
find: '/proc/22442/task/22442/fd/5': No such file or directory
find: '/proc/22442/task/22442/fdinfo/5': No such file or directory
find: '/proc/22442/fd/6': No such file or directory
find: '/proc/22442/fdinfo/6': No such file or directory
Mangels vernünftiger Linux-Kenntnisse habe ich mir das kaum selber ausgedacht.
Ich bin sehr verwundert. :(
Und daher verursachen 4,8,10 mein "korruptes" System auf dem RPi3, wenn aus FHEM heraus "Wiederbelebungsversuche" ausgeführt werden ?
[Sat Mar 21 14:19:31 2026] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[Sat Mar 21 14:19:31 2026] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[Sat Mar 21 14:19:31 2026] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Sat Mar 21 14:19:31 2026] usb 1-1.2: Product: RFXtrx433
[Sat Mar 21 14:19:31 2026] usb 1-1.2: Manufacturer: RFXCOM
[Sat Mar 21 14:19:31 2026] usb 1-1.2: SerialNumber: 02VEJQFT
[Sat Mar 21 14:19:32 2026] usb 1-1.4.3: new full-speed USB device number 8 using dwc_otg
[Sat Mar 21 14:19:32 2026] usb 1-1.4.3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[Sat Mar 21 14:19:32 2026] usb 1-1.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Sat Mar 21 14:19:32 2026] usb 1-1.4.3: Product: FT232R USB UART
[Sat Mar 21 14:19:32 2026] usb 1-1.4.3: Manufacturer: FTDI
[Sat Mar 21 14:19:32 2026] usb 1-1.4.3: SerialNumber: A9M0ESED
[Sat Mar 21 14:19:33 2026] usb 1-1.4.7: new full-speed USB device number 10 using dwc_otg
[Sat Mar 21 14:19:33 2026] usb 1-1.4.7: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[Sat Mar 21 14:19:33 2026] usb 1-1.4.7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Sat Mar 21 14:19:33 2026] usb 1-1.4.7: Product: FT232R USB UART
[Sat Mar 21 14:19:33 2026] usb 1-1.4.7: Manufacturer: FTDI
[Sat Mar 21 14:19:33 2026] usb 1-1.4.7: SerialNumber: A6019S96
plugdev scheint ein Überbleibsel aus alter Zeit zu sein, das über manche udev-Rules "zombiert".
Einfach fhem dazu packen sollte in den meisten Fällen helfen.
Danke, so habe ich es gemacht und harre wie seit einem Monat den nächsten Kuriositäten.
Wie toll lief mein FHEM unter bullseye. :'(
Zitat von: KölnSolar am 21 März 2026, 20:39:52Wie toll lief mein FHEM unter bullseye. :'(
Na ja, "irgendwann" muss man halt konsequent sein und "deprecated" features deaktivieren. Vermutlich war das aber schon unter bullseye ein (nicht so verbreitetes) Problem. Die Entscheidung scheint schon 2018 gefallen zu sein: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897916.
Jedenfalls ist mir nun klar, warum das so (scheinbar) zufällig auftritt...
Dein "tee"-Fix kommt trotzdem auf meine Liste: Hin und wieder schmiert mir zigbee2mqtt (docker) ab, der Stick ist dann nicht mehr zu erreichen, dann ist Zeit für "unplug"+Neustart des ganzen Rechners. Auch, wenn da oft viele Wochen dazwischenliegen: Unschön...
ZitatDein "tee"-Fix kommt trotzdem auf meine Liste: Hin und wieder schmiert mir zigbee2mqtt (docker) ab, der Stick ist dann nicht mehr zu erreichen, dann ist Zeit für "unplug"+Neustart des ganzen Rechners. Auch, wenn da oft viele Wochen dazwischenliegen: Unschön...
Ja, so war das bei mir früher auch.
Musste soeben erstmalig einen Ausfall ohne Logmeldungen :'( eines Signalduino, an aktivem Hub im neuen RPi5-System festststellen. Gleiches hatte ich heute Nacht auf dem RPi3B, was dort später wieder zu einem reboot durch den watchdog führte.
Mein unbind/bind auf dem 5er hat ihn remote zum Leben ohne unplug/plug/reboot erweckt. Sieht so in den Logs aus.
[Sun Mar 22 10:29:29 2026] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[Sun Mar 22 10:29:29 2026] ftdi_sio 1-2.2:1.0: device disconnected
[Sun Mar 22 10:29:58 2026] ftdi_sio 1-2.2:1.0: FTDI USB Serial Device converter detected
[Sun Mar 22 10:29:58 2026] usb 1-2.2: Detected FT232R
[Sun Mar 22 10:29:58 2026] usb 1-2.2: FTDI USB Serial Device converter now attached to ttyUSB0
2026.03.22 10:29:29 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_001PQQCF-if00-port0 disconnected, waiting to reappear (Sduino868)
2026.03.22 10:29:58 3: Setting Sduino868 serial parameters to 57600,8,N,1
2026.03.22 10:29:58 1: Sduino868/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_001PQQCF-if00-port0
2026.03.22 10:29:58 1: Sduino868/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_001PQQCF-if00-port0
2026.03.22 10:29:58 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_001PQQCF-if00-port0 reappeared (Sduino868)
2026.03.22 10:30:00 3: Sduino868/init: disable receiver (XQ)
2026.03.22 10:30:01 3: Sduino868/init: get version, retry = 0
2026.03.22 10:30:01 3: Sduino868/init: firmwareversion with ccBankSupport found -> send b?
2026.03.22 10:30:01 2: Sduino868: initialized. v3.4.7-dev_ralf_18.11.
2026.03.22 10:30:01 3: Sduino868/init: enable receiver (XE)
Auf dem Pi3B wurde er dann, was die Kommunikation anbelangt, langsam bis das LAN 1-2h später weg war und der watchdog dann einen reboot ausführte.
Auf dem 5er erhoffe ich mir, dass das nun aber folgenlos bleibt.
Beim 3er hatte ich fhem plugdev hinzugefügt aber nicht rebootet. Beim 5er habe ich es noch gar nicht gemacht, um Unterschiede eindeutig festzustellen.
sorry, hatte oben einen Fehler beim "tee". Es muss mit sudo ausgeführt werden.echo 1-1.4.7 | sudo tee /sys/bus/usb/drivers/usb/unbind > /dev/null
echo 1-1.4.7 | sudo tee /sys/bus/usb/drivers/Usb/bind > /dev/null
@Chris: Und sorry fürs kapern. Ich denke, aber es ist hilfreich die ähnlichen Probleme in einem thread abzuhandeln.
Zitat von: KölnSolar am 21 März 2026, 18:54:25Du meinst die Group plugdev ?(Dein Link ist falsch)
Ja sorry, da war Copy&Paste auf dem Smartphone etwas daneben. Ich habe den Link oben korrigiert.
Die geänderte Gruppe "plugdev" war ja tatsächlich schon im bookworm -- in #1 hat es @Beta-User schon erwähnt.
Aktuell ist bei mir kein Pi aktiv - auf Debian ist die Gruppe noch "dialout"
Gruß Ralf
Zitat von: Beta-User am 22 März 2026, 07:58:13Na ja, "irgendwann" muss man halt konsequent sein und "deprecated" features deaktivieren. Vermutlich war das aber schon unter bullseye ein (nicht so verbreitetes) Problem. Die Entscheidung scheint schon 2018 gefallen zu sein: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897916 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897916).
Muss man dann aber nicht verstehen warum im PI-OS mit Bookworm (und Trixie?) die USB-Interfaces "plugdev" bekommen haben.
Zitat von: Beta-User am 21 März 2026, 19:41:01plugdev scheint ein Überbleibsel aus alter Zeit zu sein, das über manche udev-Rules "zombiert".
Warum etwas uraltes im einem aktuellen OS (Trixie) auftaucht.
Das Problem tauchte bei mir erst mit Trixie auf. Die letzten Jahre mit gleicher Schnittstellenhardware war das immer dialout.
Zitat von: RalfRog am 23 März 2026, 00:31:35Muss man dann aber nicht verstehen warum im PI-OS mit Bookworm (und Trixie?) die USB-Interfaces "plugdev" bekommen haben.
Vermutlich nicht...
Zitat von: Burny4600 am 30 März 2026, 20:19:12Warum etwas uraltes im einem aktuellen OS (Trixie) auftaucht.
Meine (ungeprüfte!) Theorie:
Die Gruppe steht noch (selten) in manchen udev-rules. Früher scheint man das irgendwie kaschiert und umgebogen zu haben, aber damit scheint halt "Schluss" zu sein. Dann muss der User ran (und die Gruppenzugehörigkeit "wiederbeleben") (oder besser der für die udev-rule eigentlich Zuständige, und die Leiche richtig benennen...).
Zitat von: Burny4600 am 20 März 2026, 19:03:03Vor der Aktualisierung auf Trixie funktionierte unter FHEM der nanoCUL noch.
Also ich hab letzte Woche ein System komplett neu aufgesetzt welches bisher unter Buster lief.
Ich kann die Probleme mit den Gruppenrechten nicht nachvollziehen, evtl. ist es auch nur dem richtigen Zeitpunkt geschuldet, keine Ahnung.
Alles läuft wie zuvor, ohne irgendwelche Rechte zu ändern.
An der Pi(4) hängen 4 USB Geräte.
Drei serielle:
pi@fhempi:~ $ ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 26. Mär 21:59 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 26. Mär 21:59 /dev/ttyUSB1
crw-rw---- 1 root dialout 188, 2 30. Mär 20:52 /dev/ttyUSB2
und ein Conbee2:
pi@fhempi:~ $ ls -l /dev/ttyACM*
crw-rw---- 1 root dialout 166, 0 30. Mär 20:59 /dev/ttyACM0pi@fhempi:~ $ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.4
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
Die dialout und plugdev Zuweisung dürfte vom Chip des CULs unter Trixie abhängig sein.
ls -l /dev/ttyUSB1 => /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 0000
crwxrwxrwx 1 root dialout 188, 1 30. Mär 19:24 /dev/ttyUSB1
ls -l /dev/ttyUSB0 => /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D834-if00-port0
crwxrwxrwx+ 1 root plugdev 188, 0 30. Mär 19:35 /dev/ttyUSB0
Die gleiche Hardware unter Bookworm und früher verwendet, erfasste alle CULs als dialout Gerät.
Eine weitere Erkenntnis was die Rechte bei dieser Schnittstelle betrifft.
Führe ich unter Trixie eine Rechteänderung aus
sudo chmod -R 0777 /dev
ist unter FHEM die Schnittstelle erreichbar.
Nach einem Neustart des Pis ist diese Schnittstelle nicht mehr erreichbar und die Rechte müssten wieder gesetzt werden.
Diese Eigenart kann nur mit der Gruppe plugdev für FHEM behoben werden, wie ihr schon angeführt habt.
Wie sieht das mit den UDEV Regeln aus? Muss da auch etwas angepasst werden was noch nicht betreffend Trixie erwähnt wurde?
Zitat von: Burny4600 am 31 März 2026, 09:58:20Wie sieht das mit den UDEV Regeln aus?
Über das hier bin ich gestolpert:
GOTO="alsa_restore_std" has no matching label (https://github.com/alsa-project/alsa-utils/issues/280)
Zitat von: tomcat.x am 31 März 2026, 10:49:39Über das hier bin ich gestolpert:
GOTO="alsa_restore_std" has no matching label (https://github.com/alsa-project/alsa-utils/issues/280)
Betreffend UDEV Rules hat das nichts mit meiner Feststellung zu tun.
Also nur Erweiterung der plugdev Zuweisung die vor Trixie bei meiner Schnittstelle nicht notwendig war.