As an Amazon Associate I earn from qualifying purchases.

[MUSIC PLAYING] E JOHN FEIG: Hi, everyone. Welcome to Tools for Building
Better Smart Home Actions. I'm John, I lead the technical
solutions engineering team for smart home. GAURAV NOLKHA:
I'm Gaurav Nolkha. I'm a solutions
engineer on Smart Home and a lead on Local Home SDK
that was announced yesterday. E JOHN FEIG: Great. And over the last
two years, we've worked a lot of developers
building Smart Home Actions.

And based on what we've
learned from working with you, we've put together some new
APIs, tools, and processes which we're going to
discuss here today. And don't forget
to use the hashtag #AoGDevs to share what you learn
about Google Assistant at I/O. So just to start off and remind
everybody what Smart Home is, there's this great quote
from somebody on the team. It's, "nobody likes
the light bulb that asks too many questions." And what this is about is just
that, Smart Home is kind of really focused on providing
concise grammar that's also unified and consistent
across different brands so that you get you have
one way of interacting with your devices, and one way
of talking to your devices.

And you can actually control
many devices at once. So when I say,
turn on the lights, it turns on the lights
in my living room. Again, across brands. It treats plugs and
switches the same as lights, depending on the
name that I give it. And because HomeGraph
understands room context, types, and traits, it knows that
my Google Home is in the living room and my lights are
in the living room, and just to go ahead and turn
on the lights in that room when I say, turn on the lights. And you get all that
for free with Smart Home when you do a Smart
Home integration. You also get both a voice UI and
a graphical UI that we build. And you also have routines
that you can set up to do things like, if
you say good night, you can have it turn off
the lights, lock your doors, arm your security system. And that's all powered by
HomeGraph State, which we'll talk about a little bit later. GAURAV NOLKHA: To get
started with Actions, go to Actions on Google
console and this is your window to configuring your Actions,
whether it's the conversation Actions or Smart Home Actions.

You're going to
create a new project, and if you're building
for a Smart Home Actions, make sure to select Home
Control and Smart Home tile. We've had some complaints
from developers about the discoverability
of Smart Home Actions, and since then we've improved
the experience on the console. And you're going to
do two main things, like provide the
fulfillment URL– which points to
your server where you're implementing
the smart home API. And you're going to
configure the account linking section, which is how– because we use OAuth to do the
account linking between Google Account and your account.

E JOHN FEIG: Great. And just to give kind of a recap
of the architecture of what a Smart Home
integration looks like, this is a kind of a
helpful little visual here. So when you talk to your
Google Assistant surface– your phone, or your Google
Home, or your Google Nest hub– you'll say something
like, turn on the lights, that device will
send a message up to the Assistant
servers, which does the natural language
understanding and figuring out, like, from Home Graph what
devices you're talking about. And then it sends a
message to your cloud, which is then responsible
for sending that message down to the device to take
the action that you want. And then your device will
respond back up to your cloud, and then your cloud sends
the response to Google, and then Google sends that
response down to the device to speak out to the user if it
was a success or failure– what happened.

And this is broken into
three sets of APIs. The first is account linking,
which is done with OAuth2– you know, just the
standard OAuth2. And the thing to keep in
mind here that's a little bit different, is that you
are the OAuth provider and Google is the client. The next step is
a set of intents that go from Google Assistant
to your cloud, which are SYNC, QUERY, and EXECUTE. SYNC is basically where
you have an opportunity to tell Google about the
devices that the user has. So what types they
are, what traits, which is the functionality
that those devices enable. QUERY is when Google asks what
the state of your device is and you respond with
saying, the light's on, or the temperature
is set to 65 degrees.

And EXECUTE is
basically Google asking you to take some action on a
device– turn the lights on, set the temperature, turn on
the fan, something like that. And then the last two
APIs that are part of this are APIs that go from
your cloud to Google. And those are Report
State and Request Sync. Report State is when
you have the opportunity to proactively tell Google what
the state of your device is. And Request Sync is
when you tell Google that the device list needs
to be updated for the user. And we'll talk through what all
that stuff is in a little bit. GAURAV NOLKHA: So in
addition to the cloud part between assistant
and your server to implement the Smart
Home API, yesterday we announced Local Home SDK. This SDK allows
you, as developers, to run your JavaScript
on Google Home devices. And this JavaScript
contains the business logic to control your devices
and discover your devices in the user's local network. This local part allows us to
get faster execution and better reliability for
the whole system.

