Hi all.
I don’t really understand from the documentation, is this binding using the official telldusd service or does it speak directly to the USB device?
I have another home automation solution in place (which is simply using the tdtool command which communicates through telldusd), I would be very happy if this binding could live together with that for a while 
You need to install libraries from Telldus.
and register all devices you want to control in Telldus center.
The binding will the find them.
I’m on a headless Linux server, so actually there is no Telldus center. I’m used to configure my devices in /etc/tellstick.conf. But if I understand your answer correctly this means that’s where I’ll continue to configure them and that this binding simply uses the telldusd service to query and control them.
Does the binding poll for value changes (ie when the temperature changes or a switch gets flipped) or are they pushed in from the daemon?
Yes, it uses telldusd.
I haven’t actually started using my temp sensors in OH, so I’m not sure about polling.
I run a Raspberry Pi 2 and have to use a tightVNC server to provide a graphical env that I can use from my PC.
I’m using an Tellstick DUO.
I have NexaHome running to control my switches, and also openHAB using the very same TellstickDUO to check my sensors, and it works just greate. So as I assume should it be possible for you to have your ‘another home automation solution’ running and also install and run openHAB at the same time and server and TellstickDUO.
I do think it’s the binding that poll, but I am very shure that the polling actually happens.
See the file /etc/openhab2/ *.rules regarding polling.
This link might be helpful, http://docs.openhab.org/addons/bindings/tellstick/readme.html
I’ve installed the binding and tried around with it. I must say that the most of it works really good! I got automatic Thing creation in habpanel so now I’ve got a whole lot of new Things. Also there doesn’t seem to be any polling delay, both device status changes and sensor reading changes reaches openhab instantaneously. Impressive!
I’ve got some comments though. I hope this is a good place for them:
As I mentioned the Things I need was automatically created with nice names (the ones I’ve configured in tellstick.conf). However all the corresponding Items that were created are named “Switch”, so now I’ve got very many Items with that same name. It seems the only way to fix it is to go into the Things channel and delete the Item from there and then create a new with a better name, which is quite a hassle. Any way the Items default name could be something more unique?
All my sensors are identified as temperature/humidity sensors. This works quite good for some of them (for example I’ve got a bunch of temperature only sensors, doesn’t matter that the humidity is null there), but I’ve got a rain sensor that normally reports “rainrate” and “raintotal” and it (kinda naturally) reports null for both temperature and humidity. Any way to get those rain values in? Also I guess either the bindings should try to identify the type of sensor, or it has to create channels for all possible types of values (rainrate, raintotal, winddirection, windaverage and windgust).
As for #1:
I would like to have an obvious location where I move from physical names to logical.
I write physical names on the plugin switches ( for example A2-4 ) with a marker, and in telldus center I register all physical devices.
Later I choose to use switch D2-4 in the KitchenWindow, and somewhere I would like to go from referencing D2-4 to use KitchenWindow instead.
If I need to replace a switch, it should only have minimal impact in the configuration.
I absolutely don’t want to see D2-4 in my rules for instance.
as for #2:
Anything beyond switches and dimmers is unknown territory for me. But I can see lots of uses for doorbell buttons, use of remote controls etc.
As for #1:
Take a look in file ex. demo.items in /etc/openhab2/items.
There can you rename your items as you like, just be aware to do the very same renames even in ex.demo.rules,demo.sitemap
As for #2:
I do think that as in this case, must new sensor-types be added to the binding, otherwise will not the binding be able to recognize them.
Yep, that’s what I meant. I guess I should ping @jarlebh for this one.
The sensor types supported by Tellstick (and that is thus needed in the binding) are the following:
Setting up channels for all those types for all sensors make no sense, so the binding will have to check which ones each sensor supports. I don’t know exactly how the communication with telldusd works, but the information is in there somewhere, when I run a “tdtool --list-sensors” I can see what types of readings every sensor supports (and of course also the values of those readings).
I like to work with config-files, but the GUI works fine aswell, and the link below is about this.
So I hope that it somehow will be possible to make/update these files even if they are constructed in GUI and saved in dB, as described in link
About the rain-sensors, interesting, which type do you use?
I like to make a try, when and if they are possible to use.
I have got an Oregon Scientific PCR800.
Sadly enough though I’ve done some reading into the Telldus developer documentation and I found the following text:
Currently only temperature and humidity are implemented.
Kinda explains why this binding only supports those types. Can’t really understand how Telldus are reasoning here, feels kinda stupid to support more types and only expose two of them in the api 
Have read the last comments and for you new users are anything unclear in the readme file over here?
I will do a cosmic update to get the markdown formatting right so can also clarify some parts if there is a need for it.
Anyone have something to add?
Read it, looks good!
But just one thing, I actually don’t know if this is an answer to your questions, but I have got some thoughts about it. It was not possible to run 64-bits OS, 32-bits JVM and 2.1.0.201701231847 Tellstick Binding.
But my serial-device(enocean) works with 64-bits OS, 64-bits JVM so that’s how it will be.
In your README.md:
+For USB connected tellsticks only, eg. Basic and DUO
+First of all you need to make sure that your JVM is matching your installed Telldus Center. This normally means openHab must run on a 32bit JVM for windows and a 64bit JVM for linux. For windows the binding is hardcoded to look for Telldus Center in Programs Files (“C:/Program Files/Telldus/;C:/Program Files (x86)/Telldus/”). If you have trouble getting the telldus core library to work you can modify the library path using
In http://docs.openhab.org/installation/index.html /Installation/Overview/Prerequisites:
Also make sure to use the 32-bit version of the JVM, even on 64-bit operating systems. Serial connections won’t work with a 64-bit JVM, so bindings like Z-Wave won’t be working with it.
I am now running 64-bit OS, 64bit JVM, openhab2 Last Stable(2.1.0 snapshot Build 752), 2.1.0.201701231847 Tellstick Binding, since yesterday and so far is everything working as expected.
Good! Something is wrong with the “Binding Configuration” heading though.
If I were you I’d add an explanation why only temperature and humidity is supported for sensors. So no more users need to think you’re the one that missed them
edit: By the way, I have a new plan for how to get my rain sensor values into openhab. I’ll simply put a script in /usr/local/share/telldus/scripts/sensorevent/ (the place where telldus-core looks for scripts to execute when sensor values are changed) which calls openhab rest api to change the value of an item. I’ll get back to this when I’ve got it working, might be useful for other people as well.
It should be easy to implement the rain sensor, but I would need some raw event data from telldus. Maybe you would see this is you turn debug on for the telldus binding.
Well, I’ve got a script in /usr/local/share/telldus/scripts/rawdeviceevent that continuously puts the RAWDATA in a log file. Would that be what you need? Example of a line:
class:sensor;protocol:oregon;model:2914;id:11;raintotal:190.1;rainrate:0.0;
edit: I also tried the debug log level of the binding and got the following:
10:24:32.411 [DEBUG] [andler.core.TelldusCoreBridgeHandler] - Sensor Event for TellstickSensor [sensorId=11, protocol=oregon, model=2914, timeStamp=Sat Jan 28 10:23:45 CET 2017, data={RAINRATE=0.0, RAINTOTAL=190.1}] event TellstickSensorEvent [sensorId=11, model=2914, protocol=oregon, data=0.0, timestamp=1485595472000]
10:24:32.431 [DEBUG] [andler.core.TelldusCoreBridgeHandler] - Update curr 0.0 new 0.0
10:24:32.435 [DEBUG] [andler.core.TelldusCoreBridgeHandler] - Sensor Event for TellstickSensor [sensorId=11, protocol=oregon, model=2914, timeStamp=Sat Jan 28 10:23:45 CET 2017, data={RAINRATE=0.0, RAINTOTAL=190.1}] event TellstickSensorEvent [sensorId=11, model=2914, protocol=oregon, data=190.1, timestamp=1485595472000]
10:24:32.437 [DEBUG] [andler.core.TelldusCoreBridgeHandler] - Update curr 190.1 new 190.1
I’m having trouble with the binding locking up and losing the connection to telldusd if I send several ON/OFF commands at once from a rule, anyone else experiencing this? Stopping and starting the bundle fixes it, and tdtool works so I think it’s an internal issue in the binding.
I’ve worked around it with Thread::Sleep(2000) commands in my rules to give it some time to process each item.
Sound like a reasonable workaround.
It would be possible to create things dynamically from the sensor events using the API and then update the things. Eg. the user does not need to manually add things to match data output from telldus core.
An even better approach would be to have an inbox endpoint which allows creations of things so the user can choose which sensors to actually use.
I have made an attempt on adding Wind and Rain sensors, they are now a new type of sensors. Since I have neither a rain or wind sensor you will need to test this for me.
This is tested using Openhab 2.0 stable (ignore the 2.1 in the filename)
https://dl.dropboxusercontent.com/u/26815772/org.openhab.binding.tellstick-2.1.0-SNAPSHOT.jar
Newbie question (I’ve never installed any binding manually, just through paper ui and habmin): I guess I’ll just download the jar and put it in /usr/share/openhab2/addons (and maybe do a bundle:start on it), but do I have to uninstall or stop the existing 2.0.0 binding first? And what happens with my existing things when I do that?