@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:
- It is the Structure from which you go away from or return (Away/Home). If you are Away, then you want the THermostat to be in Eco Mode. This is why when you change Home/Away via Nest’s interfaces it also sets your Thermostat to Eco.
- The Structure contains the devices (e.g., Thermostat, Protect, etc.) for which you set their mode (e.g., Eco, Heat/Cool, etc.). You can change the mode regardless of your presence in the Structure.
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")
1 Like
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
Theres a “SHOW MORE” button at the top right of the channel list that will make the UI show the more “advanced” channels.
It could be that some channels that are part of the Nest API are still missing from the 2.0 Binding. Though most should be there.
Yes but just press “SHOW MORE” and you should see them.
You could write down all Device IDs, then remove all auto discovered Things and then manually add the devices again using the Inbox. Then you can choose your own Thing ID and enter the Device ID again. You could also create .things files using those Device IDs.
You can only change “demo_account” because it is the Thing ID. “nest” is the Binding ID and “account” is the Thing Type ID. Those IDs are hardcoded in the binding XML files.
You can mix them. But I’d stick to using one method per binding so it’s easy to still make sense of it. I don’t use the .things files myself except for testing if examples work. 
Arrgh! I hate simple answers They just amplify my stupidity!
Cheers!
Number:Dimensionless Therm_Hum "Humidity [%.1f %unit%]"
Displays
Humidity 55.0 one
one?
Number:Time Thermostat_FT_Duration "Fan Timer Duration [%d %unit%]"
Generates
Exception while formatting value '15' of item Thermostat_FT_Duration with format '%.0f %unit%': Conversion = 'u'
Please advise.
Mike
Number:Dimensionless Therm_Hum "Humidity [%.1f %%]"
And assuming you want minutes:
Number:Time Thermostat_FT_Duration "Fan Timer Duration [%d min]"
re: "Fan Timer Duration [%d min]"
The Item definitions (Fan Timer & Humidity) I posted where as they are in the binding documentation. If those are not accurate, then the doc will need to be updated.
Having said that…
I had tried "Humidity [%.1f %%]" but then the display is 5000.00000 %
Mike
Mike try just one %
The %unit% on Fan Timer was causing the error. Hard coding the UOM resolved that one. So either documentation update required… or something else in the binding itself is needed?
The Humidity… I had tried %%. Then I tried your single % suggestion. That caused an error. So I went back to hard coding %%… and now the value displays properly as 60.0%. Not sure what was going there. I don’t like these kinds of problems that mysteriously resolve themselves. Nevertheless… this one is now OK.
My code worked as it should… Problem in my setup was that java runs out of memory after a week or so… and that just kills almost everything… But that’s for a different thread (but I will wait for 2.4 to see if that is fixed).
1 Like