CUL with OH2 to run radio plugs (Flamingo AB400S)

I read a lot about CUL and OH2 but I did not find an answer for my issue.

With putty as serial interface for my selfmade cul (1.67 FW) I am able to switch “plug C”.
This is the code which is working:

is00000FF0FF0F -> on
is00000FF0FFF0 -> off

I tried then to do this with OH2 (putty is off)
items entry:

Switch Funk_B “Funksteckdose 2” (EG_Wohnzimmer) { culintertechno=“type=raw;address=00000FF0FF;commandOn=0F;commandOff=F0” }


Switch item=Funk_B label=“Stehlampe” icon=“light”

culintertechno.cfg (fitting to putty settings):


no success.
I tried then this entry in items:

Switch Funk_B “Funksteckdose 2” (EG_Wohnzimmer) { culintertechno=“type=raw;commandOn=00000FF0FF0F;commandOff=00000FF0FFF0” }

same result no success.

Any ideas from you?


In your second try you used a different syntax, which belongs to an updated culintertechno binding. Which binding version do you use? Please check with “bundle:list” on the karaf-console.

What does the log tell you about the connection to the CUL after OH is started and what does it say when a command is initiated ( that will give hints which binding version you are using as well)? Please post the relevant entries.

Your test with the serial interface was not with the plug you try to use with OH, shall we assume that a test with the plug B using the serial interface was working.

My cfg file looks like yours, except the device setting (ttyACM0 in my case) and I do NOT have a data setting (never seen that one).

binding-intertechno1 - 1.11.0 is written in paperUI
how can I access karaf-console with OH running in docker container?

This is in event-log:

2018-03-21 17:40:15.337 [ome.event.ItemCommandEvent] - Item ‘Funk_A’ received command ON
2018-03-21 17:40:15.339 [vent.ItemStateChangedEvent] - Funk_A changed from NULL to ON
2018-03-21 17:40:16.682 [ome.event.ItemCommandEvent] - Item ‘Funk_A’ received command OFF
2018-03-21 17:40:16.683 [vent.ItemStateChangedEvent] - Funk_A changed from ON to OFF
2018-03-21 17:40:18.270 [ome.event.ItemCommandEvent] - Item ‘Funk_B’ received command ON
2018-03-21 17:40:18.273 [vent.ItemStateChangedEvent] - Funk_B changed from NULL to ON
2018-03-21 17:40:19.305 [ome.event.ItemCommandEvent] - Item ‘Funk_B’ received command OFF
2018-03-21 17:40:19.308 [vent.ItemStateChangedEvent] - Funk_B changed from ON to OFF

in openhab.log after restarting container:

[ERROR] [el.item.internal.GenericItemProvider] - Binding configuration of type ‘culintertechno’ of item ‘Funk_B’ could not be parsed correctly.

This is for this format: { culintertechno=“type=raw;commandOn=00000F0FFF0F;commandOff=00000F0FFFF0” }

all three plugs are working in putty

I delted the data entry, no effect on this issue.


Reading this error I believe your are on the binding that needx touse the first syntax ( the other one is probably not merged yet).
I have no experience with working with a docker setup, the problem migth be there.

See This for connecting to the Karaf console on a docker setup.

After the start-up of OH, are you getting these messages in the log?

19:28:21.899 [WARN ] [.io.transport.cul.CULLifecycleManager] - CUL config is NULL, doing nothing
19:28:21.906 [INFO ] [nternal.serial.CULSerialConfigFactory] - Update config, baudrate = 38400
19:28:21.909 [INFO ] [nternal.serial.CULSerialConfigFactory] - Update config, parity = NONE (0)

The “…doing nothing” is NO problem, I have that in my working system!

I guess we found something:

2018-03-21 21:29:28.615 [WARN ] [io.transport.cul.CULLifecycleManager] - CUL config is NULL, doing nothing
2018-03-21 21:29:28.641 [ERROR] [org.apache.felix.configadmin ] - [org.osgi.service.event.EventHandler,, id=321, bundle=220/mvn:org.openhab.binding/org.openhab.binding.intertechno/1.11.0]: Updating property device of configuration org.openhab.culintertechno caused a problem: Invalid device name ‘/dev/ttyUSB1’. Must be ‘DEVICETYPE:ADDRESS’

I changed the cul cfg file to this:

Now it is looking better, no not really :slight_smile:

2018-03-21 21:56:44.670 [WARN ] [io.transport.cul.CULLifecycleManager] - CUL config is NULL, doing nothing
2018-03-21 21:56:44.684 [INFO ] [ternal.serial.CULSerialConfigFactory] - Update config, baudrate = 38400
2018-03-21 21:56:44.686 [INFO ] [ternal.serial.CULSerialConfigFactory] - Update config, parity = NONE (0)
2018-03-21 21:56:44.751 [WARN ] [io.transport.cul.CULLifecycleManager] - Can't open CUL
	at []
	at []
	at []
	at []
	at []
	at []
	at org.openhab.binding.intertechno.internal.CULIntertechnoBinding.updated( [220:org.openhab.binding.intertechno:1.11.0]
	at [7:org.apache.felix.configadmin:1.8.16]
	at [7:org.apache.felix.configadmin:1.8.16]
	at [7:org.apache.felix.configadmin:1.8.16]
	at$ManagedServiceUpdate.provide( [7:org.apache.felix.configadmin:1.8.16]
	at$ [7:org.apache.felix.configadmin:1.8.16]
	at [7:org.apache.felix.configadmin:1.8.16]
	at [7:org.apache.felix.configadmin:1.8.16]
	at [?:?]
Caused by:
	at ~[?:?]
	at ~[?:?]
	... 14 more
2018-03-21 21:56:44.777 [ERROR] [org.apache.felix.configadmin        ] - [org.osgi.service.event.EventHandler,, id=322, bundle=220/mvn:org.openhab.binding/org.openhab.binding.intertechno/1.11.0]: Unexpected problem updating configuration org.openhab.culintertechno
java.lang.NullPointerException: null
	at org.openhab.binding.intertechno.internal.CULIntertechnoBinding$ [220:org.openhab.binding.intertechno:1.11.0]
	at []
	at []
	at org.openhab.binding.intertechno.internal.CULIntertechnoBinding.updated( [220:org.openhab.binding.intertechno:1.11.0]
	at [7:org.apache.felix.configadmin:1.8.16]
	at [7:org.apache.felix.configadmin:1.8.16]
	at [7:org.apache.felix.configadmin:1.8.16]
	at$ManagedServiceUpdate.provide( [7:org.apache.felix.configadmin:1.8.16]
	at$ [7:org.apache.felix.configadmin:1.8.16]
	at [7:org.apache.felix.configadmin:1.8.16]
	at [7:org.apache.felix.configadmin:1.8.16]
	at [?:?]

The “Can’t open CUL” again.
You need to put the user that runs OH into the dialout group or run OH as user root (not suggested).
since you are using a custom made CUL you migth also need to change the as talked about in here.

…and sorry, I should have spotted the missing “serial”.

The actual documentation seems to have the last covered as well in here.

I added again the user to dialout and saw a missing information in my docker start comand

I did not start the container with the link to ttyUSB1 (this was missing --device=/dev/ttyUSB1) because I attached it later



1 Like

One more question on this.

I found here

that I can not link to a ‘by-id’ address in culintertechno.cfg. But I face the issue that my USB device received a different number after a reboot.

How can I prevent this?