Actions Speak Louder Than Words

Google Home controls lots of applications throughout my home. The majority of these are devices that have only two states. Either ON or OFF.

A number of previous projects have made REST endpoints available to turn these devices on and off. So the next question had to be how could I get Google to manage these devices.

Actions

Google Actions allows you to perform an action via your Google Assistant. To create an action there are quite a lot of steps to carry out, which based on the samples would have you deploying a number of applications across the GCP infrastructure. Even then, the samples are not complete and leave you having to consider authentication and provide minimal information if you actually need all that setup. Then came the problem of multiple devices, would that then require the entire setup all over again.

Solution

To fully understand what was required for Actions and to abstract away the complexity, a couple of local microservices could act as the bridge between Google Actions and the multiple on/off devices. These would be:

Action Hub

The entry point for all Google Action requests. Would be focused on validation of the request, talking back to Googles other services (I’ve not even mentioned HomeGraph yet), and making requests out to the second microservice.

Home Hub

Responsible for keeping track of the on/off devices on the local network and executing the required actions requested by the Action Hub. So basically turning things on or off based on their rest endpoints.

Authentication

Not a fan of reinventing the wheel so decided to use Auth0 as my authentication provider and have that talk to Google Actions.

Deployment

To add a bit of complexity I wanted to run the services locally. In a previous article I had built a miniture K8s cluster hosted on a number of Raspberry Pi’s, intention would be to deploy the new microservices on that K8s cluster.

Architecture

Ultimately this diagram shows the components in use across Auth0, Google Cloud, Google Actions and on a local network.

Summary

This was not straight forward !. The documentation is poor, the examples are disjointed and the forums are full of unanswered questions. SO… the key take aways were:

Auth0

If something is too complicated in this industry it probably means you’ve done it wrong. Auth0 is very wrong. There seems to be lots of documentation and forums but the terminology has clearly been dreamt up by a think tank of mathematicians, so in a very condensed way this is what you need.

Custom API – This is the entry point for requests from the Google Action fulfillment. From this you take the Authorization URL and Token URL to put in the Google Action config.
M2M App – This is used to facilitate the authentication flow with Google. Key configuration highlighted in the grey box.
google-oauth2 – Under the Authentication > Social Connections heading in Auth0 used to communicate with Google.

Google Cloud/Actions

Simple to configure once project has been setup in actions console. Key point to note is that if you want a valid JWT for authorisation you need to make sure an audience is specified when sending requests to Auth0. Without this parameter you will get back an opaque token which would then need an introspection endpoint, I think. (Like I said previously, who cares, too much detail).

e.g.

Fulfillment URL = https://auth-hostname.eu.auth0.com/authorize?audience=https://actionhub.co.uk/

Rest of the configuration can be seen in the grey box.