[Intertechno] Support for Intertechno V3 protocol

Hi there,
I’ve created a pullrequest to support the V3 protocol by the Intertechno binding.

I’m using it for about a month now and I would be happy, if someone can test it, as there are a bunch of changes under the hood.

You can download the binding here: org.openhab.binding.intertechno-1.11.0-SNAPSHOT.jar
or you can use the master branch of this repo to compile it by your own.
Just copy it to your addons folder.


If nobody else will test, I can da but start earliest at end of November since I`m far from home until then.
Doing any testing with the system being far away would cause the WAF go down dramatically (had that last wee, when switching off a light, which should have remained on until she returned home. GREAT TROUBLE).
My test however would be of limited value because I can test only against old (V1) protocols, and I have never had any problems with race conditions.

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.