飞利浦 Hue 命令限制答案

【问题标题】：Philips Hue command limitation飞利浦 Hue 命令限制
【发布时间】：2014-02-28 17:14:26
【问题描述】：

首先，我正在开发自己的 C# 库来控制 Philips Hue，这意味着我没有使用官方 SDK。（我猜SDK会确保你不会有任何问题）

我对 API 中 Core concepts 页面的限制有点困惑，其中指出：

我们不能太快地向灯发送命令。如果您坚持每秒对/lights 资源执行大约 10 个命令，那么您应该没问题。对于/groups 命令，您应该保持每秒最多 1 个。

我打算遵守此限制，但是当您对 /lights 资源执行 GET 请求时，该限制是否仍然适用，或者仅用于向 /lights/<id>/state 发送带有 PUT 请求的实际命令以更改光？ /groups 资源也有同样的问题。

还有可能通过发送太多请求来损坏任何东西，还是需要更长的时间才能获得所有响应？

编辑：

我的总体问题是：我应该如何理解 API 限制？

一个更具体的子问题是：我应该在发送另一个/lights 命令之前等待 100 毫秒，相对于我收到响应的时间，还是相对于我发送上一个命令的时间？

另一个子问题是：我是否应该仅在使用 PUT 请求时才考虑此限制，例如/lights/<id>/state，或在所有请求类型 GET/PUT/POST/DELETE 上

【问题讨论】：

【解决方案1】：

我不知道固件更新是否有任何变化，但我发现桥接器可能不像你想象的那么简单，API 描述也不是很清楚。我在运行固件01009914时做了一些测试。

网桥似乎有某种传入命令队列。我向一个组发送了 9 次 {"bri":254} 和 {"bri":1} 的 1 个最终命令。从第一个命令到灯光真正变暗，大约需要 3-4 秒。每次我发送命令时，桥都会立即回复success 令牌。

我做了同样的小测试，发送其他命令，每个 JSON 对象 10 个：

这实际上表明，每次属性更改大约需要 0.3 秒才能让网桥处理。

我会声称，对于我们每更改一个属性，桥接完成大约需要 300 毫秒，命令的限制应该理解为：只要你坚持每秒更改一个组的一个属性，你应该很好。

注意：我只尝试了一组由三个灯组成的组，我不知道网桥是否真的有一个传入命令队列，如果它确实有一个队列，我不知道里面的物品限制是多少。

编辑：

现在我们对Hue System Performance进行了一些官方澄清。

【讨论】：

【解决方案2】：

我相当肯定每秒 10 条命令是防止 Bridge 发生故障的指导方针，并且是硬件的技术限制。不仅如此，您很容易使桥梁超载。我相信这适用于命令和请求。

这两种方法都是合理的。为了懒惰，您可以等待 100 毫秒来发送响应，但如果您不打算与 Bridge 进行任何其他交互，我只会依赖此方法。

我认为这种限制适用于所有请求类型。

【讨论】：

这也可能是一个法律限制。 Philips Hue 使用 ZigBee Light Link 作为其射频技术。虽然 Light Link 使用 2.4GHz 的频率，但其他 ZigBee 模块也使用 868 MHz 和 915 MHz。在德国，在 868 MHz 频率上发送仅限于 1% 的时间（或使用“先听后说”），请参阅 the fhem wiki（德语，translated）。

【解决方案3】：

如果你发送命令太快，你不会损坏任何东西。但是，如果您发送命令的速度过快，网桥可能会变得无响应和/或某些消息可能会被忽略。

说到网桥，我的想法是网桥或多或少是单线程的，所以如果你确保在前一个命令返回之前不发送下一个命令，效果最好。在实践中，我们发现这比在每个请求之间等待固定时间要好得多。事实上，只要等待前一个命令完成，您几乎可以随心所欲地发送命令。

当您向桥接器发送命令时，桥接器必须通过 Zigbee 将其发送到灯。由于在某些情况下它是一个网状网络，因此消息在到达目标之前必须从灯到灯进行几次跳跃。根据您拥有的灯数量和信号需要跳多少次，这可能需要一段时间。此外，某些消息可能会随机花费比其他消息更长的时间。

一般来说，系统的设计目的不是为了处理非常快速的变化，但如果你牢记以上几点，你可以做出很多很酷的效果:)

【讨论】：