nanoCUL: STATE opened nach In-Place Upgrade von Ubuntu LTS 24 auf 26 LTS

[Domek]

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

[KölnSolar]

opened ist ja erst einmal nicht sooo schlecht.

Was steht denn bei verbose=5 und einem set nanocul433 reopen im Log ?

[tostmann]

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:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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.