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 | tee /sys/bus/usb/drivers/unbind > /dev/null
echo 1-1.4.7 | tee /sys/bus/usb/drivers/unbind > /dev/null
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