I don’t have any device with the local api, so I really don’t have any incentive to do that. 
I’m using the Tellstick binding for controlling a subset of my lights at home.
I have a rule that executes the following where the top three devices are controlled via TellstickDuo.
if(dark.state == ON){
hallway_bureau_light.sendCommand(ON)
corner_light.sendCommand(ON)
tv_light.sendCommand(ON)
workroom_desk.sendCommand(30)
}
However it seems that most of the times the rule triggers only 1 or 2 of the items are actually turned on although the state in OpenHAB logs and phone app is changed. In my mind this would indicate signal problems but I can count the number of times this has happened when manually switching a light using two fingers.
Therefore it seems unbelievable that this is a distance or interference issue. Is this a known error? Any way to fix it? Adding a delay is the one thing I can possibly think of trying (not preferred of course).
Edit: Should probably clarify now that Telldus has updated its product series. Using Tellstick Duo 433 Mhz 
Have you tried changing the “repeat” setting on the device Things? I have it set to 2 on most of my devices, but higher on ones that sometimes don’t react…
This seems to have helped. I have not experienced that many problems lately.
While we’re at it, I have a delay (in the UI’s, habpanel, app etc.) when flipping switches that are configured with the tellstick binding.
I switch it, it switches back and then after a few seconds it actually switches. Is this due to the binding reading the tdtool status? Does anyone know how one could eliminate this? My only idea is to create an extra switch item + rule for all items but that feels like a mess.
I can now report that the openHAB image/installation tool openhabian have a script for installing Telldus Core. As some of you may noted Telldus have moved their “APT” repositories and is also providing a pre-compiled 64-bit build. If any of you notice issues with the script please make me aware and I will try to fix it.
That’s interesting. Anyone really got a 64 bit OH working together with 64 bit Telldus Core? I was really struggling with this and ended up running everything in 32 bits instead because I couldn’t get it to work.
So, does this binding work in latest snapshot builds for anyone else? Just upgraded from 2.3.0 stable and Tellstick stuff doesn’t seem to work at all here now. Any known problems, @jarlebh?
What happens when I start the binding is that I get “java.lang.IllegalArgumentException: Invalid calling convention 63” which is super weird. This is the exact same error I got when I tried to get this binding running on an arm64 server and then I came to the conclusion it had to do with wrong architecture binaries being called by JNA, but now I’m in a pure 32 bit environment.
Anyone else has this up and running?
I’ve created a ticket for this now: https://github.com/openhab/openhab2-addons/issues/3849
In the meanwhile I’ve worked around the problems using executeCommandLine() calls to tdtool and with scripts in /usr/local/share/telldus/scripts calling OH REST API via curl. So if anyone wants to run Tellstick without the Tellstick Binding, just ask me and I can elaborate 
I have the same problem that my Tellstick binding does not find the bridge.
@DanielMalmgren: I am interested in getting more details on your workaround using executeCommandLine(). Calling tdtools from commandline does work so my Tellstick Duo is working.
Thanks a lot. Using the workaround rule works like a charm. I might even keep it for good.
I had been looking for a way to get the events from the Nexa remotes to OH and your script on device events is just what I was looking for as well. There I have a little challenge now: it works perfectly all the way up to controlling my lamp when using a remote but not when I use my door contact. If I just change the ID in the script to the ID of the door contact then everything in OH looks OK. I do get the same log messages and it states that it sent the command line command to tdtools. But the lamp itself does not change its status. Any idea what this could be?
Using the the remote (just changing the ID in the script) or controlling the lamp from the OH Android app works.
I would also like to use your script for my sensor. The problem is that my sensor provides humidity and temperature data. The script sends then both data in quick succession to OH. I somehow need to separate the two. Since the data format is different (humidity is integer, temperature is a decimal with one digit) I assume it is best to create two items in OH, check in the script if it is temperature or humidity and then send it to the right item. I have no experience with Linux scripts. Do you have a suggestion on how to check this best?
Once again, thanks for the workaround tutorial.
Could it be the user running OH not having permissions? Try running the tdtool command as the openhab user and see if that works.
As for the humidity and temperature sensor I think you need to look at the argument $DATATYPE in the script, it will be different for the different types of data.
The simple one first:
This was exactly it. Once again, thanks a lot!
I just needed to add && [ ${DATATYPE} = “1” ] to the script to make it work. So in total it looks now like this and seems to work:
#!/bin/bash
if [ ${PROTOCOL} = "mandolyn" ] && [ ${MODEL} = "temperaturehumidity" ] && [ ${SENSORID} = "11" ] && [ ${DATATYPE} = "1" ] ; then
curl -X PUT --header "Content-Type: text/plain" --header "Accept: application/json" -d "${VALUE}" "http://aaron.lan:8080/rest/items/Livingroom_Temp_actual/state"
fi
if [ ${PROTOCOL} = "mandolyn" ] && [ ${MODEL} = "temperaturehumidity" ] && [ ${SENSORID} = "11" ] && [ ${DATATYPE} = "2" ] ; then
curl -X PUT --header "Content-Type: text/plain" --header "Accept: application/json" -d "${VALUE}" "http://aaron.lan:8080/rest/items/Livingroom_Humid_actual/state"
fi
Now to the tricky and confusing one. I am trying to control an OH item using a Nexa door contact which should be from OH’s point of view just like a switch. All works fine with the remote contorl (ID=14) but when I change the ID to “13” which is the ID of the Door/Window sensor then everything in OH looks OK but it does not work. I now configured the script to listen to both IDs:
#!/bin/bash
case ${METHOD} in
1)
status="ON"
;;
2)
status="OFF"
;;
esac
if [ ${DEVICEID} = "13" ] || [ ${DEVICEID} = "14" ] ; then
curl -X PUT --header "Content-Type: text/plain" --header "Accept: application/json" -d "${status}" "http://aaron.lan:8080/rest/items/Jans_Room_heater/state"
fi
Everything works OK with device “14” (remote control). But when using device “13” (door contact) everything looks the same in the OH log but the status of the remote controlled outlet does not change. This is the OH log for the successful switching using the remote:
2018-08-25 12:10:56.510 [vent.ItemStateChangedEvent] - Jans_Room_heater changed from ON to OFF
2018-08-25 12:10:56.547 [INFO ] [lipse.smarthome.io.net.exec.ExecUtil] - executed commandLine ‘tdtool --off Nexa_07_TS’
2018-08-25 12:10:59.855 [vent.ItemStateChangedEvent] - Jans_Room_heater changed from OFF to ON
2018-08-25 12:10:59.867 [INFO ] [lipse.smarthome.io.net.exec.ExecUtil] - executed commandLine ‘tdtool --on Nexa_07_TS’
And this is the OH log for the unsucessful switching using the door contact:
2018-08-25 12:11:06.175 [vent.ItemStateChangedEvent] - Jans_Room_heater changed from ON to OFF
2018-08-25 12:11:06.195 [INFO ] [lipse.smarthome.io.net.exec.ExecUtil] - executed commandLine ‘tdtool --off Nexa_07_TS’
2018-08-25 12:11:11.441 [vent.ItemStateChangedEvent] - Jans_Room_heater changed from OFF to ON
2018-08-25 12:11:11.452 [INFO ] [lipse.smarthome.io.net.exec.ExecUtil] - executed commandLine ‘tdtool --on Nexa_07_TS’
The rule I am using is:
rule "Tellstick workaround Nexa 7"
when
Item Jans_Room_heater changed
then
executeCommandLine("tdtool --" + triggeringItem.state.toString.toLowerCase + " Nexa_07_TS")
end
I cannot see a difference and have no idea where to continue my investigation. Any suggestion is welcome.
Well, that’s very weird, can’t see any difference at all. It’s calling tdtool with the exact same arguments, so all the OH stuff is working as it should. You sure it just wasn’t a coincidence that the switch didn’t catch the signal?
Also, I think I will try to get an admin to move these last few post to the thread about my workaround instead, since they really has nothing with the Binding to do 
(I flagged it now. To any admin seeing this, could you please move this and the three posts above it to Workaround tutorial: Using Tellstick without Tellstick Binding instead?)
I agree that it should be moved. I did not realise that I was posting in the wrong thread 
Just to keep the posts together one more on my issue. I did investigate a bit more and the only thing that I can think of is some kind of collision on the RF channel. When I activate the door contact is sends several times the switch command, and the last one apparently after OH sends the command via the command line to the power outlet. When I changed the rule so that it triggers when “received update” instead of when “changed” the outlet gets 2-3 times the switch command via tdtool and usually works. But it is not 100% reliable. It seems to switch the status of the OH item reliably though. Usually I will not use the door contact to directly trigger a RF switch so this might not be a real problem. The plan is to get warned if a window is open too long in winter or when leaving the house.
Hm, only your own post was flagged - and no, unfortunately I cannot move your posts, I can only hide them…
Ok. I guess the posts will have to linger here. Doesn’t seem like this binding is much alive any more anyway
Did anyone get the tellstick powersensors to work?
When i changed from 2.3.0 with the binding that @jarlebh posted to a clean 2.4 i can fing all objects, but the values are not working.
Hi
- Install telldus live via paper-ui, with all the API-keys.
- Then my items should show up in the inbox?
- Non of my items from telldus-live show up in inbox, is there someone who can help me with this?
/Jerry