I used to be able to set a NEST structure away in OH2.2
However this seems to have changed in OH2.3.0
items file contains:
String GF_Nest_Away "Away status: [%s]" {channel="nest:structure:13XXXXX:XXXXX0PQkxZTLlCw:away"}
One of my rules files contains a line which does not work anymore.
GF_Nest_Away.sendCommand("AWAY")
What changed in 2.3 ?
The away state has been removed from the nest api a while ago, can’t remember when.
You need to set the hvac_mode channel to eco
I’m still using home/away with 2.3.0 so it should work.
Does it show any warnings in the logging when you send the command? Did you check if it has sufficient permissions in your Nest Developer account?
If you look at the structure in the API explorer it’s still there. 
Only the auto away state was removed, see:
Where?
My bad, I was looking in the thermostat because that’s all I have… 
I remembered something to do with away being removed from the API…
Thanks
The API has the values in lowercase.
Did you try?
GF_Nest_Away.sendCommand("away")
You should have a structure (i.e. house) too because that’s what the thermostat is part of.
It should be in uppercase. I specifically added those values to the docs to resolve such confusion:
@wborn I’ll shut up now.
@rzwarts
What does the log show? Is there an error? Or does in not work with no errors?
When I change the away API to set to “AWAY” using PaperUI it works… However using rules (like no motion in house/no phones etc) using SendCommand it does not work… no errors.
The way I remember Nest’s logic in defining this is:
Item declaration
String nestStructure_Away
"Structure Home/Away [%s]"
<present> (Nest)
{nest="=[structures(Home).away]"}
Rules syntax
sendCommand(nestStructure_Away, "AWAY")
sendCommand(nestStructure_Away, "HOME")
Clear and concise, I like that
That is using the “old” nest binding. The new one uses channels
It is prefered to use the method instead of the action, as such:
nestStructure_Away.sendCommand("AWAY")
nestStructure_Away.sendCommand("HOME")
Thx. Nest integration was my very first OH project… all of six months ago under OH2.1. I’ll add updating my Item declarations for the updated binding to my ToDo list. Curious - what are the advantages of using channels (vs. whatever the previous binding used)?
I’ve wondered about this. I have used each inconsistently as I’ve added more and more automation Rules. Is there ever a reason for using the action? Or, perhaps, why is the method preferred?
Thanks.
Mike
On my phone right now but there is an explanation in the docs in manipulating item states section
Thanks for pointing me in the right direction - Rules | openHAB
Regarding the Nest binding Item syntax… actually my Item definition is probably “all wrong” for more that the reason of being out of date. I had actually allowed the binding to auto-discover my Nest Things. I then have linked my Items to the Things via PaperUI. Thus, I don’t need any {bindingConfig} definition; right? The PaperUI link does that for me; yes? Thus my Away Item declaration (as well as all my other PaperUI linked Items) is simplified to be
String SPT_house_VT_nestStructure_Away
"Structure Home/Away [%s]"
<present> (Nest)
If what I posited is right, this makes my task of updating much simpler.
Regards.
Mike
That’s correct, if you link the channels to the items in the paperUI.
I prefer letting the paperUI do the discovery and then link in the items file with the channel=xx x xx syntax as a binding.
This way I know where the data comes from for the items just by reading the file.
Maybe you can add some logging to your rules just before sending the command to see if the rule is executed, e.g.:
logInfo("nest.rules", "Sending Nest AWAY command")
You could also increase the logging of the Nest Binding using the Karaf Console:
openhab> log:set debug org.openhab.binding.nest
When it works it should show something like:
19:05:06.041 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Nest_Home_Away' received command AWAY
19:05:06.041 [DEBUG] [inding.nest.handler.NestBridgeHandler] - Putting data to: https://firebase-apiserver28-tah01-iad01.dapi.production.nest.com:9553/structures/xxxxxxxxxxxxxx-very-secret-structure-id-xxxxxxxxxxxxxx
19:05:06.042 [DEBUG] [inding.nest.handler.NestBridgeHandler] - PUT content: {"away":"away"}
19:05:06.042 [DEBUG] [inding.nest.handler.NestBridgeHandler] - Re-using access token from configuration: very-secret-token
19:05:06.042 [INFO ] [smarthome.event.ItemStateChangedEvent] - Nest_Home_Away changed from HOME to AWAY
19:05:06.795 [DEBUG] [inding.nest.handler.NestBridgeHandler] - PUT response: {"away":"away"}
The new binding was released with 2.2 so it was only logical to use the old binding back then. The OH2 Nest Binding has Things and discovery. So you can manage/control Nest Things in Paper UI.
The new binding also uses Streaming REST so you’ll have updates instantly instead of them being polled every minute or so. That helps a lot when you want openHAB to react to fire/smoke alerts of a Nest Protect.
Because it uses channels the channel definition is standardized (bindingId:thingTypeId:bridgeId:thingId) like all other OH2 bindings.
Automatic discovery of Things. Ability to manage and modify the binding, Things, and Items in PaperUI/Karaf/REST API. If there are any changes made to the Nest API or improvements to be made, those changes are more likely to be made on the 2.x version binding. The 2.x version binding also supports units.
In answer to your first question, the Action should only be used when you don’t hard code the Item name but instead construct the name of the Item you want to sendCommand or postUpdate. This is particularly useful when doing things like Design Pattern: Associated Items.
It is important to realize that the Nest 1.x binding (the one that uses the { nest=“…” }) is a completely separate binding from the Nest 2.x binding which uses Things and autodiscovery and such. They are installed separately, have completely different syntax and patterns of use.
Does it still put that randomly named file in ~openhab/.java with the secret and uid? Most people don’t have to worry about that but it is important for those of us running in Docker.
They are just configuration parameters now. So you can configure them via Paper UI or add them to your .things file (see demo.things documentation example).
Some of the available channels as described in the API and listed in the binding documentation are not “surfaced” for auto-discovered Things. Is the only means to have those channels is to define the Things manually and declare the associated Item(s) accordingly (as per the binding example)?
If I have an Account, Structure, and Thermostat Thing already which were added via auto-discovery, can I use those to declare Items for which channels are not available in PaperUI? What is the syntax (since I would not have declared the Bridge myself and thus did not set the names for the Structure , Thermostat, etc. Right now those names contain spaces because they were capture from my Nest account directly. Is there a means to “rename” the Nest Things so they conform to the requirements of the channel specification for the Item? I would prefer not to propagate the account, StructureID, and DeviceID throughout each Item declaration. I’d like to “name” those “fields” of the Things and then use those named fields in the declaration of the Items.
Otherwise, I have questions regarding a Bridge Thing. I couldn’t find the syntax for a Bridge. Did I miss it somewhere in the openHAB docs?
What part of
Bridge nest:account:demo_account [ ...
is user specified versus binding specific syntax? Obviously demo_account is user specified. Is nest:account binding specific or user specified?
Are there any problems with having and Auto-discovered Thing as well as a user declared Thing (i.e., via my own .things file)? Or, can I just skip the Thing declaration and hard code the Account, StructureID, and DeviceID in the Item declaration (most definitely not my preferred approach!)?
Sorry for the lengthy series of questions. Thanks in advance.
Mike