[Intertechno] Support for Intertechno V3 protocol

Every test ist highly appreciated, because the former systems should even work as before. So your test will be valuable.
Please be aware, that I addressed two issues. This one mentioned here to support the V3 Interrechno protocol and another one (with its own thread here) concerning a race condition with the CUL transport. If you are willing to test both, it would be great. Your system should be working as expected as before.

I’m aware of that, didn’t to spam all three threads!

Hi Jürgen,
did you find time to test the changes?

Not yet.( Real world business did come in).
My plan is to install the new binding on other hardware (already ordered) and test it on there.

Hi Mik,
I tried to test your binding in my openHAB2 installation and got this error in the log:

2017-12-18 22:31:55.407 [ERROR] [org.openhab.binding.intertechno ] - FrameworkEvent ERROR - org.openhab.binding.intertechno
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.intertechno [213]
Unresolved requirement: Import-Package: org.openhab.core.binding

    at org.eclipse.osgi.container.Module.start(Module.java:444) [?:?]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1620) [?:?]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1600) [?:?]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1571) [?:?]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1514) [?:?]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [?:?]
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
    at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]

I guess your binding only runs with openHAB1?

Hi Martin,
due to the manual installation of the bundle, the dependencies are not resolved automaticaly. On OH 2 you have to install the 1.x compatibility layer as I described here.

Thanks for testing and I appreciate any feedback on this topic.


Hi there, I have v3 IT, but I am not sure how to “define” them in items.
Could you give me an example please? from that I can compare it to my fhem definition to work.



here is the description of the changes I made:

Intertechno V3

{ culintertechno="type=v3;id=01101011000011110000000000;channel=2" }

You have to provide the 26 digits id and the channel (0-15). Optional, you can provide the group parameter (with value “1”) , which results in switching all items with the given id.

{ culintertechno="type=v3;id=01101011000011110000000000;group=1" }

Raw mode

If you have an unsupported intertechno device you can fallback to the raw mode

{ culintertechno="type=raw;commandOn=FF00FF00FF;commandOff=FF00FF00F0" }

This configuration allows you to manual specify the complete commands to send in either ON or OFF state. The given commands will be sent directly to the CUL (prefixed with “is”).

EDIT: Added the description for RAW mode.

I appreciate your feedback, if it’s working for you (or not).


Not succeeded yet due to my n00b-ness.

I only just switched over to OpenHAB and only just barely got some CUL-stuff working.
It took me 1.5 days to learn that /dev/serial/by-id/… does not work (will figure out why later), but /dev/ttyUSBx works…

Anyway, on FHEM, I have:

define socket5_switch IT 01011011001000001011100010 0 0000

Any guess on how that should work on your thing?
Also, how can I turn on DEBUG for your stuff?

Right now, I get:
19:36:57.575 [ERROR] [el.item.internal.GenericItemProvider] - Binding configuration of type ‘culintertechno’ of item ‘Funkstecker1’ could not be parsed correctly.
at org.openhab.binding.intertechno.internal.CULIntertechnoGenericBindingProvider.processBindingConfiguration(CULIntertechnoGenericBindingProvider.java:70)[190:org.openhab.binding.intertechno:1.10.0]
at org.openhab.core.binding.internal.BindingConfigReaderDelegate.processBindingConfiguration(BindingConfigReaderDelegate.java:48)[185:org.openhab.core.compat1x:2.1.0]
at org.eclipse.smarthome.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:325)[123:org.eclipse.smarthome.model.item:0.9.0.b5]
at org.eclipse.smarthome.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:297)[123:org.eclipse.smarthome.model.item:0.9.0.b5]
at org.eclipse.smarthome.model.item.internal.GenericItemProvider.processBindingConfigsFromModel(GenericItemProvider.java:182)[123:org.eclipse.smarthome.model.item:0.9.0.b5]
at org.eclipse.smarthome.model.item.internal.GenericItemProvider.modelChanged(GenericItemProvider.java:367)[123:org.eclipse.smarthome.model.item:0.9.0.b5]
at org.eclipse.smarthome.model.core.internal.ModelRepositoryImpl.notifyListeners(ModelRepositoryImpl.java:286)[122:org.eclipse.smarthome.model.core:0.9.0.b5]
at org.eclipse.smarthome.model.core.internal.ModelRepositoryImpl.addOrRefreshModel(ModelRepositoryImpl.java:136)[122:org.eclipse.smarthome.model.core:0.9.0.b5]
at org.eclipse.smarthome.model.core.internal.folder.FolderObserver.checkFile(FolderObserver.java:234)[122:org.eclipse.smarthome.model.core:0.9.0.b5]
at org.eclipse.smarthome.model.core.internal.folder.FolderObserver.processWatchEvent(FolderObserver.java:297)[122:org.eclipse.smarthome.model.core:0.9.0.b5]
at org.eclipse.smarthome.core.service.WatchQueueReader.run(WatchQueueReader.java:206)[98:org.eclipse.smarthome.core:0.9.0.b5]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_152]

The RAW mode does not seem to work for me either.

I set it as:
Switch Funkstecker9 "Funkstecker IT Test9"{ culintertechno="type=raw;commandOn=0F0F0FFFFFFF;commandOff=1F0F0FFFFFFF"}


