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.
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:
Temperature
Humidity
Rainrate
Raintotal
Winddirection
Windaverage
Windgust
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).
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
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:
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.
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?
Yep, my things are still working. The rainsensor is not working very well though… It has got channels for rainrate and total rain so I tried connecting an item. Now the thing has status OFFLINE - HANDLER_INITIALIZING_ERROR, don’t really know what happened. The item shows value -NaN. I got a stacktrace in the log, http://pastebin.com/RTTJQsPH
