利用智能音箱实现智能家居的控制现在已经逐渐被大家接纳，现如今家庭中的智能设备也越来越多，看样子人手一套小罗伯特唐尼贾维斯系统似乎指日可待？答案是：想得美！但是各大科技企业正在往这个最终奥义上逐渐逼近，对于智能音箱和智能家居的控制上来说，撇开内容的优质程度，作为消费者最需要的就是速度. 在对智能音箱发出指令后，智能物联网设备延迟的那几秒往往会带给强迫症患者心如刀绞的感觉。所以为了广大群众的舒适度，大部分的科技公司都在极力为智能控制本地化做努力。本文会对于谷歌即将推出的本地解决话方案“Local Home SDK“做尽可能详细的解释。
Local Home SDK如何实现设备端的智能家居控制
最普遍的云端IoT控制Workflow
当用户向内置语音助手的智能设备发出指令：Hey Google, turn on the lights. 语音指令将以波束的形式发送到Google Assistant的服务器上，来做语音识别和语义分析，也就是我们所谓的人工智能部分， 最终得到用户想要将某一盏灯改变成某一种状态（明暗，色彩）的结论. 在这之后，Google Assistant会将分析得到的明确指令以一种结构化的数据形式（JSON）发送到这盏灯品牌自有的云服务上，这个云服务把非常容易理解的Google Assistant的结构化数据指令进行转换，翻译成自己云服务本身对自家智能设备做控制的数据指令形式，最终通过自家的云给设备发出更改状态的指令.
做个总结， 设备接受指令，由谷歌语音助手后台做语义分析，交给需要被控制设备的云，通过Wi-Fi进行控制.
目前方案面临的问题
一般我们的智能音箱和智能灯泡或是其他的家用智能设备都共处在同一个屋檐下，每一次由智能音箱实行的控制都要绕一个三段的大弯（音箱谷歌云设备云设备）， 假设最终需要被控制的设备本身的服务在英国，而我们在中国，所以数据得从中国跑到美国谷歌的服务器上，再溜到英国的服务器最后回到中国. 在这样的智能控制的过程中势必会产生一定的延迟, 并且长途跋涉往往会伴随着一些数据丢失. 就本人个人体验来看，好些的谷歌亚马逊的智能音箱，一般都能在2秒以内被唤醒，并且在4秒以内将命令执行完毕. 那么差一些的，等睡到天亮了昨晚关灯的指令才刚被执行完毕. 所以在智能家居的控制上能将更多的内容转换到本地上来，通过音箱与设备的直接交流来提升提出请求并且执行请求是谷歌在我们完全本地化的最终目标上做出的一个很好的尝试.
Local Home SDK
和我们最常用的模式一样，在Google Assistant和要被控制的设备云服务沟通之前，依然要通过Google Assistant的服务器做语音识别和语义分析，当这一步完成后，不一样的是Google Assistant如果知道有哪些设备是可以被本地控制的，那么Google Assistant会将结构化的JSON指令发送到智能音箱上去，然后音箱会启动包含了相应服务的智能家居控制逻辑的JavaScript文件来处理接收到的JSON指令，最终通过本地局域网的Wi-Fi来实现音箱和设备之间的交流. 这样做就省去了从谷歌服务器辗转第三方云服务器，再由第三方云服务器辗转至设备的这个流程，从而很大程度上减小了云与云之间来回跑产生的延迟于数据丢失的风险.
Local Home SDK 目前支持所有原来Smart Home SDK所支持的Device types（智能灯，智能电扇 等）和Device traits（Device type普遍通有的功能. 对于智能灯来说：开关，亮度调节等）. 目前所有的谷歌音箱以及带屏音箱都可以支持以及运行相应的JavaScript app.
这里提一下，谷歌对于智能家居有一套自己的框架叫做Home Graph，也就是在你连接家里的智能设备过程中，需要依据谷歌的框架来设定设备的名称以及所在的房间. 那么当我们需要激活某个设备的时候，使用“打开某某房间的某某设备”的最贴近我们人类习惯的指令会达到更好的效果.
技术框架
Local Home SDK和Local Home Platform是连接智能家居App和用来与智能设备通信的低等级无线传输的接口，Local Home SDK主要从事两个任务，一个是与Google Assistant交互，第二就是为套接字通信提供受控访问.
开发者/开发商需要在Action on Google的控制台上提供如何利用本地局域网找到要被控制的智能设备的方式，通过哪种通讯协议在局域网搜索设备（常见的通讯协议：UDP / UPnP /mDNS）.当通过设定的方式搜索到设备后会发送一个hint到Google Assistant云端，和曾经云对云之间交互模式下所保存的设备清单做对比，开发者需要update一个SYNC response来确认搜索到的设备是不是云上曾经记录过的设备，经过确认以后Google Assistant会在固定的时间或是重启时，把这个信息发送到所以已经连接的谷歌智能家居设备里去并且封存起来. 那么之后当我们再向智能音响设备发出语音指令后，并且传输到Google Assistant后，不会像以往一样再去连接第三方的云，而是直接将指令发送到智能音箱上，经过音箱中的JavaScript app来处理输入进来的指令，确定你的意图。这和曾经的云对的交互差不多，将谷歌分析出来的意图指令转换为要控制的设备商所用的意图指令，最后通过应用程序层协议（HTTPS/TCP/UDP sockets）来和需要被控制的设备进行沟通.
**
所以总结一下，开发者先设定好搜索的方式，搜索并且得到反馈，比对反馈和曾经云上的设备信息是不是这个云认识的设备，对应之后将同步信息发送到智能音箱并且给搜索到的设备打上标签，之后智能音箱与设备直接联系. 以后发送命令后，通过云了解设备是否可以被本地控制，如果可以就交给本地的JavaScript app，如果不可以便依然走云对云的交互模式.**
开发商所需要做的事
- 设置通过哪些参数如何搜索设备，谷歌将会开放新的UI来简化这个过程
- 同步SYNC response
- 编写你的JavaScript app，确定如何理解指令意图，通过hub设备发送指令以及最终执行的逻辑
谷歌仍需要一段时间，对现有的方案做验证并且完善文档，最终向广大开发者开放.