21:35:14.872 [ERROR] [el.item.internal.GenericItemProvider] - Binding configuration of type 'culintertechno' of item 'Funkstecker9' could not be parsed correctly.
java.lang.ArrayIndexOutOfBoundsException: 2
	at org.openhab.binding.intertechno.internal.parser.RawParser.parseAddress(RawParser.java:30)
	at org.openhab.binding.intertechno.internal.CULIntertechnoGenericBindingProvider.processBindingConfiguration(CULIntertechnoGenericBindingProvider.java:70)
	at org.openhab.core.binding.internal.BindingConfigReaderDelegate.processBindingConfiguration(BindingConfigReaderDelegate.java:48)
	at org.eclipse.smarthome.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:325)
	at org.eclipse.smarthome.model.item.internal.GenericItemProvider.dispatchBindingsPerType(GenericItemProvider.java:281)
	at org.eclipse.smarthome.model.item.internal.GenericItemProvider.addBindingConfigReader(GenericItemProvider.java:119)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.8.0_152]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_152]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_152]
	at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_152]
	at org.apache.felix.scr.impl.inject.BaseMethod.invokeMethod(BaseMethod.java:224)[31:org.apache.felix.scr:2.0.6]
	at org.apache.felix.scr.impl.inject.BaseMethod.access$500(BaseMethod.java:39)[31:org.apache.felix.scr:2.0.6]
	at org.apache.felix.scr.impl.inject.BaseMethod$Resolved.invoke(BaseMethod.java:617)[31:org.apache.felix.scr:2.0.6]
	at org.apache.felix.scr.impl.inject.BaseMethod.invoke(BaseMethod.java:501)[31:org.apache.felix.scr:2.0.6]
	at org.apache.felix.scr.impl.inject.BindMethod.invoke(BindMethod.java:655)[31:org.apache.felix.scr:2.0.6]

I removed the original intertechno binding, and it cured the previously mentioned error, but…

Switch Funkstecker2 "Test2" { culintertechno="type=raw;commandOn=0F0F0FFFFFFF;commandOff=1F0F0FFFFFFF" }

(I know it is abnormal, it is a weird 433MHz socket I have)

It does not output the signal written there:

:36:10.342 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'Funkstecker2' received command ON
22:36:10.354 [INFO ] [marthome.event.ItemStateChangedEvent] - Funkstecker2 changed from NULL to ON
22:36:10.361 [DEBUG] [port.cul.internal.AbstractCULHandler] - Requesting credit report
22:36:10.627 [DEBUG] [port.cul.internal.AbstractCULHandler] - Received raw message from CUL: isFF00FF00FF
22:36:10.631 [DEBUG] [port.cul.internal.AbstractCULHandler] - Requesting credit report
22:36:10.657 [DEBUG] [port.cul.internal.AbstractCULHandler] - Received raw message from CUL: 00  900
22:36:10.662 [DEBUG] [port.cul.internal.AbstractCULHandler] - credit10ms = 900
22:36:10.760 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'Funkstecker2' received command OFF
22:36:10.774 [INFO ] [marthome.event.ItemStateChangedEvent] - Funkstecker2 changed from ON to OFF
22:36:10.792 [DEBUG] [port.cul.internal.AbstractCULHandler] - Requesting credit report
22:36:11.057 [DEBUG] [port.cul.internal.AbstractCULHandler] - Received raw message from CUL: 00  900
22:36:11.059 [DEBUG] [port.cul.internal.AbstractCULHandler] - credit10ms = 900
22:36:11.082 [DEBUG] [port.cul.internal.AbstractCULHandler] - Received raw message from CUL: isFF00FF00F0

Not sure why it ignores my command completely…

EDIT this weird phenomena was resolved after removing the original intertechno binding AND restarting

I’m happy to hear it’s working :+1:

It works perfectly (I repeated this message on your other thread).

a) For the first time my v3 is working on OpenHab (match what i could do on FHEM).
b) My crappy eHome sockets, are working on OpenHab correctly (something I could not do on FHEM).


Did my test on the new system, seems to working.
I’m using only V1 Intertechno-like plugs, so I can’t say anything about the V3 protokoll.
Regarding the race condition I can’t say anything either, since I didn’t observe any race-condition with or without your binding.
All my mentioned problems of plugs not consitendly switching are more related to my hardware (my guess is that keeping them in the cellar for 11 month makes them a bit unpredictable). That was the reason for reporting late!

I do like the new syntax for the “raw” mode.

Good work.

Hey guys,

thanks for your feedback. I think, there should now be no issues with this binding. The changes also aren’t that complex. The CUL transport has more inner changes to the logic. I was expecting more trouble on it. Anyway, you tested it too and I’m glad it works.
Im going to ask for merging the pull request, so this changes will appear in the future releases.


1 Like

I hope they get merged! Great work.


one question to the Binding. Do I need homegear in between being able to use my NanoCUL to receive IT messages? I’ve an PIR-1000 motion detector and would like to use it for scenarios.


Hi Becksen,
as far as I know, the intertechno binding is not able to receive commands, whether from a remote control nor a PIR sensor.

Yeah, so far I have not been able to do this either.
It is a shame, it something I loved about fhem.

Also fhem could detect IT codes by itself since it listened to the received signals.

I guess, we could setup the nanoCUL as a serial device binding, and use Regex to detect certain codes?

In the changes, I did on the CUL transport, I added some trace information. You can see all serial data, which is sent to and received from the CUL. The other day, I wanted to add a new remote and thought I could use the trace data to determine the code. But no data was received by the CUL or rather sent over serial connection.
As I can see so far, no X21 command is send to the CUL to provide receiving information. There is no implementation to handle such information, either.
Maybe, I can implement something like that, if I find some time. But I think a OH2 version of the binding should be developed than. There are some mechanics to create items, when a radio packet is received, and so on.