Because if local part fails
for some reason, you do have the cloud as the
fallback available. E JOHN FEIG: Yeah. The Local Home SDK stuff
is really exciting. So here today, we're
going to talk about kind of three sets of things. So there's APIs,
tools, and processes. So APIs that we're
going to talk about are really here to help your
users have a better experience with the Smart Home interaction. The tools that we're
going to talk about are to help you in
your development. So things that might have been
a little difficult before or you didn't know about,
hopefully these things will make it a lot
easier as you're working. And then the process that
we're going to talk about is understanding the
submission process. And so let's get
started with APIs. We have a few sets of things– account linking. There's some new
stuff with account linking that we'll talk about,
which is really exciting. Request Sync, Report
State, that we mentioned a little bit ago,
and then also some security updates.

GAURAV NOLKHA: So let's
talk to account linking. This is one of the
first interactions your users have with Google
in terms of your Smart Home Action. So a few days ago, I was
going through this myself. I will talk about that. So let's look at the quick flow. I opened the Google Home app,
and I selected the partner devices that I was
setting up, and I see the web view
where I am required to enter the
credentials and I accept the permission to allow Google
to control these devices.

After that happened,
your server, your app, returns the code to Google. And Google servers exchange
that with an access and a refresh token. That access and
refresh token is used when Google's sends Sync,
Query, and Executing intent to your servers later. So a few days ago
when I was doing this, I downloaded the manufacturer
app, I set up these lights. After multiple screens,
I have this device set up and I'm able to control it
using the manufacturer app. And 15 seconds
later, I'm sweating. Why? I wanted to link these devices
to my Google Assistant, and I saw this page to enter
the username and password, and I had already forgotten. Well, some of you will
say that, that's not me. But we've seen our users
actually drop off on the Setup page, and it's a friction. Well the interesting thing
is, the other app is already on my phone and I'm logged in.

So can we leverage that? E JOHN FEIG: Yes we can. Introducing App Flip,
which is coming soon. This is a really interesting
way to do account linking. And what we do is, instead
of launching into a web view to do the authorization
for OAuth, we actually use the
app that's already installed on the user's phone. So what happens is, you
start the Assistant, you go through that
list of actions again and you find the
one that you want. And when the user clicks on
it, we do a couple of things.

First, we see if you've
registered your app for App Flip, and then we look
to see if that app is installed on the user's phone. And if those things
are true, then we can actually just launch
straight into your app and allow you to
authenticate your user. Hopefully the user
is already logged into the app on your
phone, and you can just use those credentials to go
get an authorization code and send it back. The other thing that
this is really great for is, it helps
with the disclosures and things like that in
the scope, to let people know like what you're
giving access to Google for. And then once you're ready, you
click the button in your app and it goes back to Google. And again, this just replaces
the authorization leg of the OAuth flow. The rest of OAuth
stays the same. So once you get a token back– so here, once you return
the authorization code back to Google, we do the
server to server exchange.

And like I said, so this
is exactly the same flow. The diagram looks the same. The only difference
is that, instead of launching out to the web,
we're working within your app. And so you have a
little bit more control in terms of how you want to do
that authentication, as well. So how does this work? We use Intents on Android, and
on iOS we use Universal Links. And this is just the basic way
to do interapp communication on these platforms.

And so let's look a
little bit of code. For Android, Google will
send an intent into your app, launching the intent with
StartActivityForResult, which means that, basically, once you
finish there's an intent that gets sent back to Google. And so the intent
that goes to you gets handled in your
activity onCreate method. And there's some important
intent extras that come in. So there's Client ID
and Optionally Scope. And you'll want to pull
out at least the Client ID to do a validation. And what you can do is, you
can validate both the Client ID as well as the
package signature from the incoming intent. And you'll want to do this
because you want to make sure that it's actually
Google calling you and not some random phishing
app that's installed.

