[Solved] OpenHab 2.1.0: Intertechno add-on unstable

Hi there,

a few days ago, after having updated OpenHAB to 2.1.0 via the Ubuntu feed in bintray, I have noticed that my ELRO Intertechno devices are not working anymore as expected (they have been before in OpenHAB 2.0).

I am using a 433 MHz CUL, and integration was done via the culintertechno binding, with the entry


in culintertechno.cfg. I am using openhab inside a LXC container by the way and had to “forward” the device from the host via

lxc.mount.entry = /dev/ttyACM1 dev/ttyACM1 none bind,create=file 0 0

in the config of my virtual machine.

The symptoms are: When starting openhab, the ELRO devices work a few times at the beginning, but then do not react to events anymore after a couple of times, and they do not react again.

The default settings do not show any suspicious information in openhab2.log and the expected events (when triggering them) in events.log.

My questions would be:

  • how to continue debugging (what flags? what to do?)
  • any similar experiences, especially with usage inside lxc?

Thanks and best regards,


One more update: Following https://github.com/openhab/openhab1-addons/issues/3910, I have tried to connect to the CUL directly using “screen”, and I could successfully switch my devices on and off by manually typing in the “is”-codes.

So it seems that the connection via LXC is working and that the problem indeed seems to be related to the latest openhab update (since the old version 2.0 was working in the same environment).

Any advice? If not, where should I re-post this question?



You might the consider to change the topic since you do suspect LXC being at least part of the problem.
For information I’m using a CUL with the Intertechno binding to switch power plugs with no problem on OH 2.1

Well, I am not sure whether this is in fact related to LXC, since I have another CUL for Homematic devices (dev/ttyACM0), which runs fine (via the homematic/homegear openhab binding).

Any hints on how to debug/trace the communication to the CUL? What have done in the meantime is to set logging to TRACE in /var/lib/openhab2/etc/org.ops4j.pax.logging.cfg with

log4j.logger.org.openhab.binding.intertechno = TRACE
log4j.logger.org.openhab.io.transport.cul = TRACE

Indeed, there are a few log messages appearing in /var/log/openhab2/openhab.log (see below) - but interestingly switching on/off an openhab item which binds to the channel


is only listed in event.log, but not in openhab.log, so I am not sure whether the channel is somehow working at all.

Any ideas?



017-07-16 13:02:34.278 [DEBUG] [org.openhab.binding.intertechno     ] - BundleEvent STARTING - org.openhab.binding.intertechno
2017-07-16 13:02:34.280 [DEBUG] [hno.internal.CULIntertechnoActivator] - CULIntertechno binding has been started.
2017-07-16 13:02:34.283 [DEBUG] [org.openhab.binding.intertechno     ] - ServiceEvent REGISTERED - {org.openhab.model.item.binding.BindingConfigReader, org.openhab.binding.intertechno.CULIntertechnoBindingProvider}={component.name=org.openhab.binding.intertechno.genericbindingprovider, component.id=173, service.id=293, service.bundleid=185, service.scope=bundle} - org.openhab.binding.intertechno
2017-07-16 13:02:34.289 [DEBUG] [org.openhab.binding.intertechno     ] - BundleEvent STARTED - org.openhab.binding.intertechno
2017-07-16 13:02:34.371 [DEBUG] [org.openhab.binding.intertechno     ] - ServiceEvent REGISTERED - {org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService}={event.topics=openhab/command/*, service.pid=org.openhab.culintertechno, component.name=org.openhab.binding.intertechno.binding, component.id=172, service.id=301, service.bundleid=185, service.scope=bundle} - org.openhab.binding.intertechno
2017-07-16 13:02:34.372 [DEBUG] [org.openhab.io.transport.cul        ] - BundleEvent [unknown:512] - org.openhab.io.transport.cul
2017-07-16 13:02:34.373 [DEBUG] [org.openhab.io.transport.cul        ] - BundleEvent STARTING - org.openhab.io.transport.cul
2017-07-16 13:02:34.373 [DEBUG] [penhab.io.transport.cul.CULActivator] - CUL transport has been started.
2017-07-16 13:02:34.376 [DEBUG] [io.transport.cul.internal.CULManager] - Registering class org.openhab.io.transport.cul.internal.serial.CULSerialHandlerImpl for device type serial
2017-07-16 13:02:34.376 [DEBUG] [io.transport.cul.internal.CULManager] - Registering class org.openhab.io.transport.cul.internal.network.CULNetworkHandlerImpl for device type network
2017-07-16 13:02:34.377 [DEBUG] [org.openhab.io.transport.cul        ] - BundleEvent STARTED - org.openhab.io.transport.cul
2017-07-16 13:02:34.379 [WARN ] [io.transport.cul.CULLifecycleManager] - CUL config is NULL, doing nothing
2017-07-16 13:02:34.380 [INFO ] [ternal.serial.CULSerialConfigFactory] - Update config, baudrate = 38400
2017-07-16 13:02:34.380 [INFO ] [ternal.serial.CULSerialConfigFactory] - Update config, parity = NONE (0)
2017-07-16 13:02:34.380 [DEBUG] [io.transport.cul.internal.CULManager] - Trying to open device serial:/dev/ttyACM1 in mode SLOW_RF
2017-07-16 13:02:34.380 [DEBUG] [io.transport.cul.internal.CULManager] - Searching class for device type serial
2017-07-16 13:02:34.386 [DEBUG] [internal.serial.CULSerialHandlerImpl] - Opening serial CUL connection for /dev/ttyACM1
2017-07-16 13:02:34.424 [DEBUG] [internal.serial.CULSerialHandlerImpl] - Adding serial port event listener
2017-07-16 13:02:34.437 [DEBUG] [port.cul.internal.AbstractCULHandler] - Requesting credit report

Just for the files: I just fixed the problem on my machine, but without the add-on: I have removed the culintertechno channel from the switch and instead created a rule that sends the raw command to the device directly:

rule intertechno_switch
    Item IT_Switch received command
    if (IT_Switch.state == ON) {
       executeCommandLine("/bin/sh@@-c@@echo is000000FFFFFF >/dev/ttyACM1")
    } else {
       executeCommandLine("/bin/sh@@-c@@echo is000000FFFFF0 >/dev/ttyACM1")

So I still suspect the culintertechno binding to be buggy, since accessing the CUL device seems to work without a problem from the openhab user in the LXC container (with this work-around).

Obviously, if possible, I would like to switch back to the culintertechno binding directly (even though it works on other systems), so any further debugging hints are still appreciated.

Well, I do not know whether it’s due to intermediate kernel updates or the recent 2.2 OpenHab update, but the intertechno add-on seems to work correctly again on my system, so this topic can be considered as closed.