Hallo zusammen,
kurz noch vor dem Ubuntu Upgrade funktionierte mein nanoCUL einwandfrei.
Nach Upgrade von Ubuntu LTS 24 auf 26 LTS, STATE opened.
Ich dachet, die Hardware und oder Kabel wäre defekt. Also ein neues bestellt:
------------
nanoCUL Funksender / Endlich mit USB-C / 433 MHz
CC1101 CUL / FHEM & openHAB
Gehäuse: Kunststoff (3D-Druck); USB-Chip:
CH340G; Frequenz: 433 MHz; Firmware: culfw;
USB-Zubehör: Ohne; Antenne: SMA-Buchse
------------
Am Rechner mit mincom auf dem linux, erfolgreich getstet:
V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) nanoCUL433 (F-Band: 433MHz)
ls -l /dev/serial/by-path/
total 0
lrwxrwxrwx 1 root root 13 Oct 28 20:46 pci-0000:00:14.0-usb-0:13:1.0-port0 -> ../../ttyUSB0
Im Fhem alles neu angelegt, leider STATE permanent aud opened
FHEM durchgastert,usw. Ich habe schon mit KI 2 Stunde fast(alles) ausprobier, k e i n Erfolg.
Die Rolladen bleiben unten: :(
Internals:
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-path/pci-0000:00:14.0-usb-0:13:1.0-port0@38400 1234
DeviceName /dev/serial/by-path/pci-0000:00:14.0-usb-0:13:1.0-port0@38400
FHTID 1234
FUUID 6ae23ff9-f33f-e04a-ca3d-f6bc697eafb5cdb3
NAME nanocul433
NR 697
STATE opened
TYPE CUL
devioNoSTATE 1
eventCount 8
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................................$
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-10-28 20:42:01 state opened
2026-10-28 20:05:00 uptime No answer
2026-10-28 20:27:44 version No answer
Attributes:
dummy 0
rfmode SlowRF
opened ist ja erst einmal nicht sooo schlecht.
Was steht denn bei verbose=5 und einem set nanocul433 reopen im Log ?
Das liegt sehr wahrscheinlich am nanoCUL/Ubuntu 26.04-Mix: Das Perl-Modul Device::SerialPort, über das FHEM die Schnittstelle einstellt, setzt dort 15 Baud statt 38400. Im Log steht trotzdem "Setting nanocul433 serial parameters to 38400,8,N,1". FHEM bekommt auf V keine Antwort, schließt nach drei Versuchen den Port ("Cannot init ..., ignoring it (nanocul433)") und lässt STATE auf "opened" stehen, daher fehlt FD und CMDS ist leer. minicom nutzt das Modul nicht, deshalb geht es damit.
Ursache: Seit glibc 2.42 ist B38400 = 38400 statt 15, das Ubuntu-Paket libdevice-serialport-perl 1.04-4build5 ist aber noch gegen die alten Header gebaut. Nachgestellt unter 26.04 an einem Pseudo-Terminal (ohne nanoCUL), unter 24.04 stimmt die Baudrate.
Prüfen:
perl -MPOSIX -MDevice::SerialPort -e 'print POSIX::B38400(), " ", Device::SerialPort::Bits::get_hash()->{B38400}, "\n"'Zwei verschiedene Zahlen (z.B. 38400 15) = betroffen.
Abhilfe für FHEM direkt auf dem Rechner (ein Docker-Container hat sein eigenes Perl):
sudo apt install build-essential cpanminus
sudo cpanm --reinstall Device::SerialPortDanach FHEM neu starten (z.B. shutdown restart). Der Prüfbefehl zeigt dann 38400 38400.
Ein originaler busware CUL ist davon übrigens nicht betroffen: Er hängt per USB-CDC am Rechner, die Baudrate ist dort nur ein Scheinwert, den die Firmware ignoriert. Es trifft Nachbauten, die über einen USB-Seriell-Wandler (hier CH340) angebunden sind. Sag bitte Bescheid, ob es das war.