首先，我正在开发自己的C＃库来控制飞利浦Hue，这意味着我没有使用官方SDK。 （我猜这个SDK会确保你没有任何问题）
我对API中Core concepts页面的限制感到有些困惑，其中指出：
我们不能太快地向灯光发送命令。如果您坚持每秒约10个命令到
/lights资源，那么你应该没问题。对于/groups命令，您应该每秒最多保持1次。
我打算尊重此限制，但是当您在/lights资源上执行GET请求时，该限制是否仍然适用，或者仅用于将带有PUT请求的实际命令发送到/lights/<id>/state更改光的状态？同样的问题适用于/groups资源。
甚至可能通过发送太多请求来损坏任何内容，还是只需要更长时间才能获得所有响应？
修改
我的整体问题是：我应该如何理解API限制？
更具体的子问题是：在发送另一个/lights命令之前，我应该等待100毫秒，相对于我收到响应时，还是相对于我发送上一个命令的时间？
另一个子问题是：我是否应该仅在例如使用PUT请求时才考虑此限制/lights/<id>/state，或所有请求类型GET / PUT / POST / DELETE
答案 0 :(得分：6)
我不知道固件更新是否有任何改变，但我发现桥可能不像您想象的那么简单，并且API描述不是很清楚。
我在运行固件01009914时做了一些测试。
网桥似乎有某种传入命令队列。我将{"bri":254}发送给了一个组9次，最后命令为{"bri":1}。从第一个命令到灯光实际变暗时，大约需要3-4秒。每次我发送命令时，网桥几乎立即用success令牌回复。
我做了相同的小测试，发送其他命令，每个JSON对象10个：
{"bri":254} 3-4秒{"on":true, "bri":254} 6-7秒{"on":true, "bri":254, "alert":"none", "effect":"none"} 12-13秒这实际上表明，每次更改属性大约需要0.3秒才能处理桥。
我将声称对于我们更改的每个属性，桥需要大约300毫秒才能完成，命令的限制应该理解为：只要你坚持每秒更改一个组的一个属性，你应该是细
注意：我只试过一个由三个灯组成的组，我不知道桥是否确实有一个传入命令队列，如果它有一个队列，我不知道其中的物品限制是什么。
修改
现在我们对Hue System Performance进行了一些正式的澄清。
答案 1 :(得分：2)
我非常确定每秒10个命令是防止Bridge故障的指导原则，并且是硬件的技术限制。除此之外，你很容易超载桥梁。我相信这适用于命令和请求。
这两种方法都是合理的。为了懒惰，你可以等待100ms来发送响应，但如果你不打算与Bridge进行任何其他交互，我只会依赖这种方法。
我认为这种限制适用于所有请求类型。
答案 2 :(得分：2)
如果你发送的命令太快，你不会损坏任何东西。但是，如果发送命令的速度过快，则网桥可能会无响应和/或某些消息可能会被忽略。
当谈到桥接器时，我认为它的方式是桥接器或多或少是单线程的，因此如果确保在前一个命令返回之前不发送下一个命令，它最有效。 在实践中，我们发现这比在每个请求之间等待固定时间要好得多。事实上，只要你等待前一个命令完成，你几乎可以发送命令。
当您向桥梁发送命令时，桥梁必须通过Zigbee将其发送到灯具。由于它在某些情况下是网状网络，因此消息必须在到达目标之前从灯到灯进行几次跳跃。根据您拥有的灯数和信号需要多少跳，这可能需要一段时间。此外，某些邮件可能比其他邮件随机占用更长时间。
一般来说，系统不是为处理非常快速的变化而设计的，但是如果你记住上述内容就可以产生很多很酷的效果：）