[nest] Add support for Smart Device Management (SDM) API

[wborn]

• Reworks WWN implementation so that the thing types have a wwn_ prefix and the classes have a WWN prefix and reside in a 'wwn' package
• Adds an SDM implementation which is also based on: https://github.com/bhigg-code/openhab-addons/tree/2.5.x/bundles/org.openhab.binding.nestdeviceaccess
• Adds unit tests for (de)serialization of the SDM and Pub/Sub API requests and responses
• Updates the binding documentation for the changes and additions

Fixes #8664

---

The following bundles can be used for testing the changes:

• org.openhab.binding.nest-2.5.13.20210530.jar (retro OH versions: 2.5.0, 2.5.1, ... 2.5.10, 2.5.11, 2.5.12)
• org.openhab.binding.nest-3.0.3.20210530.jar (older OH versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0.M1, 3.1.0.M2, 3.1.0.M3, 3.1.0.M4)
• org.openhab.binding.nest-3.1.0.20210530.jar (newer OH versions: 3.1.0-SNAPSHOT, 3.1.0.M5)

For documentation, see the updated README.md.

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/google-nest-device-access-console-now-available/105404/173

[junalmeida]

@wborn Suggestion:

In sdm-config.xml give brief instructions how the user can create the "Device Access Console" project, and "Google Cloud Console" oauth credentials. I had no idea (and I couldn't find anywhere) whether to create a web or desktop oauth type.
And after figuring out that I need a desktop type, the redirect-url from google instructions is a mistake, as there is no google.com uri allowed for a desktop oauth type.

The correct url to get the auth code is:
https://nestservices.google.com/partnerconnections/{Project_ID}/auth?redirect_uri=urn:ietf:wg:oauth:2.0:oob&access_type=offline&prompt=consent&client_id={Client_ID}&response_type=code&scope=https://www.googleapis.com/auth/sdm.service

With redirect_uri set to urn:ietf:wg:oauth:2.0:oob. I could only find this out by reading the code.

Also, I forgot to enable the correct API, so it would be nice to see that instruction in the config page as well. If API is not enabled, discovery will fail silently because the resultant json is:

"error": {
    "code": 403,
    "message": "Smart Device Management API has not been used in project XXXXXX before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/smartdevicemanagement.googleapis.com/overview?project=XXXXXXX then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",

After passing by all these, I can now successfully connect to my Nest thermostat as the old API is not available for me. I'm using your latest code from the source of this PR compiled locally.

I don't know yet how to enable Pub/Sub because I can only see the Pub/Sub topic id. Not sure how to fill it out.

Thanks for your awesome work and I hope this can get merged to openhab soon.

[wborn]

Yes adding some docs on how to configure everything is one of the reasons why this PR is still WIP. 🙂 Getting an authorization code for accessing Pub/Sub is very similar to how it is done with Google Cloud TTS. The configuration is a lot easier now it can all be done by creating an account thing using the UI and configuring the authorization code to get the access/refresh tokens.

[fwolter]

Should the "not backward compatible" label be set?

[junalmeida]

Generating the correct link on settings page after filling out the project id and client id would be awesome IMO

[wborn]

I've fixed and improved the docs @techie66. That part got lost somewhere while copy/pasting. 👍

[wborn]

Hey I've also backported all the Nest SDM changes of my PR to 2.5.x for all the retro openHAB-ers. 🙂
I've added the JAR to the initial PR comment. It seems to work equally well from the brief testing I gave it.

[wborn]

It's nice to see the PR made it into OH 3.1! 🥳🎈

[resetpointer]

is there a reason why OATH2 is implemented as a "web application" instead of a "desktop application". Openhab is certainly is not a web-application, it would make more sense if the OATH2 account is registered as a "desktop application".

Is it possible to update the nest_sdm addon to support OATH2 account of type "desktop application" as well. thanks.

[wborn]

is there a reason why OATH2 is implemented as a "web application" instead of a "desktop application". Openhab is certainly is not a web-application, it would make more sense if the OATH2 account is registered as a "desktop application".

See: https://support.google.com/cloud/answer/6158849#zippy=%2Cweb-applications%2Cnative-applications

A web application is accessed by web browsers over a network.

• Applications that use client-side JavaScript to access Google APIs must specify authorized JavaScript origins. The origins identify the domains from which your application can send API requests.
• Applications that access Google APIs from a server (often using languages and frameworks like Node.js, Java, .NET, and Python) must specify authorized redirect URIs. The redirect URIs are the endpoints of your application server to which the OAuth 2.0 server can send responses.

It would be nice when we can use openHAB in the redirect URI so it is easier to configure this.

[resetpointer]

Wborn,

I reviewed the code base of TTS and nest-sdm yesterday. What I observed was that the application type used to be "tv and media devices", which is similar to desktop application type. Since Google OATH2 depreciated OOB (out of bound redirect), openhab began to change the application type to web application, and I believe this was recommended by the SDM api.

Regardless, the authentication flow is too complicated for a typical end user. This whole process can be simplified by implementing a redirect backend, that can be hosted on openhab.org or somewhere in the cloud that everyone can use. This whole process of issuing manual post request and then copy/past authorization code is just too tedious, we need to simplify the common OATH2 verification process for OH users.

Thanks for the prompt reply, btw.

[wborn]

This whole process can be simplified by implementing a redirect backend, that can be hosted on openhab.org or somewhere in the cloud that everyone can use.

I think it should be possible to redirect the browser to your own OH instance even if it does not expose any ports to the Internet. Some bindings already have a servlet for handling such a redirect (see SpotifyAuthServlet). But I think it would be better if such flows are also supported by the openHAB Core so servlets handling the redirect do not have to be duplicated in each binding that uses (Google) OAuth 2. 🙂

[resetpointer]

This whole process can be simplified by implementing a redirect backend, that can be hosted on openhab.org or somewhere in the cloud that everyone can use.

I think it should be possible to redirect the browser to your own OH instance even if it does not expose any ports to the Internet. Some bindings already have a servlet for handling such a redirect (see SpotifyAuthServlet). But I think it would be better if such flows are also supported by the openHAB Core so servlets handling the redirect do not have to be duplicated in each binding that uses (Google) OAuth 2. slightly_smiling_face

good idea! Please address it to the core developers.