home-assistant
Research Implementing the Google Smart Home Local Execution API
Context
Google has recently announced their local execution API for their Smart Home Actions. Link This is meant to be running alongside the existing cloud fulfillment method and can potentially speed up the execution of any intents by allowing the device you're talking to to process the request instead of jumping out to the cloud. Request input on if there is interest in implementing this and, if we would like to proceed, if we should wait for Google to fully finalize it. My thought is, it might play in to how they're going to work with Nest devices in the future.
Proposal
Implement the Local Execution API
Consequences
Would allow for faster responses from Google Assistant. Adds complexity to the integration. Would likely need some additional configuration options.. Integration would likely need to support falling back to existing behavior when the local execution isn't configured to avoid major breaking changes. Need to consider the Nabu Casa cloud integration when making these changes.
Risks
Google has not fully finalized this API and it could still change at any time. Might need to delay this work until after it is finalized.
I spend a day at Google and they thought me all about it 😃. I'm working on adding report state, which is a prerequisite before using the local SDK. I have a rough architecture of how to implement the local SDK in my head, will publish more details soon.
Local SDK should launch soon. I'm, as usual, a bit behind 🙈
FYI, Google's "Local Home SDK" with local fulfilment is now finally live for everyone as of April 7th 2020
- https://developers.google.com/assistant/smarthome/concepts/local
"The SDK lets you write a local fulfillment app, using TypeScript or JavaScript, that contains your smart home business logic. Google Home or Google Nest devices can load and run your app on-device. Your app communicates directly with your existing smart devices over Wi-Fi on a local area network (LAN) to fulfill user commands, over existing protocols. Integration of the SDK offers performance improvements to your smart home Action, including lower latency and higher reliability. Local fulfilment is supported for all device types and device traits, except those that use two-factor authentication."
- https://github.com/actions-on-google/local-home-sdk/blob/master/CHANGELOG.md
Again, Google explained in their initial announcements they detailed how the local control should work, by first discovering nearby devices on the same network and then using them as the execution path (instead of the device's developer cloud) when users issue a command.
- https://developers.googleblog.com/2019/07/developer-preview-of-local-home-sdk.html
- https://developers.googleblog.com/2019/05/Actions-on-Google-at-IO-2019.html
Be sure to first check out the Local Technologies for the Smart Home talk from Google I/O 2019:
- https://www.youtube.com/watch?v=Y6Ue5hQ9meM&feature=youtu.be
Interested check out the API reference, developer guide, and samples.
- https://developers.google.com/actions/smarthome/reference/local/
- https://developers.google.com/actions/smarthome/concepts/local/
- https://github.com/actions-on-google/smart-home-local
They now also offer a test suite self-certification of Smart Home Actions
- https://developers.google.com/assistant/smarthome/tools/smart-home-test-suite
For reference, I read this news on Android Police site:
- https://www.androidpolice.com/2020/04/07/googles-speakers-and-displays-add-local-control-of-smart-home-devices-starting-with-hue-tp-link-more/
"With the new Local Home SDK, devs can make use of the Google Home speakers' and Nest Displays' built-in radios (Bluetooth and WiFi, possibly also Thread where applicable) to communicate directly with their devices. So when you ask Assistant to control your LIFX lights for example, it doesn't talk to the LIFX cloud which then communicates back to the light, but instead the command is directly relayed from the speaker/display to the light. This speeds things up and makes them more reliable. (It could also possibly bring offline controls when your network is down.). Other hubs like SmartThings and Wink have had this for years, so it's exciting to see Google add it, even if the functionality seems to be limited — at least at first — to first-party speakers and displays. Google says it's been working with Philips, GE, WeMo, LIFX, and TP-Link on this SDK, and will open it to all developers starting next month."
Google did take a bit more than the promised to release this for all but better late than never, or?
This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.
For that reason, I'm going to close this issue.
../Frenck