And so once you've done that,
you verified that it's Google, you can call your
off OAuth backend. And you'll want to do this,
and send the Client ID along, to make sure that there's a
record created in your backend with that authorization code,
so that when Google does the token exchange
later on there's a valid code for this
user in your database. And so once you've
done that, and you've gotten a code back
from your server, you can create a new
Intent that you're going to send back to Google. You'll add a couple extras. One is Response Type, which
you set to Authorization Code. And the other is the actual
authorization code itself. You'll want to make sure
to set the result to OK, and then you're to
launch back in to Google. On iOS, its Universal Links, and
it is even more straightforward just to look at just a
couple of links here. So the first one is the link
that launches into your app from Google.

So you own this Universal
Link and you'll register it with Apple just like you do. And there will be several
query parameters that come in. The Client ID–
same as on Android– Scopes– which you set in the
actions of Google console– the State– which is a string
that you just respond back the identical string when
you give your response– and then a redirect URI– that's the universal
link for Google that you're going to use
to launch back to Google. And here, instead of
a package signature, you can actually validate
the redirect URI as well as the client ID. You know, again, do the
same validation on iOS using those couple of things. And then once you've
done that, you can call your
OAuth backend again with your user credentials
that are already stored in the app, as
well as the Client ID.

Once you get an authorization
code back from your servers, then you can respond
back to Google using Google's URI that was
provided in the redirect URI. And again, the authorization
code and the state. GAURAV NOLKHA: So now we're
happy with those lights, and we get new lights from
the same manufacturer. And I go to the same app and
I set up these new lights. And just like last
time, we do the Setup and now I'm able to control
the lights from the app. But the great thing was,
I am immediately also able to control it
from Google Assistant. How did that happen? That brings us to Request Sync. So when your cloud sees– a
change in Users Devices List, or if you add really new
capabilities to your devices, you let HomeGraph know that,
for this particular user, something has changed. That's the requesting API. And at that point,
HomeGraph calls back the same Sync Intent that
happened the first time the user had linked.

So the good effect
is, the user didn't have to do any
account linking again. And assistant now knows
about the new devices, so the user can go and control. And this really provides a
very good user experience for your users
who actually chose to buy new devices from you. So let's look at the
code command equivalent of what happens here. It's very simple. You let us know the
agent user ID that is affected with the change
in the Device's List, and you specify the
API key that you get from Google Cloud console
and call the HomeGraph Request Sync API. And there. E JOHN FEIG: Great. And now let's talk a little
bit about Report State.

Report State, as
we mentioned, is when you proactively send
the state of your devices to Google. So every time a user
switches on a light, you send this API to
Google letting us know that that light is turned on. If the user changes
the thermostat, you send that State. And the State data in
HomeGraph is ephemeral. And so why does
Google need this? And the answer is
Touch Controls. So we have smart displays
and the Google Home app that have graphical
controls for your devices. And basically, to be able
to draw that control, we need to know what the State
is so that we can draw it appropriately. And the Report State
API gives us the State that we need to be able to
draw accurate and responsive controls. Let's look at a
couple of examples. So here we have the Google Nest
hub as well as the Home app, and you can see some
controls getting pulled up.

These are two
different surfaces, they're convenient in
different situations. But both are showing
the ability to control a group of devices which might
be even different brands. And so this is a
really great way to do interactions for users. And what happens, though,
is that if you don't provide the State via Report
State, instead of getting the nice graphical control,
what the user sees immediately is a spinning dial while
we query for the State. And it's really kind of
a jarring experience.

And so implementing this
is fairly straightforward. There's just a few steps
to get Report State working that you need to do. The first– which is
just a one time thing– is to go enable
the HomeGraph API. And then you'll create a service
account key, which is just a one time thing, again. And then at runtime
in your service, you'll generate a JSON
Web Token, or JWT, which is a verifiable method
of representing claims securely between two party servers. And then you'll create a
Report State JSON payload and you'll call the API. Now let's walk through each of
these a little bit of detail. So to enable the
HomeGraph API, you'll just go to the Google Cloud
console, select your project, and then under the APIs and
services, you'll go to Library and search for HomeGraph
API and click Enable.

