Google Nest Device Access Console now available

Great news. If I’m still running 2.5, is there a way to still use the new nest binding?

Wouter posted a link to a 2.5 jar file here: Google Nest Device Access Console now available - #263 by wborn

It keeps losing the authentication after a week:

Did you confirm that your SDM configuration publishing status is set to Production?

  1. Configure the “Publishing status” of your Google Cloud Platform to “Production” (APIs & Services > OAuth consent screen) so the OAuth 2.0 tokens do not expire after 2 weeks.
1 Like

Thanks, that no doubt was the issue.

I had most of the things set up for months already, partly through trial and error. Would have been better if I had deleted everything and started from scratch with the step by step guide.

1 Like

Ok. I finally upgraded to 3.1 and am now using the native binding instead of the side-loaded one. I’m still having two issues.

First and most importantly, I am not getting read/write access to the temperature settings. I can read/write the mode and eco_mode settings, but I can only read the temperature setpoints. Any ideas?

Second, I can’t create the Bridge / account thing properly using the text files. It works ok the first time, but then it gives me an authorization error when I change or reload anything. I suspect this is because it is not retaining the refresh token. Given that the binding page on openhab.org shows an example of using a text file, I would have expected it to work. But I don’t see anywhere that I can grab the refresh token. This isn’t the biggest of deals because I can add the thing through the GUI (so far in a couple hours of testing it seems to work), but I prefer to keep everything in text files for easy clean installs.

Thanks.

Hi all,

I’ve got a silly question here apologies in advanced…I’m following the steps outlined in the guide and so far I’ve created a project in ‘Device Access console’ and the next step was to configure OAuth 2.0 tokens so that they do not expire after 2 weeks.

Question is do I need to create a separate project in the ‘Google Cloud Platform’ OR will the project in ‘Device Access console’ sync over?

Thanks all

Jeevs, You shouldn’t have to create anything extra. Its not needed for SDM to work with the Google Cloud Platform…

Same here. Does anyone know how to solve this?

Hi Dave,

Thanks for the response, I’m a bit confused as this is the steps I’m currently on:

When I look at point 1 and click the link it takes me to:

image

But it says I need to select a project. Do I need to create a new one?

Hi Jeevs,

Did you follow the step in the instructions where you create the SDM project prior to the step where you set the publishing status? The project name should appear on the OAuth screen in the pull down that says Select a project:

Create a new SDM project on the Projects page

  1. Give your project a name so it is easily recognizable
  2. “Skip” entering the OAuth client ID for now
  3. If you want to download camera images using the binding, it is required to “Enable” events. Enabling events also allows for faster thermostat state updates. The binding only uses events when the Pub/Sub configuration parameters of the Nest SDM Account Thing are also configured.
  4. After clicking the “Create project” button, the SDM project details of the created project show
  5. Copy and save the Project ID at the top of the page (e.g. 585de72e-968c-435c-b16a-31d1d3f76833) somewhere

Hi Dave,

Yes, I’ve followed the above steps already and created the SDM project:

image

However, have no option to select this in the current step as mentioned in the previous post :frowning:

Jeevs,

Looks like you have followed all the steps outlined in the ReadMe from Wouter. There may be a step missing. I had documented the steps based on the original version that Brian Higgs built. In that I do have a step to create a project in the google cloud platform.

I think your correct in that you will need to create a project there. Here is a link to that step in my documentation that you can follow to do that.

Enable the SDM API

By the way I need to update this documentation now that the binding setup has simplified it a bit removing the need to manually set up a Pub/Sub subscription. On my todo list…

2 Likes

Thanks so much for this Dave!

Will give this a read and report back if I have any issues :slight_smile:

But you’re getting two-way communication on temperature control? That’s the concerning one to me, and I can’t imagine I’m the only one experiencing it. Very odd.

Hello everyone! I have a question about the newest version of the binding, which I love, but have one smallish problem with. I’m running OH/Nest binding version 3.1.0 (on openHABian) on a RP4 utilizing the SDM configuration (as opposed to WWN), and every channel in the binding works perfectly and as expected except for “maximum_temperature” and “minimum_temperature”. I’m not sure if I am correct in my understanding, but I believe that these channels correspond to the max and min Eco mode temperatures on the thermostat (the settings which go into effect when the thermostat is in Eco mode - though the term “Eco mode” is never mentioned in the binding documentation in association with those channels). Can anyone verify that I am correct about this? The problem I am having is that these channels (which are listed in the documentation as read/write) do not appear to update in OpenHAB with changes to the Eco temperatures settings in the Nest app, and vice versa, when I attempt to send a temperature command to these channels from OpenHAB (while Eco mode is on, anyway) I get the following error:

