Workaround tutorial: Using Tellstick without Tellstick Binding

In current 2.4 snapshots the Tellstick Binding seems to be completely broken. Since I haven’t been able to solve the Binding (and haven’t got any response for my requests for help) I’ve instead done some workarounds, thought I’d share them if anyone else has the same problem. Please note that this is not a solution for the problem, just a temporary workaround. Has worked fine for me last week though :slight_smile:

Also note that my setup is kinda simple. Most of my house uses Z-Wave, I’ve only got some old stuff that’s still using 433. So if you’ve got more complicated setup you obviously have to think a bit longer than me :wink:

Device events from OH to Tellstick
When an Item in OH changes state you could simply call tdtool using executeCommandLine() to also change it’s state there. The syntax for this is either "tdtool --on " or "tdtool --off " (assuming you haven’t got any dimmers which I haven’t. Guess that’s possible as well but surely more complicated).

I simply wrote one rule per device, haven’t got that many. The rules ended up like this:

rule "Tellstick workaround 16"
	Item Utebelysning received command
	executeCommandLine("tdtool --" + receivedCommand.toString.toLowerCase + " 16")

Device events from Tellstick to OH
When a key is pressed on a Tellstick device you also want to change the corresponding OH Item. The easiest way to do that is using the scripts in /usr/local/share/telldus/scripts that the Telldus service executes (for more info on this see here). Note that this only works on Linux and also that after you’ve created a script you need to restart the telldusd service so it picks up the new script. Also make sure the script is executable (ie has the x flag set).

My script (/usr/local/share/telldus/scripts/deviceevent/ looks something like the below. The METHOD argument is kinda backwards, hence the case stuff. I’ve only got the one doorbell device I’m interested in, you’ll have to manually add your devices in the same fashion:


case ${METHOD} in

if [ ${DEVICEID} = "20" ] ; then
    curl -X PUT --header "Content-Type: text/plain" --header "Accept: application/json" -d "${status}" "http://cube:8080/rest/items/RingklockaYtterdorr/state"

Sensor events from Tellstick to OH
Sensor readings works about the same way as device events, it’s just another script being called and some other input variables. It’s a tiny bit more complicated checking for the right sensor though, since there can be more sensors with the same id. Just run a “tdtool --list” from the console to check your sensor’s protocol, model and id.

My script (/usr/local/share/telldus/scripts/sensorevent/ Again just add more rows if you’ve got more sensors:


#For sensors that only send one kind of value you can do the following
if [ ${PROTOCOL} = "fineoffset" ] && [ ${MODEL} = "temperature" ] && [ ${SENSORID} = "203" ] ; then
    curl -X PUT --header "Content-Type: text/plain" --header "Accept: application/json" -d "${VALUE}" "http://cube:8080/rest/items/Utetemp_verandan/state"

#For sensors sending different kinds of values (for example temperature and humidity) you'd have to take the type of date into account:
if [ ${PROTOCOL} = "fineoffset" ] && [ ${MODEL} = "temperature" ] && [ ${SENSORID} = "203" ] ; then
	case ${DATATYPE} in
	curl -X PUT --header "Content-Type: text/plain" --header "Accept: application/json" -d "${VALUE}" "http://cube:8080/rest/items/${device}/state"


Thanks for this, hope the binding will be fixed soon ™ :wink:

For those who have temp and humid. sensors, you have to use the datatype variable aswell, like this (oregon sensor):

if [ ${PROTOCOL} = "oregon" ] && [ ${MODEL} = "1A2D" ] && [ ${SENSORID} = "240" ]; then
        if [ ${DATATYPE} -eq 1 ]; then
                curl -X PUT --header "Content-Type: text/plain" --header "Accept: application/json" -d "${VALUE}" "http://box:8080/rest/items/myTempSensorItem/state
        if [ ${DATATYPE} -eq 2 ]; then
                curl -X PUT --header "Content-Type: text/plain" --header "Accept: application/json" -d "${VALUE}" "http://box:8080/rest/items/myHumiditySensorItem/state

The different datatypes are defined as :


1 Like

Just two notes to anyone using this workaround.

Firstly, @jarlebh has now confirmed that he indeed isn’t doing any more work on the Tellstick binding, at least not as it looks now. That might mean that the binding will not be fixed at all, so this temporary workaround might turn out to be a permanent workaround.

Secondly, after a change in 2.4.0 Milestone 4, this workaround won’t work any more if your Items are still linked to broken Tellstick Things (as mine were), so you have to unlink the Items. For more info about this see What is ItemStatePredictedEvent?

edit: Or, as I have learned now, if you trigger the rule on received command instead of changed (and also change triggeringItem.state to receivedCommand) everything works even with the links in place. Updated the first post according to this as well.

1 Like

Thank you for the workaround. Works good. The only thing that confuses me is why the temperature sometimes is updated in Fahrenheit and sometimes in Celsius? Mostly Fahrenheit I would say.

[quote=“Erik_Bergstrom, post:5, topic:49976”]
The only thing that confuses me is why the temperature sometimes is updated in Fahrenheit and sometimes in Celsius? Mostly Fahrenheit I would say.[/quote]

Sounds weird. You mean like it’s 10 degrees outside and suddenly it says it’s 50? Do you get the same fault when you run a “tdtool --list” from your console?

Actually I realized it wasn’t Fahrenheit. It’s jumping between showing temperature and humidity.
Every minute when the tellstick receives new data the value in the Openhab client is jumping back and forth between temperature and humidity. Sometimes it stops an uses the temperature for one minute and the next minute it stops att the humidity value. I’m checking my things and items, feels like I’ve done something wrong.

Ah, sorry! That’s because I only have devices that send one kind of reading, so in my OP I didn’t take the type of data into account. You should look at this comment above. I guess I should update my post a bit before others stumble into this as well :blush:

edit: OP updated, added some more script rows for DATATYPE.

Oh you’re right. I missed that post. Works like a charm now. Thank you so much for your time! :slight_smile:

Just a notice for anyone still using this workaround: In 2.4M6 the binding is working out-of-box again (big thanks to @jannegpriv for your effort in fixing this!) so we can all move back to using it :sunny:

1 Like