Pretty straightforward. The next– again, this
is just a one time thing– is you would generate
a service account key. And here, again, in the
APIs and services section, you'll dropdown to Credentials
from Library, where you were. And you'll click the
Create Credentials button and you'll just go through
the steps to create that. We recommend JSON type because
it's a little bit easier to work with. GAURAV NOLKHA: So now that
your server has access to your service
account key and we have to call the repository
notification API to let HomeGraph know of
this change in State. We will need two things. First is a token to
communicate with HomeGraph, and second is the payload. So let's look at the first one. So to create the token for
Google to verify your service, we need a few things. First is iss. This is a service account email
which you can get from the JSON that you downloaded.

The scope and audience will
remain same, pretty much, because you're calling
the HomeGraph API and you need to get the token. Secondly, iat, the current time
is what you will specify here. And you have to make sure
that the expiry is typically an hour from the current time. And this is
specified in seconds. Once you have this
information handy, there are libraries available in
pretty much all the server site languages that are out there. So check out JWT.IO
for more information about the libraries for
your specific platform and framework. And you should be able
to take this information and generate the token.

And finally, you
make sure that you sign this token with
the private key that's in the service account JSON. So now that we have the token,
let's look at the payload. So when the device
changes state, and it lets your cloud
know of this new state, you're going to create
this JSON payload. And you see here, we
have the agent user ID for which this device list
has changed its state. And then we have
two devices here. The first one is
on, and it's online. And the second one– probably a lock or a door– and it's locked. So you specify this JSON. And finally, let's
call the Report State in notification API. And let's take a look at this
in the form of a curl command, which is very straightforward. The token goes into the
authorization header as a Bearer token, and the body
becomes the Report State JSON payload that we just created.

And you make a simple post
called, to the HomeGraph Report State and Notification API. And that's it. At that point, all your smart
displays, visual displays, and Google Home app
should show you the latest state for your devices. E JOHN FEIG: All right. So next we're going to talk
about enabling security use cases for Smart Home
with Google Assistant. How are we going to do that? Well, we're going to two
factor authentication, or 2FA. 2FA is basically a
second factor validation, something like a pin
or an acknowledgment. And it's used to make sure that
the person making the request is actually authorized to do so.

And so why is this important? Well, we heard your
feedback and you wanted to be able to enable
Smart Home on devices like locks, or security cameras,
security systems, or even windows. We launched a couple of
new traits this week– lock-unlock and
arm-disarm– that 2FA is really, really useful for. And the neat thing is
that all of your devices, any interaction for EXECUTE
and QUERY, can use 2FA. So if you have something
that you want to protect, your want to make sure that
there's an acknowledgment, you can do that. And the other thing
to keep in mind here is that, for
pin-type protections, you actually own the pin. So it's owned in
your service, you can change it as frequently
as you want– even on every interaction
if you really want to. So let's look at a couple
of different examples of how this works. So the first is No
challenge, which is basically the same is a normal
interaction where you say, OK, G, turn on the lights. And assistant says, OK,
turning on three lights. The second is an Ack needed.

And this is where you might need
some sort of acknowledgment. You just want to make
sure that this is really what the user wants to do. And in case, the users ask
you to heat up the living room to 100 degrees. Which your service might get
that request and say, like, that's pretty warm. That's really outside our range
of what we'd recommend a room to be, but we can do that.

And so you might want an
acknowledgment here and just ask the user, are you sure? And the user says, yes, and then
you can go ahead and do that. And finally, we have
Pin needed, which is asking Google
to unlock the door. And here we want a little bit
more than just a confirmation, so we ask for a security code
and the user provides that.

And then once you have
a code that's correct, they can go ahead
and unlock the door. And you can actually see this
in practice in our sandbox with a cookie jar that's
protected by two factor authentication to
keep the kids out. GAURAV NOLKHA: Yeah,
definitely check that out. It's cooler than the
code, but the code is very simple as well. So let's take a look. So typically, when the user
wanted to control a device, we send an EXECUTE Intent
to your server, right. And without two
factor authentication, your server returns
a success if it's able to control the device. But for this case, if you wanted
to implement the two factor authentication, you would
return an error back to Google for that EXECUTE response. And this error as the status. And the error code will
be Challenge needed.

