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:
I just got a couple of these, and my OH things are stuck in the “initializing” stage. I tried them both with https enabled, and then tried to disable https on one unit to see if there was an issue there, but it still won’t connect even with http. Any ideas?
Hi!
It’s been a while since I set mine up, but I seem to recall it requiring a username/password along with https.
Might also be worth checking the log file to see if it’s printing anything helpful there. It might be necessary to enable some additional logging to see what’s going on, but let’s try those 2 points first.
It seems to be an SSL certificate issue.
I can directly connect to the API using a python script when it’s in http mode. But when I set it to https (which I now realize is the only option for this binding), it gives me a certificate error.
My OH logs also show what appear to be ssl errors:
15:42:56.241 [WARN ] [tty.util.ssl.SslContextFactory.config] - Trusting all certificates configured for Client@30ff527[provider=null,keyStore=null,trustStore=null]
15:42:56.242 [WARN ] [tty.util.ssl.SslContextFactory.config] - No Client EndPointIdentificationAlgorithm configured for Client@30ff527[provider=null,keyStore=null,trustStore=null]
15:43:03.004 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: Cannot invoke "org.openhab.binding.venstarthermostat.internal.dto.VenstarAwayMode.modeName()" because the return value of "org.openhab.binding.venstarthermostat.internal.dto.VenstarInfoData.getAwayMode()" is null
at org.openhab.binding.venstarthermostat.internal.handler.VenstarThermostatHandler.updateData(VenstarThermostatHandler.java:541) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[?:?]
at java.util.concurrent.FutureTask.runAndReset(Unknown Source) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[?:?]
at java.lang.Thread.run(Unknown Source) [?:?]
Update, it may be that I have old firmware. I asked it to check and it said I was on the latest, but I’m currently trying to manually load the latest via SD card. Is there a firmware range I should use for best results with the binding? I have a T8850, and the desktop app is reporting VW6.93 is the latest firmware. I’m still trying to find the current version in the thermostat’s menus.
Those first lines don’t look like SSL errors, just warnings that the shared http client is trusting the self signed cert (and outside the actual binding code), i would need to check, but i think thats standard
Thats the error, it’s a NPE on something we are expecting to always be there but is not (getAwayMode), its probably different firmware that we have not seen yet. I can take a look at it on Friday when i’m back, in the mean time if you put the binding in TRACE log mode, we print out the JSON response from the thermostat that the code is choking on, if you can post that or PM me it, that would be super helpful.
I’ll fiddle with changing the log levels when I can, but for now, this is what is reported when I I get a python result:
{'name': 'Office', 'mode': 3, 'state': 2, 'fan': 1, 'fanstate': 1, 'tempunits': 0, 'schedule': 0, 'schedulepart': 255, 'holiday': 0, 'override': 0, 'overridetime': 0, 'forceunocc': 0, 'spacetemp': 80.0, 'heattemp': 73.0, 'cooltemp': 78.0, 'cooltempmin': 35.0, 'cooltempmax': 99.0, 'heattempmin': 35.0, 'heattempmax': 99.0, 'setpointdelta': 5.0, 'availablemodes': 0}```
Found it. I’m on VW 4.08-1A firmware currently. Any guidance on whether to upgrade or not would be lovely.
Hi-
Not sure if this will help, but I’m running T7900s on VH5.10. FWIW, I haven’t updated the firmware since I installed them quite a few years ago; the indication is that there are new features that my thermostat doesn’t have, so may be worth the effort to update. I do have them on a non-internet-attached network so there may be advantages in updating if you’ve got them on one that is.
Bill
If you don’t mind waiting a day or two, i can fix this in the binding so it works with your version, its a small change which needs to be fixed, i’m on a flight with awful wifi, otherwise i would just fix it real quick. I just checked and my units are running 6.93, but we should try to be compatible with as broad of firmware versions as we can sanely maintain.
I’ve updated to 6.93, and that has fixed my problem. I have 4 other units and will leave at least one of them on 4.08 so I can beta test if you need it.
Excellent.
Thanks for the offer! I can safely make the changes now that i have your sample JSON without a test device so go ahead and update your last unit. i’m going to assume everything needs a null check when we deserialize JSON responses. I’ll probably write a few unit tests around it just to be sure.