Intertechno binding

Hey There,

I’ve been reading along in this community for some days now, because I am trying to port my FHEM installation to OpenHAB.
Unfortunately I have run into some unsolvable problems (for me, at last) when trying to implement the intertechno binding.

I am using a selfmade CUL 433 Mhz running a-culfw, which should look to OpenHAB like a original CUL from Busware. Am I right here? Does OpenHAB at this point support 433 Mhz CUL? My Setup works fine on FHEM.

2015-12-06 08:45:33.790 [DEBUG] [.io.transport.cul.CULActivator] - CUL transport has been started.
2015-12-06 08:45:33.861 [DEBUG] [] - Registering class for device type serial
2015-12-06 08:45:33.864 [DEBUG] [] - Registering class for device type network
2015-12-06 08:45:34.015 [INFO ] [.service.AbstractActiveService] - HTTP Refresh Service has been started
2015-12-06 08:45:34.773 [INFO ] [.service.AbstractActiveService] - Hue Refresh Service has been started
2015-12-06 08:45:34.777 [DEBUG] [] - Trying to open device serial:/dev/ttyUSB0 in mode SLOW_RF
2015-12-06 08:45:34.779 [DEBUG] [] - Searching class for device type serial
2015-12-06 08:45:34.842 [DEBUG] [o.i.t.c.i.CULSerialHandlerImpl] - Opening serial CUL connection for /dev/ttyUSB0
2015-12-06 08:45:36.885 [ERROR] [.o.b.i.i.CULIntertechnoBinding] - Can’t open CUL
at ~[na:na]
at ~[na:na]
at ~[bundlefile:na]
at ~[bundlefile:na]
at ~[bundlefile:na]
at org.openhab.binding.intertechno.internal.CULIntertechnoBinding.bindCULHandler( [bundlefile:na]
at org.openhab.binding.intertechno.internal.CULIntertechnoBinding.setNewDeviceName( [bundlefile:na]
at org.openhab.binding.intertechno.internal.CULIntertechnoBinding.updated( [bundlefile:na]
at$ [org.eclipse.equinox.cm_1.0.400.v20120522-1841.jar:na]
at$ [org.eclipse.equinox.cm_1.0.400.v20120522-1841.jar:na]
Caused by: null
at ~[na:na]
at ~[na:na]
… 9 common frames omitted
2015-12-06 08:45:36.893 [INFO ] [.service.AbstractActiveService] - CULIntertechno Refresh Service has been started

Thanks a ton for any help!


[quote=“lwienhues, post:1, topic:4812, full:true”]
Does OpenHAB at this point support 433 Mhz CUL? [/quote]

Yes, it should.

It looks like your system can’t talk to the port, maybe you’ve picked the wrong port (/dev/ttyUSB0) or it’s a permission problem.
What system are you on?


thanks for your fast reply!

I double checked the port, which should be correct.
My system is a Raspberry Pi 2 running Raspian Wheezy. I start OpenHAB via /etc/init.d/ as root (I think)
So there shouldn’t be permission Problems, right?

Thanks again!

My openhab.cfg:


My test.items:

Switch Test_Licht_A_5 “Intertechno” (Wohnzimmer) {culintertechno=“type=raw;address=000FF0F0FF;commandOn=FF;commandOff=F0”}

Seems like it was a permission problem. If I execute the manualy as root, it seems to send.

2015-12-06 11:31:42.985 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler] - Sending raw message to CUL /dev/ttyUSB0: ‘is000000000FFF’
2015-12-06 11:31:42.990 [INFO ] [runtime.busevents ] - Light_GF_Corridor_Ceiling received command ON
2015-12-06 11:31:43.007 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler] - Requesting credit report

Unfortunately it still doesn’t work. The code should be correct since I know it from FHEM.

What does the “is” in ‘is000000000FFF’ stand for?

I am using ELRO type plugs with 10 dip-swiches

Thanks again for any help!

[quote=“lwienhues, post:5, topic:4812, full:true”]
Unfortunately it still doesn’t work. The code should be correct since I know it from FHEM.[/quote]

Sorry, I don’t know, I’m not using this binding. :sunglasses:

[quote=“lwienhues, post:5, topic:4812, full:true”]
If I execute the manualy as root, it seems to send.[/quote]

That is the way to do it if you did a manual install via copying into /opt/openhab or getting the files via wget.
Maybe someone who is using this binding can be of any further help.

Good luck.

It cost me some time, but I found the problem.
My selfmade CUL needs a baud rate of 38400 to communicate. Default in OpenHAB seems to be 9400.


as in the fs20 binding works. Maybe one schould implement this possibility into the wiki.

Thanks for your help!

[quote=“lwienhues, post:7, topic:4812, full:true”]
It cost me some time, but I found the problem.[/quote]

Good. Happy switching. :evergreen_tree:

Well, culintertechno:baudrate=38400 doesn’t seem to work after all.
The workaround that helped me, without me noticing at first, was opening a screen session with screen /dev/ttyUSB0 38400
I can then close the session again and openHAB can communicate with the nanoCUL.

Is there a simple way to implement culintertechno:baudrate= in the Intertechno add-on?

As I have exactly the same problem, I started looking a bit at the code and it looks to me as if there’s no way to configure the baud rate when cul is used through intertechno (as this was only implemented in the fs20) binding :frowning:

I did try to hack in the code for the baudrate, but that does not seem to be enough. I’m wondering if there is something else as well. The workaround with the screen session is useful to know.

Did some more investigation, looks like also the parity is different. Going to play around some more. Does anyone know if there is someone else working on the cul transport? There seem to be a couple bugs around allowing to configure serial settings globally instead of each individual binding?

Got it working now with hardcoded baud + parity. What we need is: which I might implement if no one else is willing to.

Btw. I did the changes and I’m now waiting for the PR to get merged:

I also found an issue with my nanocul. It only worked until I restarted openhab. After further investigations I traced it down to an issue with setting the repetitions for intertechno. After commenting this part out it seems to work fine through restarts :slightly_smiling: I have a question open on the developer of the alternative firmware but as soon as the first pull request is merged I’ll probably also add something to allow disabling of sending those startup parameters for intertechno as they are not really needed anyway.

Hi Lukas,
not sure, if this is still open…fought for the past two weeks with similar problems - and for my opinion also the Wiki is wrong: The group address is “A, B, C, D…” for the classic series - and not “I,II,III,IV,…”

ALSO, it’s not possible to use the absolute device name in the openhab.cfg:

This one works:


And this one doesn’t work:


If someone else looks for a solution with Intertechno problems, here is it how I got everything working:


####################### Intertechno (Licht) #######################

That’s the item definition:

Switch CUL_Licht_TV_Halogen  { culintertechno="type=classic;group=A;address=1" }

And this is what the sitemap looks like:

Switch item=CUL_Licht_TV_Halogen label="Licht TV (Halogen)" mappings=[ON="ON",OFF="OFF"]

Let’s hope, it saves some other people those needless hours I had to spend. But now it’s working :slight_smile:


P.S.: Using now an original CUL from busware - and here’s the address of the stick /dev/ttyACM0

Ah, just found this:
The I,II,III and IV is valid for the FLS system!

Hi all, I use this binding for using RF CC1101?? CC1101 is connected to Raspberry running Openhab 1.8.3.
Or any advice for me to use CC1101!!