And one important
thing you're to specify is which type of
challenge you need. It could be Pin or
it could be Ack. So at that point assistant
will announce it to the user and either ask for
an Ack or a Pin. And now Google calls another
EXECUTE intent to your server. And in this case, the
pin will be specified in the EXECUTE intent. So pretty straightforward. Pretty much exactly
how you do an EXECUTE and Process and EXECUTE intent. But this time it has the pin,
your server validates it, and if it is a valid pin, takes
the action that user requested.

E JOHN FEIG: All right. Let's move on to Tools. So these Tools are
here to help you in your development
of Smart Home. And we developed a
lot of these, really, based on our experience
supporting you in your development
as well as feedback that we've gotten directly. And the first thing
we're going to talk about is a brand new tool that is
called the Smart Home Test Suite. And this is something that
we very recently launched, and it addresses
this major problem that people have had
when wanting to go live with their actions.

The end of development,
you're done, you want to publish
it make it available, which is that previously,
we required devices to be shipped for certification. And now we realize that this
is hard for a lot of people. Shipping devices
is expensive, it's easy to miss those
emails back-and-forth. The process was a bit opaque
and there were sometimes multiple rounds of testing. And especially if
you're international and had to deal with customs. And so what we're
doing here is, we're actually giving you
control over the process. You can test from
your desk, there's no need to ship devices. And it helps to give
you clarity and insight into the certification testing. So how does this work? Well, the basic flow
is that you will start by developing an action. You just kind of
need the bare bones to make one thing work, right. So you'll do OAuth,
SYNC, EXECUTE, and Report State for at least making
sure that one thing end-to-end works. And then after
that, you'll account link your developer account and
make sure that you can use it. So just do a smoke
test, make sure that you can turn on
your light or something.

Next, you'll set up a Google
Home right next your computer and crank up your
speaker's volume, or you can put headphones on it. And the reason is because
the test tool actually generates TTS. It generates commands that
say, OK, G, turn on the lights. And the Google will
pick it up and then try to take that action. So it's kind of a cool
end-to-end test like that. And so then you can load
the tool and run it. And you can actually
run this tool as much as you want while
you're in development. And it's great for
test-driven development because we don't send the
results from the tool back to Google until you're ready.

And then when you
are ready to launch, you can use a form linked in
the Tool to submit your results. So another thing that's
really cool about this is that it's only
in the browser. This is a browser-based tool. It doesn't send
results to Google until you submit that form. And so with that, we do need a
couple of pieces of information to make this run. We'll request the
agent user ID so that we can identify which
specific user to pick out and the service account key. And these two things are
needed for a HomeGraph API that will allow you to pull
devices that you own, and you own the service
to, out of HomeGraph. And we basically use the same
mechanism for this test suite as well as the another
tool that Gaurav will talk about in a minute. And once you've provided
those couple of things, the project ID should just
get filled in automatically if you provide a valid
service account key. Next we do a HomeGraph
Sync, and we ask HomeGraph to get that user's devices.

And in this case, we get
a light with the traits on, off, and brightness. And then once we have the
device, we can click Next, and the tool will
just automatically generate the test cases based
on the device types and traits that you've synced. Next you can see
it start running, and it'll just speak
out the commands, and it'll go to the
Google Home, and then the whole thing will happen. And you'll Report State
back, and we can pick up those Reported State events.

And you can see the progress–
where it is in the test– as well as in the
log area, you can see if the tests are
passing or failing, which is really helpful. And then once you're done– and if you have
any failures, you can open up a spreadsheet
that gets generated, and look exactly where, OK,
these tests were passing and then this one
was a failure– and see why it failed. And so we tell you, here's
the results that we expected, and here's what you
gave us, and that's where the discrepancy
is, so that you can very easily go and fix
that and rerun the test. And then once you're
done with that, you can just submit your results
in the form that's linked and you're good to go.

GAURAV NOLKHA: So this is
great, because integration tests can be hard. And especially now
this involves voice, your server, your devices. So you really want to use that. And I use that, personally,
for the new traits that I am working with these days. It's amazing. Check it out. So, OK, moving on to
Report State tool. Now one of the things that John
mentioned about Smart Home Test Suite is that it relies on
Report State working so it can check the state properly. But what if Report
State is not working? So here's a tool that'll
help you do that.

