OK, restarting my main OH2 instance resulted in progress as well. It created a new thing and its properties are populated and the message is:
Status: OFFLINE - CONFIGURATION_ERROR Invalid credentials
I’ve triple checked and entered and re-entered the login and password so I know I’ve got it right.
Hmm. That’s extremely odd. If you turn up debugging on the discovery service you should get a better idea of what’s going on. UPnP is kind of a pain, so a lot of discovery packets get sent and received, which is what the noise in your log file is all about. That’s a good sign, generally. If you want to really turn up the output to see the actual traffic, you can do this from the openhanded console:
log:set TRACE org.openhab.binding.venstarthermostat.internal
Here’s another idea… have you tried going to the URL in your browser? It should prompt you for the credentials you specified and then give you a version string that looks like this:
{“api_ver”:5,“type”:“residential”}
And just for reference, my thermostat URL looks something like this (in Paper UI):
Downstairs
ColorTouch Thermostat
Venstar ColorTouch Thermostat
Status: ONLINE
HIDE PROPERTIES
uuid 98:f1:70:68:b1:b5
url https://192.168.1.100/
Success!! After breaking my install (don’t mess with setcap) and getting it back, restarting a few times and using some colorful language I appear to have the binding working. Woot!
I have two questions though that I’m sure you have to have solved. Right now the humidity is .33 instead of 33%. Can’t seem to get to display correctly. Also, what is System State? I assumed it would be something like ‘heating/cooling/idle’. I tried creating a string item for it but I can’t get a value.
Thanks for all the help, I do appreciate it. I’m not 100% sure what I did to get it to work, but I’m not going to look a gift horse in the mouth!
~Mark
I’m glad you got it at least semi-working. Strangely, I am sure I wrote a reply back on Sunday with some more details but I was either imagining it or something went wrong with the post. Here’s is that message in a nutshell:
Over the weekend I blew away my openhab install and got a fresh copy of the 2.0 release and rebuilt things. I did end up making some changes to the discovery process so that it’s more reliable, and fixed a few potential problems. If you want to try to use the latest code, you can find it here:
http://bill.welliver.org/dist/openhab/org.openhab.binding.venstarthermostat-2.1.0-SNAPSHOT.jar
I do have a few things that I plan to fix, so there will be further releases in the next few weeks, but this version is functional.
Ok, now on to your questions:
System state is an indicator of what the thermostat thinks is happening: Idle, Heating, Cooling, etc.
I’m currently using PaperUI and my control widget looks like this (I haven’t linked the Cooling Setpoint or System Mode channels):
I have not, to my knowledge done anything outside of the binding to make the PaperUI widgets display what they do. I will look at some of the other UIs… which one are you using?
Bill
I just took a few moments to try some of the other UIs and it seems that PaperUI is the only interface that seems to completely render the channel values properly. I suspect that’s because the other UIs aren’t implementing all of the value mapping rules. You can see rules and how everything is supposed to be translated in the thing definition file:
I’m not sure what to do about the discrepancy, as, for example, it’s not possible to change the thermostat set point in the iOS app. There seems to be only one other OpenHAB2 binding for thermostats, the coolmasternet binding, and it basically works the same way (which is a little reassuring that I ended up with a similar approach.)
Maybe a bug or question should be filed about this against those other UIs?
Hi Bill,
Thanks for working on this binding! I installed a Venstar Colortouch T7900 today and I am trying to use this binding on openHAB2 stable. I installed the latest build you linked, and the binding is able to discover the thermostat, but it remains in state “UNINITIALIZED - HANDLER_MISSING_ERROR” indefinitely
In the log I see:
2017-03-12 19:29:11.629 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'venstarthermostat:colorTouchThermostat:00aefabd5a6a' to inbox.
2017-03-12 19:29:18.607 [INFO ] [al.VenstarThermostatDiscoveryService] - Got an answer message in venstar
2017-03-12 19:29:18.607 [INFO ] [al.VenstarThermostatDiscoveryService] - unable to parse response: Not a valid protocol version: M-SEARCH * HTTP/1.1
Then the last two lines repeat over and over again.
I can hit the API and get:
GET /
{"api_ver":5,"type":"residential"}
In the properties of the thermostat thing, UUID & url are filled in correctly.
I have tried a few restart cycles for openhab, and adding/removing the thermostat again - but I still can’t get it to initialize.
Any ideas?
Thanks!
Hi,
That log entry is actually a sign that discovery is working properly: the discovery service is “seeing its reflection” on the network. Probably, though, it would be better to not make it seem like that is a problem.
I assume you’ve turned on SSL and enabled a username and password on the thermostat and provided this information in the Thing configuration… if you haven’t, the handler probably won’t start up.
Bill
Another thing: what does bundle:list say about the venstarthermostat binding? It’s possible that there’s a dependency problem. It might also be worthwhile to look further back in your log files for problems with the handler.
Also, depending on the version of openhab you’re using, I’ve found that doing a thing removal + restart + rediscovery sometimes helps, though I haven’t run into this problem with the 2.0 release as of yet.
Bill
Hi Bill,
Thank you for your response. I had tried both adding/removing and restarting, but not restarting in between the add/remove. For some reason that could be pure coincidence, that did it and its paired now. Everything seems to be working fine now 
Hi,
So glad that worked. It doesn’t seem like that particular sequence should matter, but I’ve been in that position a few times where it was the only solution. I don’t think it’s binding particular, just a quirk/bug of the framework. I am hopeful that will slowly get better.
Please let me know if you run into any problems or have suggestions. I’ve got a few improvements in the pipeline so there should be another update at some point in the next few weeks.
Bill
Hi Bill,
For the most part everything was working great for awhile. Then at one point, I did a normal clean reboot of the openhab2 server. After the server came back up, the thermostat binding was in a corrupted state and kept spewing the following at the check interval:
2017-03-14 19:32:31.156 [ERROR] [org.eclipse.smarthome.io.rest.sse ] - FrameworkEvent ERROR - org.eclipse.smarthome.io.rest.sse
org.osgi.framework.BundleException: Exception in org.eclipse.smarthome.io.rest.sse.internal.SseActivator.start() of bundle org.eclipse.smarthome.io.rest.sse.
at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:792)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:941)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:318)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.Module.doStart(Module.java:571)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.Module.start(Module.java:439)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:454)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer.applyDelta(ModuleContainer.java:717)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:491)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:437)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer.refresh(ModuleContainer.java:955)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerWiring.dispatchEvent(ModuleContainer.java:1336)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerWiring.dispatchEvent(ModuleContainer.java:1)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
Caused by: java.lang.LinkageError: ClassCastException: attempting to castbundleresource://22.fwk1807648168/javax/ws/rs/ext/RuntimeDelegate.class to bundleresource://22.fwk1807648168/javax/ws/rs/ext/RuntimeDelegate.class
at javax.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:146)
at javax.ws.rs.ext.RuntimeDelegate.getInstance(RuntimeDelegate.java:120)
at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
at org.glassfish.jersey.media.sse.SseFeature.<clinit>(SseFeature.java:62)
at org.eclipse.smarthome.io.rest.sse.internal.SseActivator.start(SseActivator.java:44)
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_121]
at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
... 14 more
java.util.concurrent.ExecutionException: java.lang.NullPointerException
at java.util.concurrent.FutureTask.report(FutureTask.java:122)[:1.8.0_121]
at java.util.concurrent.FutureTask.get(FutureTask.java:206)[:1.8.0_121]
at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:188)[98:org.eclipse.smarthome.core:0.9.0.b4]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:81)[98:org.eclipse.smarthome.core:0.9.0.b4]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:65)[98:org.eclipse.smarthome.core:0.9.0.b4]
at org.eclipse.smarthome.core.thing.internal.ThingManager.receiveCommand(ThingManager.java:369)[105:org.eclipse.smarthome.core.thing:0.9.0.b4]
at org.eclipse.smarthome.core.items.events.AbstractItemEventSubscriber.receive(AbstractItemEventSubscriber.java:46)[98:org.eclipse.smarthome.core:0.9.0.b4]
at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:192)[98:org.eclipse.smarthome.core:0.9.0.b4]
at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:1)[98:org.eclipse.smarthome.core:0.9.0.b4]
at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:179)[98:org.eclipse.smarthome.core:0.9.0.b4]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]
Caused by: java.lang.NullPointerException
at org.openhab.binding.venstarthermostat.handler.VenstarThermostatHandler.getCoolingSetpoint(VenstarThermostatHandler.java:351)[197:org.openhab.binding.venstarthermostat:2.1.0.201703052220]
at org.openhab.binding.venstarthermostat.handler.VenstarThermostatHandler.setHeatingSetpoint(VenstarThermostatHandler.java:344)[197:org.openhab.binding.venstarthermostat:2.1.0.201703052220]
at org.openhab.binding.venstarthermostat.handler.VenstarThermostatHandler.handleCommand(VenstarThermostatHandler.java:154)[197:org.openhab.binding.venstarthermostat:2.1.0.201703052220]
at org.eclipse.smarthome.core.thing.internal.ThingManager$4.call(ThingManager.java:372)[105:org.eclipse.smarthome.core.thing:0.9.0.b4]
at org.eclipse.smarthome.core.thing.internal.ThingManager$4.call(ThingManager.java:1)[105:org.eclipse.smarthome.core.thing:0.9.0.b4]
... 5 more
2017-03-14 21:29:32.085 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occured while calling handler: java.lang.NullPointerException
java.util.concurrent.ExecutionException: java.lang.NullPointerException
at java.util.concurrent.FutureTask.report(FutureTask.java:122)[:1.8.0_121]
at java.util.concurrent.FutureTask.get(FutureTask.java:206)[:1.8.0_121]
at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:188)[98:org.eclipse.smarthome.core:0.9.0.b4]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:81)[98:org.eclipse.smarthome.core:0.9.0.b4]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:65)[98:org.eclipse.smarthome.core:0.9.0.b4]
at org.eclipse.smarthome.core.thing.internal.ThingManager.receiveCommand(ThingManager.java:369)[105:org.eclipse.smarthome.core.thing:0.9.0.b4]
at org.eclipse.smarthome.core.items.events.AbstractItemEventSubscriber.receive(AbstractItemEventSubscriber.java:46)[98:org.eclipse.smarthome.core:0.9.0.b4]
at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:192)[98:org.eclipse.smarthome.core:0.9.0.b4]
at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:1)[98:org.eclipse.smarthome.core:0.9.0.b4]
at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:179)[98:org.eclipse.smarthome.core:0.9.0.b4]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]
Caused by: java.lang.NullPointerException
at org.openhab.binding.venstarthermostat.handler.VenstarThermostatHandler.getHeatingSetpoint(VenstarThermostatHandler.java:355)[197:org.openhab.binding.venstarthermostat:2.1.0.201703052220]
at org.openhab.binding.venstarthermostat.handler.VenstarThermostatHandler.setCoolingSetpoint(VenstarThermostatHandler.java:330)[197:org.openhab.binding.venstarthermostat:2.1.0.201703052220]
at org.openhab.binding.venstarthermostat.handler.VenstarThermostatHandler.handleCommand(VenstarThermostatHandler.java:164)[197:org.openhab.binding.venstarthermostat:2.1.0.201703052220]
at org.eclipse.smarthome.core.thing.internal.ThingManager$4.call(ThingManager.java:372)[105:org.eclipse.smarthome.core.thing:0.9.0.b4]
at org.eclipse.smarthome.core.thing.internal.ThingManager$4.call(ThingManager.java:1)[105:org.eclipse.smarthome.core.thing:0.9.0.b4]
... 5 more
Every time this would happen, it would actually cause a reboot on the thermostat itself - i kept noticing it brighten up and go to the Venstar bootloader screen, and I could correlate that with these log clips happening. In order to fix, I had to do the remove, restart, add cycle again. Not sure what went on here.
Other than that, for the most part things were working great. I had two observations though:
Everything else was working fine, including the state display, temperature display, and heating/cooling setpoints. Hopefully this info is of use.
Keep up the good work on the binding, looking forward to the next build
I’ll take a look and see what might have caused that error… the binding certainly shouldn’t be able to cause the thermostat to reboot; unless there’s a bug in the thermostat that chokes on possible bad requests. The error seems to have come from not getting data from the thermostat. Whether that was the cause of the problem or the effect, I’m not so sure. I’ll put some error handling in the next release to help prevent the NullPointerException.
What version of OpenHAB and which UI are you running? I’ve noticed that PaperUI seems to be the only UI that currently supports all of the formatting/mapping details that are included in the thing configuration file. It’s possible you’re seeing the default value and %% for this reason. My sense is that the 2.0 release was made before everything was completely baked.
Bill
Bill,
I’m using the official 2.0/stable deb repo for Ubuntu 16.04. I configured via PaperUI, but primarily use the android app.
Does it work properly with PaperUI? I’ve tried the iOS app and it doesn’t seem to display the values properly. I can double check to make sure the system mode works properly in PaperUI for me, though I’m pretty sure it was working. I have noticed that the outdoor temperature displays 0 degrees; I assume that’s because I don’t have an external temperature sensor installed.
All the controls that ever worked for me worked for both the android app and paper ui.
I seem to have an issue where openhab randomly loses the connection to the thermostat and goes back into “Initializing state”. While in this state, its not apparently obvious to me when looking at the UI in the app, because it still shows the last collected values for temperature, heating, and cooling, but of course cannot respond to any changes. I’m not sure why this is yet.
I still see the normal logging in this case, but when I try to change the setpoint, i get the following:
2017-03-16 17:57:07.759 [INFO ] [al.VenstarThermostatDiscoveryService] - unable to parse response: Not a valid protocol version: M-SEARCH * HTTP/1.1
2017-03-16 17:57:11.262 [INFO ] [al.VenstarThermostatDiscoveryService] - Got an answer message in venstar
2017-03-16 17:57:11.262 [INFO ] [al.VenstarThermostatDiscoveryService] - unable to parse response: Not a valid protocol version: M-SEARCH * HTTP/1.1
2017-03-16 17:57:14.763 [INFO ] [al.VenstarThermostatDiscoveryService] - Got an answer message in venstar
2017-03-16 17:57:14.763 [INFO ] [al.VenstarThermostatDiscoveryService] - unable to parse response: Not a valid protocol version: M-SEARCH * HTTP/1.1
2017-03-16 17:57:14.962 [INFO ] [al.VenstarThermostatDiscoveryService] - Got an answer message in venstar
2017-03-16 18:02:02.248 [INFO ] [ome.core.thing.internal.ThingManager] - Not delegating command '75' for item 'ThermostatHeatTo' to handler for channel 'venstarthermostat:colorTouchThermostat:00aefabd5a6a:heatingSetpoint', because handler is not initialized (thing must be in status UNKNOWN, ONLINE or OFFLINE).
2017-03-16 18:02:02.249 [INFO ] [ome.core.thing.internal.ThingManager] - Not delegating update '75' for item 'ThermostatHeatTo' to handler for channel 'venstarthermostat:colorTouchThermostat:00aefabd5a6a:heatingSetpoint', because handler is not initialized (thing must be in status UNKNOWN, ONLINE or OFFLINE).
2017-03-16 18:02:05.221 [INFO ] [ome.core.thing.internal.ThingManager] - Not delegating command '75' for item 'ThermostatCoolTo' to handler for channel 'venstarthermostat:colorTouchThermostat:00aefabd5a6a:coolingSetpoint', because handler is not initialized (thing must be in status UNKNOWN, ONLINE or OFFLINE).
2017-03-16 18:02:05.221 [INFO ] [ome.core.thing.internal.ThingManager] - Not delegating update '75' for item 'ThermostatCoolTo' to handler for channel 'venstarthermostat:colorTouchThermostat:00aefabd5a6a:coolingSetpoint', because handler is not initialized (thing must be in status UNKNOWN, ONLINE or OFFLINE).
This time I did not do any restarts to the server, and I have verified that I can hit the thermostat’s rest api in my browser. I’m not sure why openhab lost the connection, I don’t see anything in the log to point to why.
Well, I’m not sure why that would happen. The handler goes into INITIALIZING? No other details? I’ve got some code that recovers a little better from problems; I will try to package that up this weekend. You can also turn logging up using the log:set command.
Off the top of my head:
log:set DEBUG org.openhab.binding.venstarthermostat.handler
On the off chance that anyone’s following this thread, I’ve put together a new release of the Venstar thermostat binding that I’ve been running on OpenHAB 2.1.0. It is more robust than the version I previously posted, and should be reliable enough for general use.
If anyone’s interested, a binary download and the source code (better than before, but still in need of cleanup) is available at this URL:
As always, questions, comments or suggestions are welcome!
Bill
Hi again Bill,
Thanks for sharing a new version! I gave this new version a shot - I never had solved the random reboot issue I was hitting before that I posted about earlier in the thread. Unfortunately, I still get it with this version and openhab 2.1.0.
I’ve done significant testing since my last post, and I am pretty sure it has to be caused by something in your custom discovery code, however, I don’t know what. There is no real insight in the logs. The reason I suspect discovery is because the thermostat will reboot merely if it is on the same wireless network as the openHAB instance with this binding installed. As soon as I uninstall the binding, the random reboots stop. I had went a few months now without any random reboots (after uninstalling the binding). They started again within 5 minutes of me installing the new version 
The binding does connect and work if I configure it, the device just reboots every few minutes.
Is it possible to just have fully manual configuration as an option? If discovery is an issue with this device where it is very quirky in how it handles those requests (as you mentioned near the beginning of this thread), then it might be better to have an option to just disable discovery entirely in favor of manual config. If that allowed me to use the binding without my device rebooting, that would be amazing.
That’s a truly strange problem… in the course of getting everything working, I’ve done a fair amount of network traffic sniffing, and there’s very little going on aside from sending the packet that Venstar specifies. In fact, the reason I had to write a custom discovery service is because the thermostat is so picky about the format of the message, I wasn’t able to make things work any other way!
I need to dig into the openhab internals to see exactly what’s possible as far as manual configuration and disabling the discovery service. In theory, OpenHAB should provide a means to disable the discovery service, as it controls when it starts and stops, but I’m not sure.
If you’re using a static IP address for the thermostat, it should be feasible to have a manual configuration; if there’s a possibility of the thermostat getting a new address, then discovery is really the only way to keep it up to date… I will look into all of this, though it might take a little time to figure out the options. I’ll post back to this thread when I make some progress.
In the meantime, any chance you can let me know the model and version number of the software you’re running? I will compare it to mine (I hear that there’s a new version of the firmware out but haven’t looked into it.)