这个部件是通过轮询来更新状态的吗？

[itispip]

和AlexxIT 的MiGateWay3部件，以及ha0y的Miot_raw部件相比较，这个部件视乎状态更新的延迟是最明显的。是因为这个部件是通过定时云端轮询的原因吗？

[al-one]

xiaomi_gateway3插件应该是拦截了多模网关里面的所有事件并解析，从而实现实时响应状态，对于蓝牙、Zigbee设备，xiaomi_gateway3插件配合多模网关无疑是最优的解决方案。

至于xiaomi_miot_raw，应该和本插件一样，都是采用轮询的方式获取数据。只是轮询的机制或轮询间隔可能不一样。另外本插件可能为了获取更多的状态属性，会调用不同的小米接口来获取设备状态。

如果你的设备在用本插件更新状态时有明显延迟，可以具体描述下延迟情况，我会很乐意优化这些问题。

[itispip]

谢谢解释。总体而言这个部件已经很优秀了，比xiaomi_gateway3慢是可以理解的。可能速度比同样轮询的miot_raw慢一点，但是用户友好性和提供的属性丰富性比那个好很多。

目前碰到的延迟只要是(1)蓝牙灯光，在灯已经相应打开或者关闭指令以后，UI的Switch状态有可能和灯的实际状态不符合。这个不符合的时间长短不定，应该是轮询的时间间隔的原因吧； (2) Gateway3的Alarm Panel， Alarm状态和网关实际的状态有比较明显的延迟，这个对于自动化的影响比较明显。

[itispip]

另外报告一个bug：这个部件对小米门磁的状态解析是相反的。关闭状态识别成打开，打开识别成关闭。

[al-one]

(1)蓝牙灯光，在灯已经相应打开或者关闭指令以后，UI的Switch状态有可能和灯的实际状态不符合。这个不符合的时间长短不定，应该是轮询的时间间隔的原因吧；

如果是通过米家APP、小爱同学或实体按键控制的灯，那么在HA中设备状态会等到下一次轮询才会更新，这种情况是正常的。具体可以查看 #100 (comment) ，也可以参考里面的方法缩短轮询间隔。但如果是通过本插件在HA中控制的设备，但是控制后状态与设备实际状态不一致，那确实有问题，需要仔细再查查。

---

(2) Gateway3的Alarm Panel， Alarm状态和网关实际的状态有比较明显的延迟，这个对于自动化的影响比较明显。

这个延迟和上面差不多，Alarm状态是由设备主动变化的，一样可以通过自定义属性interval_seconds来缩小轮询间隔，不过更推荐用xiaomi_gateway3插件。

---

这个部件对小米门磁的状态解析是相反的。关闭状态识别成打开，打开识别成关闭。

这个Bug已经在v0.4.12版本中修复了，更新后即可解决。

[itispip]

如果是通过本插件在HA中控制的设备，但是控制后状态与设备实际状态不一致，那确实有问题，需要仔细再查查。

反复测试，通过本插件在HA里控制设备，例如主网关的警报，点击"在家警戒“后小米网关立刻反应，进入警戒状态，但是HA界面需要等待8-10秒，HA的界面才会进入警戒。反之，解除警戒也是一样的10秒左右的延迟。

在AlexxIT的MiGateway3里面控制警戒状态，也同样存在延迟。似乎至少在警戒控制这一块，他也没有本地拦截和解析消息。我去了解了下，他的警戒控制这一块的代码，实际上是由xiaomi_miot_raw这个部件的作者commit的，估计也同样是云端读取状态。

[itispip]

这个Bug已经在v0.4.12版本中修复了，更新后即可解决

我已经是0.4.12版本了，但是状态似乎任然没有修复

[al-one]

反复测试，通过本插件在HA里控制设备，例如主网关的警报，点击"在家警戒“后小米网关立刻反应，进入警戒状态，但是HA界面需要等待8-10秒，HA的界面才会进入警戒。反之，解除警戒也是一样的10秒左右的延迟。

该问题已在 dbd01f4 中修复，请更新到master分支后再试。

---

我已经是0.4.12版本了，但是状态似乎任然没有修复

如果是绿米的门磁，也同样需要更新到master分支。 #299 #300