So we again need the same two
key information– the agent user ID and the
service account key. Based on this information,
we can query HomeGraph, get the state of the
devices that HomeGraph sees, and if there is a discrepancy
between what HomeGraph sees and what your server is seeing,
some debugging may be in order. So this is a tool that
gives you a view into what HomeGraph is able to see. After you fix the issues
with Report State, you know, it should all
work with the GUI controls.

E JOHN FEIG: All right. Next up is a tool
called StackDriver. And StackDriver, as
some of you might know, is actually just a
generally available tool, provided by the
Google Cloud Platform, that is for scalable logging. But here we're going to
actually talk about how we use it for Smart Home. And one of the things that
we heard from developers is, there's this
kind of frustration around a lack of logs
and a lack of insight into what's happening
on the Google side if there's a failure. And what we're doing with
StackDriver is providing those assistant side logs so
that you can see if, you know, you get an error TTS that
comes back from Google once you've tried to take some
action, what actually happened.

And the other neat
thing about this is that StackDriver
allows for integrations. And so you can actually
create a service where you can subscribe
to these log events and have them sent straight
into your own logging service so that you don't need
to go to multiple places to look at logs. You can also parse the logs
that are coming in for analytics and write your own
metrics based on that. So let's look at
how to enable this. The first thing
you're going to do is, you're going to go to
the Google Cloud console and you're going to, again,
pick your Action there as your project.

And then you're going
to open up the menu and go to the logging
section, and it's under Logs. Next, there's this
Resource Picker dropdown that you'll select. And when you click
that, you're going to select the Google
Assistant Action. Once you've selected
those things, you should see logs coming up. And here is actually
something that I was working on a
couple of weeks ago where I had backend failures. And this is the
sort of thing that, if you're using maybe an HDB
proxy like Nginx or Apache in front of your service
to handle the web requests, and then will forward on the
request to your service– if you get a 500, it
might actually not be getting forwarded
back to your service. And so your Services Logs might
not have this failure in it.

And that's where StackDriver is
like really, really useful, is you can see those failures
that maybe your service doesn't log because it doesn't
get those requests. Another example of
that might be if you have auth failures, where
the credentials are expired or maybe not existent
on the Assistant side. Those will get logged
here too, and it'll give you an indication that
there's an auth failure. And like I said,
you can integrate this using Google Cloud Pub/Sub
to have those StackDriver events sent straight into
your own logging service if you already have one. And you can, again,
peg metrics based on the various types
of failures that you get to understand the
areas where you need you might need improvement.

And we have this
great tool, that's a sample on GitHub, that
really just walks you through how to do this. It walks you through how
to create an integration with StackDriver and
then also to parse out those logs for metrics. And it's a Smart
Home focused example. GAURAV NOLKHA: So
John just showed us an error with Sync
Response on StackDriver. So now how do you debug in case
you actually send a 200 back? So you think your Synced
response is right, but Assistant did not
like it and it showed the user account linking error. Sync Validator comes
in handy at that point. So on our adaptive
documentation for Smart Home, we have embedded a validator. It's a simple input box where
you paste your Sync Response and let the script tell
you if it sees any errors with your Sync Response. So like you see here, Fight
is not a valid device type.

It probably needed to be Light. And Darkness is not a valid
trait, it should be Brightness. It also tells you type errors. So for example, the name in this
case should have been a string. And once you fix
these Sync errors, your account linking and
sync both happen to work. And you know, it's a
better user experience and you can fix
these things easily. We've talked about a
lot of applets and tools that you can leverage. But what if you're just starting
with the Smart Home and API and you want to create
your first action? We're going to check
out the Codelab. And you can actually do it
in the Codelab area right after this talk, or you can
go home and check it out on the web. So the goal of this Codelab
is to create a virtual device and then be able to control this
virtual device using Assistant. So you're going to implement
the SYNC, EXECUTE, and QUERY endpoint, and also Request,
Sync, and Report State. So it's a complete package. It's a gateway to get started
with the Smart Home API.

