I was very excited to find that there is an updated binding for the nest thermostat that follows the 2.0 model. The binding is found in the current openHAB 2.2.0~20171008013406-1 (Build #1058) unstable snapshot.
I have four Nest Thermostats, 6 protects, and 2 Nest Cams. I have struggled with the 1.0 binding for months, and had finally given up on these devices. I had invested many long hours puzzling over conflicting posts and instructions, rebuilt my openhab system multiple times, and recreated my nest product dozens of times with no success.
I started with openhab after the release of 2.0, so had no experience with the 1.0 bindings. I spent hours looking at logs but mostly never saw connects happen.
I had followed the discussion on GITHUB and it appeared midsummer that this project was dead after the developer received some serious flame. Thanks to PINKFISH for completing their efforts to create a functioning binding.
The move to the unstable snapshot was rocky, as always, breaking the web server, samba, and zwave functionality. Several hours of troubleshooting fixed these. I was gun shy and almost stopped there, but decided to give the Nest configuration a try. I created a “THING” for the Nest account, populated it with my Product ID, Secret, and one time pin from the nest authentication link and almost fell out of my chair, as all my nest devices appeared in the inbox.
The devices associate to channels as expected, and the countless hours of frustration are behind me.
Thanks to the developer and team that helped to remove this massive thorn from my Openhab2.
I am saddened to read the thread on that github issue. @watou was very prolific and helpful on these forums and with contributions to the code, I greatly respect his expertise and contributions to the community, and I think of him as a mentor who helped me tremendously when I got started with OH.
I do know there is some additional history behind that thread I won’t go into here. Searching for postings with him around the 2.0 beta time frames will show for those who are curious.
I hope this experience has not completely soured his continued participation in the community though it does explain why it has been a long time since I’ve seen him post.
I offer my congratulations to pinkfish but wish there could have been a way to manage this without stomping on people’s toes.
thanks, i’ve just installed this binding for a thermostat and I’m getting values filled into the channels - but they don’t appear to be the right values.
For example, i have the “heat set to” on my thermostat as 18.5, but there’s no matching data (or anything close) in any of the channel values.
What build are you using? Recently PR #2737 got merged which should add a set_point channel for this to thermostats in the binding.
I think it will be part of build #1059 or newer. That PR also replaces the polling with streaming data so you are instantly notified of temperature/humidity changes or fire/smoke alarms!
I’m not sure which version I have, but found a link to a snapshot jar from github earlier (so presumably the latest build?) and installed that and am now getting the set_point value.
However, while I could postupdate to change the value in OH, the value at nest and on the thermostat didn’t change.
Do your Nest things have an “ONLINE” status in Paper UI? (See: Configuration -> Things). When they are not online you will not see the correct status and postUpdate will also not work. The reason why they are offline should also be displayed.
Do you see any warnings/errors in the console/logging?
Yes you should use sendCommand for the binding to send a command to Nest. postUpdate will only update the value of an openHAB item.
It’s also possible to send commands via Paper UI by changing the values of your themostat using the “Control” page. This will also result in a sendCommand.
Now i’m doing it right and sending a command and not an update, it’s working.
Apologies for being a numptie and thanks for your help in getting me sorted.
I have just noticed that errors appear in the log when changing the set_point. As it’s still in development I guess those are already known about, but if someone would like to see those errors just say.
2017-10-13 16:47:59.962 [WARN ] [eclipse.jetty.servlet.ServletHandler] - /proxy
java.lang.NullPointerException: null
at java.net.URI$Parser.parse(URI.java:3042) [?:?]
at java.net.URI.<init>(URI.java:588) [?:?]
at java.net.URI.create(URI.java:850) [?:?]
at org.eclipse.smarthome.ui.internal.proxy.ProxyServletService.uriFromRequest(ProxyServletService.java:267) [138:org.eclipse.smarthome.ui:0.9.0.201709121704]
at org.eclipse.smarthome.ui.internal.proxy.AsyncProxyServlet.rewriteTarget(AsyncProxyServlet.java:61) [138:org.eclipse.smarthome.ui:0.9.0.201709121704]
at org.eclipse.jetty.proxy.ProxyServlet.service(ProxyServlet.java:63) [81:org.eclipse.jetty.proxy:9.3.14.v20161028]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [31:javax.servlet-api:3.1.0]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845) [86:org.eclipse.jetty.servlet:9.3.14.v20161028]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584) [86:org.eclipse.jetty.servlet:9.3.14.v20161028]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [172:org.ops4j.pax.web.pax-web-jetty:6.0.6]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [85:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) [83:org.eclipse.jetty.security:9.3.14.v20161028]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) [85:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180) [85:org.eclipse.jetty.server:9.3.14.v20161028]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:284) [172:org.ops4j.pax.web.pax-web-jetty:6.0.6]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512) [86:org.eclipse.jetty.servlet:9.3.14.v20161028]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) [85:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112) [85:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [85:org.eclipse.jetty.server:9.3.14.v20161028]
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [172:org.ops4j.pax.web.pax-web-jetty:6.0.6]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) [85:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.Server.handle(Server.java:534) [85:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320) [85:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) [85:org.eclipse.jetty.server:9.3.14.v20161028]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273) [77:org.eclipse.jetty.io:9.3.14.v20161028]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95) [77:org.eclipse.jetty.io:9.3.14.v20161028]
at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) [77:org.eclipse.jetty.io:9.3.14.v20161028]
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) [88:org.eclipse.jetty.util:9.3.14.v20161028]
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) [88:org.eclipse.jetty.util:9.3.14.v20161028]
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) [88:org.eclipse.jetty.util:9.3.14.v20161028]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) [88:org.eclipse.jetty.util:9.3.14.v20161028]
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) [88:org.eclipse.jetty.util:9.3.14.v20161028]
at java.lang.Thread.run(Thread.java:745) [?:?]
@DSTM The error seems to be generated by a call made from one of the openHAB UIs (or maybe even an iOS/Android App). The call is processed by the Jetty server running inside openHAB and it then tries to proxy it to a destination that is null (hence the NullPointerException). So it looks unrelated to the Nest binding.
You could further debug the source of it by opening your browser debug view (F12). There is a “Network” tab where you can monitor all HTTP requests that are made. When a call fails it is highlighted in a red font. Typically it will have a 4xx or 5xx status code.
When you then click on the failed request it will show its details. E.g. the request URL/method and headers. Those details may help with finding the source of the error.
Hi @DSTM i’m newbie on OA2 and i’m try to use the nest2 binding but i don’t understand how to install it. Until yesterday i was using the 1.0 nest binding with succes but i tried to use the one and i don’t understand how can i install the binding, for previous one i did it from paper UI but there i can only find the 1.0’s, is there a tutorial to install the new one?
i’m sure my Nest API ara running because with curl i can read messages from my thermostat.
