首先,我正在开发自己的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将其发送到灯具。由于它在某些情况下是网状网络,因此消息必须在到达目标之前从灯到灯进行几次跳跃。根据您拥有的灯数和信号需要多少跳,这可能需要一段时间。此外,某些邮件可能比其他邮件随机占用更长时间。
一般来说,系统不是为处理非常快速的变化而设计的,但是如果你记住上述内容就可以产生很多很酷的效果:)