2021-07-13 21:10:09.173 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'UpstairsMaxTemp' received command 81
2021-07-13 21:10:09.177 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'UpstairsMaxTemp' predicted to become 81
2021-07-13 21:10:09.182 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'UpstairsMaxTemp' changed from 78.3668912 °F to 81 °F
2021-07-13 21:10:09.184 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.nest.internal.sdm.handler.SDMThermostatHandler@194eca8': INVALID use case for setThermostatTargetTemperature
java.lang.IllegalStateException: INVALID use case for setThermostatTargetTemperature
	at org.openhab.binding.nest.internal.sdm.handler.SDMThermostatHandler.setTargetTemperature(SDMThermostatHandler.java:314) ~[?:?]
	at org.openhab.binding.nest.internal.sdm.handler.SDMThermostatHandler.handleCommand(SDMThermostatHandler.java:120) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
	at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
	at com.sun.proxy.$Proxy7789.handleCommand(Unknown Source) [?:?]
	at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:80) [bundleFile:?]
	at org.openhab.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
	at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]

Interestingly, when Eco mode is off, there is no error and the command appears to be sent to the minimum_temperature or maximum_temperature channel, but the temperature setting does not actually get update in Nest…

2021-07-13 21:21:12.377 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'UpstairsMaxTemp' received command 80
2021-07-13 21:21:12.388 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'UpstairsMaxTemp' predicted to become 80
2021-07-13 21:21:12.396 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'UpstairsMaxTemp' changed from 81.1 °F to 80 °F

(Note no error here as above with Eco mode on)

Maybe I am just misinterpreting what these maximum/minimum channels are intended to do?

Thanks in advance!

Looking at the SDM documentation for the thermostat, they have some caveats about Eco Mode that may be causing some of the symptoms and perhaps the binding needs some logic to handle this properly.

Set Mode Command

SetMode

Change the thermostat Eco mode.

To change the thermostat mode to HEAT, COOL, or HEATCOOL, use the SetMode command of the ThermostatMode trait.

This command impacts other traits, based on the current status of, or changes to, the Eco mode:

  • If Eco mode is OFF, the thermostat mode will default to the last standard mode (HEAT, COOL, HEATCOOL, or OFF) that was active.
  • If Eco mode is MANUAL_ECO:
  • Commands for the ThermostatTemperatureSetpoint trait are rejected.
  • Temperature setpoints are not returned by the ThermostatTemperatureSetpoint trait.

Some thermostat models do not support changing the Eco mode when the thermostat mode is OFF, according to the ThermostatMode trait. The thermostat mode must be changed to HEAT, COOL, or HEATCOOL prior to changing the Eco mode.

If you turn on debug you may see an error message referenced in the above documentation that can help troubleshoot/confirm this is happening.

I’ve been seeing similar problems, just haven’t gotten around to digging into them and opening a ticket to work with the developers of the binding…

I actually think that the min and max temperatures refer to the brackets when you have the mode set to heat-cool. As far as I know, the binding does not read or write the eco-mode or away or whatever temperatures. But those should mostly be set one time and forgotten about, right?

I am still having problems writing temperatures to my devices. I need to check my log results and will report back.

Eureka!

It was a problem in my items file. I found an error in my logs once I turned on log:set INFO org.openhab.binding.nest. The error was that it could not convert my input number to Celsius. My old items looked like this:

Number NestMainRooms_TargetTemp "Target Temperature [%.1f° F]" <heating> { channel=...

I changed them to be the following, and it now seems to work:

Number:Temperature NestOffice_TargetTemp "Target Temperature [%.1f %unit%]" <heating> { channel=...

An OH restart was required before it worked.

1 Like

I’m all up and running now with my thermostat using sdm.

The only thing that is bugging me is that when the thermostat is put into eco mode by nests own home/away process, nothing seems to change on all the thermostat items? There’s nothing to indicate that this is the case on the thermostat traits even though it is in eco mode in the nest app.

Is there a way to know that the thermostat is in eco mode in this circumstance?