api - 飞利浦 Hue 命令限制

Question

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

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

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

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

编辑：

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

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

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

score 6 · Accepted Answer

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

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

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

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

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

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

编辑：

现在我们对Hue System Performance有了一些官方说明。

score 2 · Accepted Answer

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

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

我认为对所有请求类型都有这种限制。

score 2 · Accepted Answer

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

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

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

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

3 回答 3