Have you made any progress in creating a binding that can support both firmware versions? I’m happy to test.
Hi, I’ve done a little research and think I have a plan for how to work with both versions of the firmware. Last weekend was a bit busier than expected, so I didn’t write much code. I’m hopeful that I can get something to test before the end of this weekend. I think it will probably take one or two rounds of testing, so you’ll definitely get a chance to participate 
Will be in touch soon!
Just a bump to see if you’ve made any progress updating the binding.
Hi, I haven’t forgotten about you! I’ve been trying to merge some fixes needed before the binding can get submitted for inclusion in the openhab core, and that’s complicated getting a fix out for you. I’ve got a version that I think will fix discovery for you (it might require a few go-rounds to get squared away).
An important question: what version of OpenHAB are you running? The integration work I’m doing is against 2.5M1, so if you’re running that or newer (like a nightly snapshot), I can provide a binding jar for you to test.
Bill
I recently upgraded to 2.5M1, so that is what I’m currently running.
Ok, give this one a try:
I’ve attempted to rework the regular expression used to see if it the discovered device is compatible. We might have to tweak a bit, as I no longer have a thermostat running the older version of the firmware. Please do let me know how you fare!
Bill
Thanks Bill, that discovered 2 more of my thermostats. I realized the final one is one a different subnet and discovery isn’t going to work. Is there a way to add it manually by specifying the IP?
Well, progress is at least something, right?
It is possible to create a thermostat thing manually, but it’s not super simple. You’ll need to know the unique UUID of the thermostat as well as it’s IP address. You create the thermostat manually by using paper ui: Configuration->Things->+ (Add a thing)->Venstar Thermostats->Add Manually (At the bottom of the screen)->ColorTouch Thermostat.
Give the new thermostat a name, and enter the username and password and Click the checkmark (save) button. This will create the thing but it won’t work because the UUID and IP address aren’t specified. The IP is simple enough but I’m not aware of a way to get the UUID outside of the discovery process. If there’s no change the thermostat will ever be accidentally be discoverable, you can probably make one up.
I think to provide this information, you have to stop openhab and edit the openhab/userdata/jsondb/org.eclipse.smarthome.core.thing.Thing.json file.
In that file, look for the section about the thermostat you just created… easiest to locate it by name or by the hex id it chose for the thing. You’ll then scroll down the the “properties” section and there should be empty placeholders for uuid and url. Fill in the uuid and the url, which is https://thermostat_ip. Save the file and restart openhab. That should get things to work.
The downside is that if your thermostat uses DHCP and its address changes, things will become disconnected and you’ll have to this that by using the process in the previous paragraph.
If you can, it might be better in the long run to get cross segment discovery working:
So, I’m assuming that your thermostats are on a network that is reachable from your OpenHAB system, but one where OpenHAB doesn’t have an interface directly attached. The Venstar thermostats use SSDP, which uses site-local multicast in order to find all of the discoverable devices located at the current site, even if they’re not on the same subnet. This requires getting multicast routing set up. I’m assuming since you’ve got multiple segments, you’re probably using either an layer 3 switch or a router. Usually these are capable of enabling multicast routing. Often there’s a feature called IGMP snooping that’s involved with this, or a process of specifying which lan segments are part of the “site”.
A google search for cross segment SSDP or DLNA should provide some tips. I might be able to provide some pointers for getting this set up if you let us know what kind of routing/switching hardware you’re running.
Best,
Bill
Just a quick note on this thread to mention that this binding has been submitted for possible distribution with OpenHAB 2: