Tellstick binding for OpenHab2

Setup, Configuration and Use Runtime
174

Daniel,
Thank you for your feedback, I will try, and see if I can manage that installation, the Linux part is for a windows user not that easy to understand.

Thanks again.

I wish you a happy new year

/Jocke

175

Hi, this link does not seem to work anymore.

I have done a new installation of OpenHab 2, but cannot get the “built-in” bundle to work.
I had this up and running earlier, but perhaps I installed the add on manually.

176

The version in latest Openhab2 should work fine, or use this

177

Need some help from you guys. I am trying to migrate my openhab instance to an Pine64 board and have struggled with getting Tellstick-core interface working. I wonder if you could give me some advice.

I am currently running Ubuntu 16.04 and while the board is 64-bit I have compiled the telldusd service myself which works great. The error I get is this from /var/log/openhab2/openhab.log:

Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.tellstick.JNA$CLibrary
	at org.tellstick.device.TellstickDevice.getDevices(TellstickDevice.java:245) ~[?:?]
	at org.openhab.binding.tellstick.internal.core.TelldusCoreBridgeHandler.rescanTelldusDevices(TelldusCoreBridgeHandler.java:135) ~[?:?]
	at org.openhab.binding.tellstick.internal.discovery.TellstickDiscoveryService.startScan(TellstickDiscoveryService.java:97) ~[?:?]
	at org.eclipse.smarthome.config.discovery.AbstractDiscoveryService.startScan(AbstractDiscoveryService.java:222) ~[?:?]
	at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:409) ~[?:?]
	at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScans(DiscoveryServiceRegistryImpl.java:385) ~[?:?]
	at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:241) ~[?:?]
	at org.eclipse.smarthome.io.rest.core.internal.discovery.DiscoveryResource.scan(DiscoveryResource.java:97) ~[?:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]...

I have installed Jnalib eg. apt-get install libjna-java this is needed right?
(@jarlebh could you give some direction here?)

My Java version is currently :

[19:51:59] pine64@pine64:~$ java -d64 -version
openjdk version "1.8.0_152"
OpenJDK Runtime Environment (Zulu Embedded 8.25.0.79-linux-aarch64) (build 1.8.0_152-b79)
OpenJDK 64-Bit Server VM (Zulu Embedded 8.25.0.79-linux-aarch64) (build 25.152-b79, mixed mode, Evaluation)

[19:52:02] pine64@pine64:~$ java -d32 -version
Error: This Java instance does not support a 32-bit JVM.
Please install the desired version.

As I understod it the 64/32bit versions of telldus service and java must match to have JNA work.
Is something else needed?

178

I would guess that the java process can’t find the telldus core so file. Is this file in the default location ? There is an config option to point to another folder, but I have never tested it myself.

Jarle

E4CD7F25AA104605BC0394ED7670D660.png708×1 83 Bytes

1 Like
179

Thanks for the input got me in the right direction.

Found a solution today. Reinstalled the whole machine with 32-bit library for both java and telldusd. If someone else need a guide for installing tellstick-core on PINE64 do this:

  1. Install Java Zulu the way its done in openhabian (link here). The important stuff is sudo dpkg --add-architecture armhf and having the correct package in your source.list. The script solves all this so just use openhabian for that.

  2. This script worked for me while installing tellstick-core:

sudo dpkg --add-architecture armhf
wget -O - http://download.telldus.se/debian/telldus-public.key | apt-key add -
echo "deb http://download.telldus.com/debian/ stable main" > /etc/apt/sources.list.d/telldus-stable.list
apt update
apt -y install libc6:armhf libncurses5:armhf libstdc++6:armhf   libc-bin:armhf
apt -y install libjna-java telldus-core

(3. Optional) Create a new startup script for systemd. First off locate where telldusd is, either /usr/bin or /usr/sbin. Then create a new service definition: /lib/systemd/system/telldusd.service.

[Unit]
Description=Tellstick service daemon
After=multi-user.target

[Service]
Type=forking
ExecStart=/usr/sbin/telldusd

[Install]
WantedBy=multi-user.target

After creating the script run sudo systemctl daemon-reload as well as sudo systemctl start telldusd.service.

180

@jarlebh Have you looked at adding Tellstick Local API support? It seems pretty straight forward. Here’s a node version that I’m currently using (using both live & local api): https://github.com/mifi/telldus-api

1 Like
181

I don’t have any device with the local api, so I really don’t have any incentive to do that. :wink:

182

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 :slight_smile:

183

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…

184

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.

185

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.

186

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.

187

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?

188

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 :wink:

189

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.

190

I wrote up a post about it here, hope you’ll find it useful :slight_smile:

191

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.

192

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.

193

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.