CUL with OH 2.4


my CUL worked with previous OH Versions, but somehow it won’t with OH 2.4
this is my log

2019-12-07 15:19:35.120 [WARN ] [io.transport.cul.CULLifecycleManager] - CUL config is NULL, doing nothing
2019-12-07 15:19:35.131 [INFO ] [ternal.serial.CULSerialConfigFactory] - Update config, baudrate = 38400

Minicom with SHIFT+V shows me nothing
in older versions i got “V 1.67 nanoCUL433” as response

my intertechno.cfg



Bus 001 Device 005: ID 2109:0715 VIA Labs, Inc.
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter    
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

ls -l /dev/serial/by-id

total 0
lrwxrwxrwx 1 root root 13 Dec  7 07:23 usb-FTDI_FT232R_USB_UART_A9E5XZFJ-if00-port0 -> ../../ttyUSB0

i tried to recreate the CUL

[15:32:26] openhabian@openhab:~/culfw-code/culfw/Devices/nanoCUL$ nano ~/culfw-code/culfw/clib/rf_send.h
[15:33:25] openhabian@openhab:~/culfw-code/culfw/Devices/nanoCUL$ make

Size before:
   text    data     bss     dec     hex filename
  24480      74    1013   25567    63df nanoCUL.elf

Compiling C: nanoCUL.c
Compiling C: ../../clib/clock.c
Compiling C: ../../clib/fht.c
Compiling C: ../../clib/rf_send.c
Compiling C: ../../clib/rf_receive.c
Compiling C: ../../clib/rf_moritz.c
Compiling C: ../../clib/somfy_rts.c
Compiling C: ../../clib/intertechno.c
Compiling C: ../../clib/kopp-fc.c
Linking: nanoCUL.elf
Creating load file for Flash: nanoCUL.hex
Creating load file for EEPROM: nanoCUL.eep
Creating Extended Listing: nanoCUL.lss
Creating Symbol Table: nanoCUL.sym

Size after:
   text    data     bss     dec     hex filename
  24480      74    1013   25567    63df nanoCUL.elf

AVRDUDE gives me an error

[15:33:48] openhabian@openhab:~/culfw-code/culfw/Devices/nanoCUL$ make program
#@if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
#@if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
#echo out > /sys/class/gpio/gpio17/direction
#echo out > /sys/class/gpio/gpio18/direction
#echo 0 > /sys/class/gpio/gpio17/value
#echo 0 > /sys/class/gpio/gpio18/value
#sleep 1
#echo 1 > /sys/class/gpio/gpio17/value
#sleep 1
#echo 1 > /sys/class/gpio/gpio18/value
avrdude -D -p atmega328p -P /dev/ttyUSB0 -b 57600 -c arduino    -U flash:w:nanoCUL.hex
avrdude: stk500_recv(): programmer is not responding

avrdude done.  Thank you.

make: *** [makefile:227: program] Error 1

how can i fix that ?


If I remember correctly that log does NOT report a problem, the message " config is NULL…" comes immediately before the config is read as you can see I the following line.

On the problems with the CUL not showing its version and the error while trying to recreatetheCUL, this is no openHAB problem, you’d better ask in the apropriate community.

1 Like

Also, since 2.5 will be released later this month, I would recommend trying with 2.5 Milestone 6. There have been major changes between 2.4 & 2.5.

i had time to investigate again.
the problem was to stop openhab for “make program”
now the CUL is back again.

But still a little problem with it.
With Minicom and String:

ON = "is01011100110000010111000010010000"
OFF = "is01011100110000010111000010000000"

the plug is switching immediately.

With Openhab the plug switches super laggy, not always but here and there.
and sometimes not at all… a openhab restart mostly fixes it . but still laggy sometimes
if it doesn’t work at all, i change the Hardware Flow Control in minicom to the opposite YES or NO and then the plug switches again. don’t know where to find a fix for that. any ideas ?

my item:

Switch LED_Printer "LED Drucker (IT)" 	<led_strip>   [ "Switchable" ]
		{ culintertechno="type=raw;commandOn=01011100110000010111000010010000;commandOff=01011100110000010111000010000000" 

Thank you!

Did you try raisng the log-level for the intertechno binding and checking the logs?

only this, and it gives me nothing special:
log:set DEBUG org.openhab.binding.intertechno

In this case I’m out off ideas. I never saw or read of such problem ( working slow but working)
Is the minicom connected to the CUL when you try it with openHAB? I do remember problem when it was connected to “screen”.

currently yes, but not in general.
its not a big deal, but would have been nice to fix that.