Additionally we would have to restrict access to the device type (ie not open) and not allow any SmartApps from the community to interact with Nest. As you can start to see, there are many reasons why official integration has fallen lower on the priority list.
I stated this on last night’s developer discussion too. It was in a rant near the end
This is all very interesting. I’ve been feeling that Nest is falling down on interactivity with other systems for a while now, but I hadn’t looked into details about what was going on with them. All these API restrictions are worse than I’d realized. The IFTTT integration is useless to me. All I wanted was access to changing the modes, and that’s the one thing we didn’t get. Although I am loathe to give up on the $500 worth of hardware I bought, I have been eyeing the ecobee3 lately, especially since I could get $100 rebates on each of the two I’d need.
Maybe my parents would want one of my Nests. They are still nice theromostats, unless you want to integrate them with anything else.
I still would like to see some integration. Enough to be able to to essential functions and basic automation. All that is needed for my setup is allowing “Routines” to adjust temperature or home-away mode and the possibility of using a sensor to alter the thermostats state. I understand that many people use community developed smart-apps but some functionality is better than none. IMO
Yeah, learning more about all the limitations I understand why there is a lack of support. My previous communications had led me to believe it was over something extremely trivial, but this makes sense.
I’m trying to understand why community developed smart-apps/device types isn’t enough.
Well, for one thing (though not particularly relevant for cloud-cloud connected Device Type Handlers), Community Device Types not accepted, reviewed, and published officially will not run locally on Hub V2.
As far as I understand, any device handler that talks to a web service (like Nest) will not run locally anyway.
I was answering this question below in the global sense. i.e., There will always be the possibility of various benefits available to Official Device Handlers and SmartApps that are not available to un-certified Community Developed ones. At the moment, the local processing benefit is inapplicable to Nest in either case.
I have a Nest thermostat, cam and protect. I am VERY new at setting up processes to control these devices “things”. I was using the routines built in to the app but they are very limited so I was hoping there was a better way to control more features of the thermostat than just temp. What I want is when everyone leaves the house, it does the normal stuff (lock doors, turn off light, the easy stuff) but also set the Nest thermostat to “away” mode. This will correctly set the temp to my preset “away” settings and also tell the Cam to turn on. I looked for a way to make a custom routines but nothing came up that was much help. Anything you all can do would be great!
As far as I know there is not a way to do this with routines. But there are other ways to set your nest away automatically.
ThermostatAutoAway.groovy: Smartthings smartapp that sets a thermostat to “Away” when presence(s) are no longer detected.
ThermostatAutoHome.groovy: Smartthings smartapp that sets a thermostat to “Home” when presence(s) are detected.
I’m absolutely looking for the same thing @dalemeyer , I want to be able to run “goodbye” routine for example (which for me happens based on everyone leaving the house/geolocation) and have it trigger away in the Nest (and vice versa.) Even if that’s through the routine, triggering a mode, that is seen by the smartapp. There is a way to do a geolocation trigger for it through Life360, but I’d rather not have to deal with another thing tracking my every move.
I wouldn’t think it would be too hard to amend ThermostatAutoAway into changing based on a certain mode versus a presence detector, but I don’t know how.
It probably wouldn’t, but I don’t code for others for free. There is a donate link on the github page.
Understood @sidjohn1, we all have to eat
For the record, I ended up using the custom app @imbrianji 's “change nest mode” and connected it to the mode Away so it indirectly is triggered by the routine “Goodbye” that triggers automatically by geolocation and another spawn of the app to a new mode I created called “Heading Home” with a corresponding routine that is on my widget to press to get it kicked back into home mode since my returning schedule is inconsistent.
That’s a good find I may use that as well.
I added a lock capability to the device and set commands for lock to away and open to present. It was pretty straightforward to add it to my routines for “goodbye” and “i’m back” after that.
Does anyone know how to modify the change nest mode app so that you can choose multiple ST modes? I can only select one, but I have several Home and Away modes. I would rather not have a SA for each one.
You can try rule machine expert features. If you add capability actuator to the nest device type it opens up a lot of custom commands including home and away. Then just make a rule to do what u want using the new commands.
Can someone please post the best / latest Nest setup to follow, step by step with the code?
The most recently updated with multi-tile interface is:
A long thread on nest is