E JOHN FEIG: All right. And now we're onto
the last section, which is understanding
the process that we use once you're ready to submit
your Action and publish it. So let's talk about the
submission process a little bit and clear up kind
of what happens, so that you understand
what's going on when you click that Submit button. And we're also making
some improvements to make this easier and smoother
for you throughout the process.

And so here's how to
submit and what happens. The first thing
you're going to do is submit passing results
in the Smart Home Test Suite using the form that's
linked in the tool. So just really simple–
make sure you're passing the Test Suite. Second, is that you're going
to go and fill out company and branding information in
the Actions on Google console. Just make sure that you've
filled out everything that we asked for,
and it will make things go quite a bit faster. The next move over
to the Google side– and so this might actually
be a bit of a back-and-forth. We might reach out
to you with things that need to be updated
and stuff like that. And those would come
out of two things. So there's a functional
certification that happens where we review
the results that you submitted for the Smart Home
Test Suite as well as a policy review that
happens to make sure that you're in compliance
with all of our policies.

And then once you
pass those two things, you're ready to go live. And we have some tips that
we've kind of collected over the couple of years about
how to make this as smooth as possible and to kind
of avoid back-and-forth. And the first thing that's
really, really important is to use the appropriate
types and traits. So this is something that we
see as kind of a common issue. And we see things like
using on-off as opposed to start-stop. And there are cases where you
might have a robot vacuum, and Start Vacuuming is a
much more natural grammar to say than Turn On the Vacuum.

Another one to keep in mind
is like temperature control versus temperature setting. One of them is for
thermostats, and the other one might be for your oven. And then finally,
also making sure that you're using a two
factor authentication where appropriate. So you know, if it's a lock,
security system, you really want to make sure
that you're using 2FA. The next thing is
again, just making sure you're passing
the Test Suite. Not a lot to say there, but
definitely run the Test Suite as frequently as you like. The next thing is to make sure
that your descriptions match the locales. So let's say that you're ready
to launch your Smart Home Action, and you're
shipping devices in Japan and you want to launch
your Action there. That's great. Make sure that, instead of
submitting a description that's in English, you
submit one that's also in Japanese if you're
selecting Japan as a locale.

The next is making
sure that you're just in compliance with all
of our policies for AoG. And then you'll
want to make sure that you supply a
valid privacy policy for each supported language. So again, you've submitted
a Japanese description, you're going to submit
a privacy policy that's written in Japanese. The next thing is to make
sure that you've implemented all of our APIs including Report
State, Request Sync, and Query. These are really critical,
and in fact the Test Suite won't work well if you don't
implement these things. It won't work at all if you
don't implement Report State.

You'll want to make sure that
account linking is working. And this might seem obvious,
but once you launch, your users are going to
try to do account linking and start interacting with you. And if account
linking doesn't work, they won't be able to do that
and you'll have zero users. You'll want to make sure that
the cloud to cloud latency is consistently under 900
milliseconds, which is just kind of where we really find
it to be very noticeable if there's cloud latency. When you say, Turn
on the Lights, and then it takes more than
a second for that to happen, it's pretty noticeable. The next is to make sure
that the authorization grant in your OAuth flow
grants permission to Google and not
something else.

We don't want to see
permissions granted to Google Assistant, or
Google Home, or Nest, or anything else– just Google. And finally, make sure that
the icon that you provide is 144×144 circular
with a white background. GAURAV NOLKHA: Cool. And if you are a
maker, or someone who's just doing this
for fun, definitely add the Assistant
and the voice control to your devices in
your fun project and you don't have to
worry about the approval.

So use it. And then finally, all the things
that we've talked about today and the documentation for
this lives under our docs at developers.googl
e.com/actions/smarthome. And it lives inside
Actions Google and click under the Smart Home section. And this will guide you through
the APIs, and the tools, and everything that we
just talked about today. So finally, thank you
very much for coming here. Last two years has been
a thrilling ride for us on Smart Home, and we've worked
with many of you in the room and outside this room. And we really thank you for
all the feedback on the APIs, on the tools, and our
processes that you provided that has helped us improve
our tools and all the APIs and processes. And we can't wait to see what
you guys do with these tools and the actions you build.

Thank you. E JOHN FEIG: Thank
you for joining us. [MUSIC PLAYING].