我正在努力寻找如何让google home进行本地网络休息呼叫。
我有一些ESP8266与mDNS和其他api在一起。 现在有了google home，我希望它能够向设备发送一个休息呼叫。
我不想要任何像IFTTT这样的网络钩子/服务。我不希望通过这些第三方服务进行沟通。
它应该像这样google home得到输入（谷歌服务了解是oke）。它检索动作（本地网络，与身体的url休息调用）。 Google Home会将其余的api调用发送到本地设备。
无需更改端口转发/防火墙。
答案 0 :(得分：2)
Google Home对设备上的处理工作非常少。发送本地网络呼叫不是它所做的事情之一。几乎所有处理（包括通过智能家居API的物联网控制）都是通过基于云的服务完成的。
<强>更新
我无法回答“为什么”它没有这样做，因为我不是建造它的工程师之一，但我可以对其进行大量猜测。
对于初学者来说 - 它会大大增加设备上软件和硬件的复杂性。现在，该设备实际上只是一个麦克风和一个扬声器，有一点逻辑来检测热门词然后将其他所有内容传输到服务器，然后得到一个结果并播放它。其余大部分代码都可能处理设置和配置。
如果设备也必须是通用物联网集线器，那么它需要用于蓝牙和其他信令系统的软件和硬件。它需要能够跟踪网络上其他设备的状态，并在设备的电源周期之间进行管理（甚至可以处理设备本身的电源中断）。这可能需要打开设备上的网络以接收消息，而不仅仅是发送它们。它必须具有更广泛的网络配置 - 了解本地网络是什么，而不仅仅是本地路由器是什么以及如何处理该配置（以及更改时的配置）。可以肯定的是，这些都是可能的，但会增加复杂性，在某些情况下会降低设备的安全性。
这可能是合理的......如果这样做有很大的价值。但是你已经在问题中规定语音处理可以在云中完成，所以一旦将命令发送到云并在那里进行解析 - 为什么不进行上述所有操作（设备和状态跟踪，更改等）在云端？特别是因为大多数物联网设备无论如何都要维护云服务器，因为当人们在家庭局域网上不时，人们也希望能够控制或监控他们的家庭设备。拥有一套双重命令（有些用于本地时，有些则用于本地时，有些则在某些情况下确实有意义 - 但也会大大增加控制器和设备的复杂性，因此大多数只依赖于云再一次。
因此，虽然我理解为什么有些人希望有一个漂亮的小系统，它可以偶尔向你的本地REST服务器发送一个命令，但实际情况是为消费者系统做这个并不合理。
如果您真的想要一个可以做到这一点的系统 - 您可以继续保持业余爱好，并使用Assistant SDK和您最喜爱的物联网平台构建一些东西。
答案 1 :(得分：0)
用于Google Home的“本地” API有所限制。这是对API进行反向工程的人的文档。
看起来它们暴露了蓝牙和警报/计时器以及一些有限的配置内容。