Local Technologies for the Smart Home (Google I/O'19)

I. Hope. Today you were able to listen to some of the great talks we've had and explore. The different sandboxes, and if you haven't seen the smart homes section in the assistance sandbox I highly, encourage you to do so, thank. You we have a great team there and some really cool demos, including. Showing, you how the smart home API can, help you grow a better garden, on. Behalf of our team were, really excited, to share with you some, of the smart home technologies, that we've been building since, we last spoke to you at I 18. My. Name is Carl Vogel, I'm a product manager on the smart home team my, name is Bennett I am a software engineer I am, guru I'm a solutions engineer and, smart home, I'd. Like to begin with a story. One. Of my friends recently purchased some smart home devices in. Particular. Light, bulbs from one company and smart, plugs from a different one and he, put them in an area that he calls the downstairs. And, when he gets ready for bed he walks upstairs and he, says hey, G turn, off the lights, well. He was telling me that often times they don't respond, together one. Set of lights often, responds, a half second or a second, faster than the other or. Sometimes they just take a really long time to respond in general or. They, don't respond at all as. Google. On our developer, community work, together to, grow smart, home we, need to work together to, solve these challenges. We. Believe one method, is to shift processing. From the cloud to, the local, environment, we've. Taken our first step in this direction to. Improve the experience, for users like him and the. Millions of other users, that use our products, on a daily basis, we're, happy and to, introduce that, that first step is the. Local, home, SDK. The. Local home SDK, enables. You to locally. Process, and fulfill smart home commands, received, from the Google assistant, we. Do this by inviting you to build and run your smart home business, logic locally. On Google, home speakers, and Google. Nest displays. Then. We. Securely, give you access to the lower level radios to, communicate over the local area network with. Your smart devices, through. This we. Can together deliver, substantial, improvements. In latency. And reliability. But. First before I talk about the local home SDK, let. Me give you an intro to the smart home API and then, show you how the local home SDK, layers, on top. The. Smart home API is the foundation. Of our smart home program, let's. Begin with how devices, are defined, and, integrated. Into the assistant, first. Developers. Specified, the vice tete type, this. Is really the what is it factor is that, a light bulb is, that our microwave, a, camera. Device. Type is our method to classify, the, overall essence, of the, device in a, user's home. Second. Developers, specify. A device, trait, and this, really describes, the overall functionality. Of, the device what. Can it do how. Can users control it, devices. Oftentimes have multiple traits for, example a light bulb may have the traits on/off brightness. And color, setting. Once. The device type and trade are specified, we, can then bring these devices, into the assistant, and specifically. Into our home graph using. The sync intent, home. Graph is our database, that'll, enable us to build a topology, of the users devices in their, home now.

That The devices are defined, and in our home graph let's, see what happens when a user issues. A command for your device. When. Our user says a command, such as for example hey. Google turn on the lights, we. Send that to the assistant, server as a, and, then, assistant server processed, this waveform and ultimately. Determines. Which device, or, devices, the. User is trying to move into what state. Then. We send that as a structured, JSON, payload, to the developer, to be processed, and ultimately. Fulfilled, and as, we see the, developer, communicates. With, the end device. Through. This very simple. Method. To integrate, devices, into the assistant, and have users control them we have grown exponentially. Since. 2017. In fact. We, work with over 30,000. Unique devices, among. 3,500. Brands we. Encourage you to join us in to integrate, if you haven't, done so already and, a, great place to start is the smart home one-on-one, talk that, some of our friends gave earlier, this morning. Although. Successful by almost all accounts, cloud. The cloud integrations, have, inherent, limitations. We. May have a Google home speaker, and a smart device within 10 feet of each other yet, this command, needs to travel hundreds, if not thousands. Of miles before. Returning back to the same room this, takes time and of, course provides opportunities, for jobs commands, so. We started to think at Google can, we leverage the fact that these are on the same local area network, the. Local home SDK, is our method to do so. At. Google to the developer, experience is core, to our thinking. And this deeply influenced. Our design tenets, with. The smart home API being, the foundation, we want it to leverage its capabilities. And layer. The, SDK, on top as a deeper, integration. Not, as in either org. We. Also. Implemented. What we call a coma zoo our philosophy, in that, we wanted to work with your devices, as is, today. Without. Requiring, any form wrap modifications. Lastly. We've. Heard from you thousands. Loved the smart home API. So we wanted to mirror, that familiar. Interface on to the SDK, so what, these tenets now understood, let's go ahead and revisit, what happens, when, a user issues, a command using. The local home SDK, as. We, can see the user still, says a command, and it still goes to the assistant server to be processed, however. If we. Know that this device is locally, controllable. Will. Actually. Send that command as a JSON, payload, down to, the Google home speaker, or Google, Nest display will. Then pull up the appropriate developers, JavaScript, file, that has their smart home business logic on it to process the intent and then. We'll provide access to the lower-level Wi-Fi, radio to, ultimately, communicate. With, your device over the local area network, and notice. The, developer, still controls, the smart device but, can now process and fulfill, that command, locally. And. Since. We still have this cloud the cloud integration, we, now have the cloud as a fallback. So. What is this app what is adding this local path do well, first it. Allows us to reduce the latency after. A payload, leaves the assistant, server to, less than 300. Milliseconds. This. Will provide a very very. Noticeable. Benefit, for your users. Second. It allows us to drive the reliability. That a smart home command, reaches the device to, well above, 99.9%. And, we, primarily achieve, this by having redundancy. In the system. So. The next natural question is this sounds cool but will this work with my device well. I'm happy this to say this works with all the device types including. The 16 new ones that we just launched at i/o and, in. Particular. This is not just for Wi-Fi devices if you, use a hub or a gateway for your, smart home integration, for, example a ble, hub or ZigBee hub you, can talk locally, to that hub as well in. Addition, we, support all the traits that you use today with, the one exception of two factor authentication. Recall. From the tenets that our goal was, not to require, any firmware changes, on the part of the developer and so, we set out to support, the most popular, discovery, and control, protocols, as shown, on the slide behind me and.

Lastly. Which. Devices, can host or run this JavaScript, well. Really happy to say here, that it works with all our Google home speakers, and Google Nest displays, including. The, new Google, Nest hub max. So. We've talked a lot about the experience for developers and, this, is i/o of course but. What about users, what. Do users have to do to, gain this benefit, and the, answer, absolutely. Nothing. Once. You integrate the local home SDK, we, go ahead and establish the, local path for all the users that are already on, your smart home project. So. With that I want to turn it over to minute to talk more about the technical architecture. The. Smart home ecosystem, today relies, on developers. Bringing, in devices better, discovered, and controlled, on the local network in different ways in. Many cases the application, layer or the business layer logic, is openly, documented but, nonetheless custom. Early. On we decided to make the local home platform, flexible, enough such, that our smart home developers, would be able to leverage the platform without. Compromising. The ability to bring, out their unique features at. A high level let's, look into the elements to make this flexibility, happen we'll. Talk about the Google device and what's happening there we'll. Talk about the, overall, Google infrastructure. And how the Google device fits into it and then, we'll go into the specifics, of discover, and control. To. Give a bit of background a few years ago we built chromecast, chromecast, runs. On chromium, which, is the open source project behind Google, Chrome. Chromecast. Or more, specifically, the Google cast SDK, created. A wave, developers, to run their code on a Google, built device, this. Code doesn't run natively but, rather as a app in its own container, since. We're running on something like Google Chrome this. Container happens, to be a browser, window and the, app is JavaScript. Leveraging. This browser technology were, able to run multiple media, apps in their own sandboxes. Securely, and simultaneously. Building. On the caste foundation, we created the local home SDK, and the local, home platform, the.

Local Home SDK, and the platform, together are, the interface, between developer, smart home apps and the, low-level radios used, to talk to smart devices. Local. Home platform, has two important, tasks to take care of first. Interfacing. With the Google assistant such, that we can leverage the smart home API as is and second. To provide controlled, access, to socket communications, using TCP, UDP or, HTTP. HTTP. And HTTPS. Protocols, I, just. Spent a couple minutes talking about the Google home device and how, you can soon run smart. Home JavaScript. Apps on it in. Order to communicate with your devices, in the users local network we, also how to build out some components, in the larger smart home ecosystem, with the Google assistant and with, some help from you if, you. Already have a cloud the cloud smart, home integration, you'll be familiar with the actions on Google console and home. Graph. There. Are some additions to both of those systems, in order for you the developer, to, help your users benefit, from this new local path, let's. Look at the high level flow to discover and control your. Devices in the, users local environment, in the next two slides. Before. We talk about the code that you'll write to Ronald go home you'll, need to add some data via, the actions of the console, and the, cloud to cloud integration. In. The actions of Google console you'll, tell the Google home how to find, your, devices, in the users local network we. Implemented, the common discovery. Protocols, like mdns, UDP. Broadcast. And UPnP. Next. You'll update the sync response to include a hint to, the local home platform, that, will help with identifying, a local, to locally, discovered, device is the, same device, that. Appears, in the cloud the cloud integration sync. Device list, once. The discover information is, added via actions of google console and you've. Added this hint to. Sync response Google, assistant will send this information to all, Google home devices that, a user is linked to if, the. Local home platform, can match a locally discovered device to, a device in the list from your cloud we've, established the local path. Great. So now we have a local path and the. User says hey, Google turn on the lights the request, from Google assistant, is dynamically. Routed to, a Google home device that, has claimed that local route the. JavaScript, app running on the Google home can, now handle this request and can, communicate with the device using. Application, layer protocols, like HTTP. Or TCP. And UDP sockets. So. When we set out to build the local home SDK, we want to make sure that developers have best, experience. So. Let's look at the developer flow starting. With building, your application, - debugging, it for, certifying, your application, and even launching, like we've taken care of the complete spectrum and in next few sections of the site's we'll look into these each. So. First let's start with developing, your typescript, application, they'll help us discover and control. The devices locally. To. Help discover, and control devices locally, you, as a developer needs, to do three key things first. Like, minute mentioned earlier the, scan config, on actions, on Google console. Second. The, little bit of help from your works with integration, where, you update your sync response, to, give us a hint that, these devices may be locally, controllable, and third. Your, typescript app this. Is the app that will, run on Google. Home devices now. A quick note about the app itself, we've. Been talking about JavaScript as the app that runs on the devices but, we highly recommend developing. Your app in type step it's, just a better developer, flow. So. What does this app do locally, it, needs, to handle two key events first. When. Google home devices discover, a device in the local network that. Belongs to you as a provider. We. Fire and identify, intent, and that needs to be handled by your app. The. Second one is reachable devices which is a special case of the first one where if we, have discovered a hub or a bridge, device and will go into the details in coming sections and finally. When the user wants to control the device the. Platform, fires executes intent and for those who are familiar with the smart home API it's, the same execute, intent that, your JavaScript receives. Like, your cloud endpoint, receives. Let's. Go into the details of what, the discover flow looks like. We. Talked a lot about this actions, on Google console so what does it look like in. A few. Days you'll be able to see this new, UI which. Allows you to update how. We, find your devices in the, users local network in this, particular, example we've. Added. The ability to upload, the, UDP broadcast packet, along with the in and output ports required for UDP broadcast. Next. We'll take a look at exactly, what you need to do to update the sync response. We've. Added a new field called other device IDs which.

Hints, To the Google, home to, start looking for a device and, we'll, use the information in this field to help duplicate. A device that we find locally to, a device that you told us about via the cloud to cloud integration. Here's. A sample of what that looks like you'll. Notice that this other device IDs field, appears. At the, device level so, you as the developer can, choose which devices, you want to be locally controlled or not. So. Now we're going to jump into the diaper skip app and this is the app that has the business logic that. Can control, your devices, it is. A simple but it's a critical component in this whole process and just a quick reminder we need to handle too intense. Let's. Quickly put these intents in perspective, so. For those who are familiar with the Smart Hub API we, have sync query, and execute, intent that Google, servers sent to your cloud services. For. Local we are adding two new intents, identify. Which. Is fired. By platform, when we've. Scanned a device that belongs to you and second. Is the reachable devices intent which is optional but, required for if we have scanned a bridge or a hub. Let's. Get started with the typescript app but. Before we do that let's, look at the SDK, interface, and. When. This launches, in June you will be able to download a sample and a boilerplate code from github. So. The interface export is, exposed, by the SDK is pretty straightforward. It has two main classes first, the, device manager class the. Device manager class provides, methods to communicate, with your devices and like, Method mentioned earlier it could be TCP UDP or HTTP, HTTPS the. Second is the, app class, this. Provides the methods to attach the intent handlers. So. Let's look at the Taipings for device manager class is. The, send which. Takes in an input for, command, request type object, and returns. A promise which, is resolved, when command, has completed and like. I said earlier it could be HTTP, TCP or UDP. Let's. Look at the typing for the app class, so. For those who are familiar with the actions of Google node library that you use for the cloud site integration, you. Will realize that there. We have on execute. On sync and on query as the handlers you can attach to here. We have unidentified. Unreachable. Devices, and on execute, methods which. You can call to attach, the handlers for your app after. Your app has attached the handlers, we call the listen API, and that's. An indicator to the SDK that the app is now ready to process these intents and notice. That these methods, are chainable, finally. When you are ready to communicate with your device you, will call the get device manager, API to get the singleton, object for device manager, and use, the send API. Let's. Put this interface into perspective by looking at the skeleton of a sample app so. In the sample app I have like identify. Handler and execute Handler and in. The constructor, for this class I create. The instantiation of a local home app get. The device manager object, attached. The two handlers, and call. The listen API. Now. Let's start. Looking at the events that, happen at runtime, and what, your app does to, handle those events. I'm. A visual learner so let's take a look at this in pictures. You've. Already updated, scan config via actions at Google console you've, updated the sync response and now, that information has been set down to a Google home the. Google home starts. A state machine where, we look, for local devices. Then. This process repeats, so whenever, user, plugs in a new device will find that too when. The smart device responds, to one of our scans the, local home platform, generates, an intent called identifying, like Gaurav has been mentioning and we, then call, your apps identify, handler, so.

Let's Look at identify, handler so. Here's the signature of the identify handler the. Input, is a object. Of type identifier, request and we. Expect, a response to. Be a promise, that resolves, to identify, response the. Key information in, identifier, request object is the scan data and this. Depends upon the scan that we'd used to scan for your devices it could be Europe e em DNS UPnP. Identify. Response, the, key information will look from identify, response for, the device that we just found is the. Verification ID, and, this. Must, match, one. Of the other device IDs, that we got from your sync response and. If. We find the match we. Would have established a low but now. There are two other flags, that are also important, is proxy. And is local only and they're, set to false for this device if this. Device was an end device that we wanted to control but. What if we find a hub. Great. Question Gaurav similarly. When we find a hub will, trigger and identify, intent and is. The, field, is proxy, and is local only will, be set to true and that will tell the local home platform, to, then trigger a reachable devices, intent as. The. Name kind of suggests reachable. Devices, intent is supposed to return all the devices that are reachable from this hub, the. Signature. For the handler. Looks very similar to the identifier request the. Key information, to look for in the reachable devices request object, is the, proxy, device this, is your hub that, you told us about in response, for identify. Now. The. Response object we expect, a array, of devices and again, the key information for each one of those device is the, verification ID, and that has, to match one. Of the other device IDs in from your sync response. Like. You know I'm a visual learner so let's take a look at this lovely animation, we. Start establishing the local path with, information, from you via. Scan config via, the actions of Google console and the, updated sync response from your cloud to cloud integration. Once. The Google assistant, receives this information it. Will send it down to all Google home devices a users link to. Once. The Google home receives this information it. Begins looking for devices on the local network. When. A smart device responds, the, Google home generates, and identify, intent, to the appropriate, JavaScript.

The. JavaScript, responds, with a verification ID, and the, local home platform, does some magic to, determine if there's a local path if there, is Google, home we'll update the Google assistant with this optimized, route. Let's. Dive into the details of what that magic is. If. You take a look at the, first step we've updated sync, response and you've told us via. The other device these field that we should start looking for device, locally. Once. We find a device locally, we'll ask you to give us a verification ID via, the JavaScript if, we. Find a match between the verification, ID and any. One of the other device IDs field we'll, call that a deduplicated. Match and we'll tell the, assistant. That that device can go local if not. That's okay we'll, still go to your cloud for integration. Great. So now that local path is available thanks. To the sync response, identifying. Reachable devices. Let's. Make sure when the user says a command, it goes, local. So. User. Says hey G lights on a system, then sends a message to Google home in this case because, we have established the local path right at. That point the, platform, generates. I execute. Intent and the. Execute intent. Handler in your JavaScript, app gets called, the. Key information to look for in the execute request object, is the list of devices that the user wanted to control and. The command and the control that user really wanted could be on/off brightness. Whatever. So. Your app is going to create a command for, each one of those devices or a series, of commands actually and then, use the device manager send, API to communicate, with the device and. For. Your help we have a utility Builder function available that, helps you create the execute, response, and you. Can specify the success, or the failure state, for each one of those devices so. One. Thing to note here is that your, app does, not have direct access to IP address, of the device and we.

Expect. Your app to, use the command request object, to, communicate, with the platform and eventually. To your device and. So like we are showing here again you could use TCP. Or UDP sockets, or HTTP. HTTP, requests. So to recap what, you need to do as a developer. To. Develop your local smart home app that, will run under google home device are these steps you'll. Tell the Google home how to find your device on a user's local network via the actions on Google console you'll. Update the sync response with, a hint to establish this local path and you'll. Write an app that, will handle identify, and execute, intents and optionally. A reachable devices intent. Wait. So. Moving on now that the app is, written. And its. Type script so, let's start right building, and running this app so. Type, step simple, it's at you're, going to use the typescript compiler to. Generate the JavaScript app and the good thing is you can use whichever module system you want and as. Long as the target you choose is supported, by Chrome browser. You're. Good to go because. Remember this, is an app that, conceptually, is running, in a, browser tab. So. Far we've talked about that. A JavaScript, as app is running in the browser but technically, you know it's an HTML page right. So. Look. At the sample HTML, it. Really doesn't do much only. Loads the SDK, and. Your. App and. During. Development you, can actually host, this HTML, page in your local machine or on a hosting, server and. Once you have that URL. Go. Back to actions in Google console and on. Device, testing, page there, is a way there's, an input box for you to enter this URL once. You save this URL, give. 30 minutes for our servers to propagate, this information, and at, that point if you. Reboot, your Google home devices then. You can imagine a, tab. Coming, up and it's, loading, your JavaScript, app and. If. All of that worked moment. Of truth haji. Lights on, did. That work and, did. It go local well. That question brings us to our next section. Testing. And debugging your app can be a little complex because the app is running on, the Google home device but, we've leveraged a few familiar tools, to make it easier. Open. Chrome inspect on a new chrome tab on a machine, that's on the same Wi-Fi, network as the Google home device make. Sure your network doesn't, block packets between devices, on the same Wi-Fi and you.

Should See your app listed, like. This image on the screen behind me click. The inspect, link underneath, your JavaScript, and you, can open up dev tools to remote debug your app but. What, if your app isn't in this list. Because. Your actions on Google console project is not yet in production a few things need to be right before, your code kicks into action let's. Go through that checklist, make. Sure the linked user on the google home device has access, to your actions on Google project. Second. Make, sure your sync response is updated, and contains, at least one other device, IDs field filled, in finally. The scan config and your, app URL should, be correctly entered in the actions on Google console. Now. Let's, assume that all those worked and your app is loading let's, make sure it loads without errors to. Ensure that you can look at the console, section, of the dev tools page, it'll. Look something like this if there is a problem. For. Identify, handler make sure that verification, ID, is correct and it matches one, of the other device IDs field so that we can do the magic to, go local. Next. For the execute, handler make sure that the commands are working either TCP UDP, or HTTP. HTTPS, and, finally. Make, sure that you're. Returning a promise from each of your handlers. So. Now, to ensure the great user experience, it's important, that the, smart of integration, that you just did is complete, and all, the golden queries work so, how, do you do that. Smart. On test suite is your friend when it comes to testing your integration. And we're, going to talk more, about smart, home test suite in detail, in tomorrow's, talk at 9:30, a.m. on stage, five so join us. Finally. Let's, look at quickly. The remainder, of the app lifecycle. So. Your app works smart. Home test suite says it's working all, the tests pass and at. That point it's time to upload your JavaScript, so go back to the console upload. Your JavaScript, hit save. After. You feel ready. You, hit the submit button and that, starts, the certification. Process on. Google's. End to, certify, this new, JavaScript, and the integration, once. Certified your project, launches, to all the users. Once. It's launched, you, can manage your integration, again and actions. On Google console is your window to doing that you, can monitor the ops dashboard, you, can look at the stack driver logging, for all the error logs that are happening in production, on Google, End and, if. You, find issues or errors with your JavaScript, go. Back to the console and again. Upload the version 2 of JavaScript, and, hit. Submit if. You. See that, in production there is a JavaScript, bug and you need to roll back to a working version like v1 of your JavaScript you. Can again work with us through, the console to, kind of help you roll back your. JavaScript. So. We've covered a lot of details about the complete devel. From. Writing, your app to. Launching, your app if you, want to learn more about the tools available and, for, fasters, approval. And submission. Process join. Us at the tools. For creating better smart, home talk. On Thursday. Morning at 9:30 a.m. and now. To know, what's. Next. I'll, invite. Carla. So. We have a busy couple months ahead of us the. Link behind me GTO slash local home SDK, is now, live so, you can go ahead visit. That link to learn more and we'll also be posting updates throughout, the next couple months to that page, in. Just a few weeks we'll, launch the SDK, into developer preview and at, this time you'll be able to build and test your JavaScript, app in the local environment and complete, the self certification program, that Gaurav was talking about and. Although. We don't think it will take you a long time to complete this integration we, wanted to make sure we gave you plenty of time and so, we began launching projects, to production in October. And bringing, this amazing, speed, to, users. We'd. Be remiss if we didn't give a big thank you to some of the partners on the slide behind me for, providing engineering time, and energy, to test out the platform and SDK, to make sure we deliver a rockstar, product, to you in June. So. When, we've talked about going, local, this whole talk, local. Execution is just the tip of the iceberg we, have much much, more in. Mind I want. To briefly talk about two technologies. Were building, that, leverage, local communication. To, improve the device setup experience, and to extend, the assistant, even, further. One. Of the things we've we've, heard from users is that, set, up an account linking of smart devices is hard in fact. It can take upwards of, 10 plus steps for users including. Downloading a new app creating. A new user name and password, setting, up the device taking an OTA, pretending.

To The Google home app or Google assistant, app to link re-entering. Those credentials, it's, it's not easy for users. One, of the other things we heard is that and scenes that users have, a lot of apps on their phone to manage their smart home and for. All use smart home enthusiasts, out there you'll recognize, this phone on this screen behind me that, you need a folder, to actually manage your Markham. So. We took our first step towards solving this device setup problem, with GE Lighting and developing. A seamless, setup experience, that. We delivered, first in the Google smart light starter kit we. Gave users the ability to, natively. Set up C by GE smart, lights in the Google home app without. Needing to download, any additional apps, and, instead. Of this 10 plus step process, we, reduced it to three steps and about. 30 seconds, let's. Take a look and see what it looks like, so. When a google home device discovers, a. C by GE light we. Prompt the user. Would. You like to setup your smart light, then. We go ahead and connect to the bulb and discover services, at, which point then the bulb will begin to blink and this, will let the user know which bulb they're setting up they, click setup and choose which room they want it to go in and give it a name at, this point we're provisioning, the bulb to the local network and registering, it with home graph and in. Just about one second, you'll see that this the smart light is now, set, up and at. Which point it can go ahead and start taking Google, home commands. And, so. 30 seconds is, really incredible for our users and we've. Heard really great feedback so. Far. And. We. Accomplished this by allowing GE to run their code on Google home devices, and yes. As you may have guessed they, also used, the local home SDK. However. To do seamless. Set up there's more intense. Too right than just the identify, and execute we talked about today including. Indicate, provision. On provision, etc, and those are all part of the SDK and, also. This SDK, can. Be used for more than just the Wi-Fi radio as part. Of early access we, allow this SDK to also, leverage, the Bluetooth, radios, for, direct connection. To ble, devices, and, through. This seamless setup experience, with ble devices we. Use the, Google home as a hub, so, you don't need to go out and buy an additional ble. Or Gateway. We're. Growing the seamless setup program now I'm focusing. On ble, devices, in the near term so, if you're interested, let us know by, visiting the link on the screen behind me. Next. I want to talk about existent, connect which, is something that you may have heard about at CES and we've been continuing to invest in since it leverages. The same local home platform, that minute talked about to extend the reach of the Google assistant, which. We call assistant.

Extensions, And we've, classified these into two categories, the. First is input extensions, which, enable a simple method for user to activate, the assistant, to, do everything from simple queries such as what's, the weather to, triggering advanced. Smart home routines, here. We have a simple programmable. Button that, instead of always requiring, users, to say hey, gee they. Can go ahead and just push the button it's, really great for some of those frequent, queries in, addition. We also have output, extensions, that, enable devices, to show assistant, responses, such, as what's the weather or their, schedule, from, their Google Calendar so. This, is currently in early access right, now and throughout, 2019, we're, going we have a really, busy year ahead of us we, have some product, launches coming up later this year so stay tuned and our, teams are finalizing, the reference design and preparing, the assistant connect SDK, for public release later, this year and by 2020, we, expect developers, to have self-service. Access and the ability to even more easily and deeply, integrate, the assistant, into their products. So. To recap. We. Believe that driving, logic from cloud to on device is central, to, our strategy, to create even better experiences. For users and we. Believe that by going local, it we can also invite developers, to integrate more, deeply, with Google the. Secondly. The. Developer experience is key to, building a great smart home ecosystem. Our. Ecosystem. Is only as strong as our developer, community you. All we've. Taken many sape steps to make onboarding, as simple as possible, for example, by, not requiring firmware, updates, to garner, the benefits, of local execution and. We always welcome feedback on how we can further improve so, definitely, let us know and, lastly. A big. Focus for us in 2019. Is reducing, friction and making device setup and linking more seamless, I encourage. You to explore our programs and learn more. So. With that I realize, a 5:30. P.m. talk your for going happy hours so we thank you for coming here today and listening to learn more about local technologies. If. You have any additional questions check out the links on the slide behind me visit, us in the sandbox or swing by our office hours and with, that enjoy the rest of your i/o thank. You.

2019-05-15 12:58

Other news