飞利浦Hue命令限制

时间:2014-02-28 17:14:26

标签: api philips-hue

首先,我正在开发自己的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

3 个答案:

答案 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将其发送到灯具。由于它在某些情况下是网状网络,因此消息必须在到达目标之前从灯到灯进行几次跳跃。根据您拥有的灯数和信号需要多少跳,这可能需要一段时间。此外,某些邮件可能比其他邮件随机占用更长时间。

一般来说,系统不是为处理非常快速的变化而设计的,但是如果你记住上述内容就可以产生很多很酷的效果:)