关于时效性的小实验-记录和分析：米系蓝牙、本地vs云端

XCray

“指纹开锁->解除警戒+打开玄关灯”的自动化用了很久了，经常出现时效性不满意的现象。决定优化细究。

米家和HA分别设置自动化，执行同样的任务，即“指纹开锁->解除警戒+打开玄关灯”。为了准确判断，用zigbee插座担负玄关灯的角色，一方检测到zigbee插座已开就认为对方已经执行。HA侧负责计数（能者多劳）。
选择zigbee插座的根本原因就是只有它能做到状态更新接近于实时。

自动化设置：

- 米家，执行方式为云端：
   - 触发：指纹开锁（事件经蓝牙网关发送至云端）
   - 条件：zigbee插座处于关闭状态
   - 动作：开zigbee插座、解除警戒、小爱播放欢迎辞、倒计时3分钟关闭zigbee插座
- HA，纯本地执行：
   - 触发：指纹开锁（esp32本地解码）
   - 动作：
       - 如果zigbee插座已开，则认为米家已经执行，把“米家更快”计数器加1
       - 如果zigbee插座未开，执行“开zigbee插座、解除警戒、HA更快计数器加1、倒计时3分钟关闭zigbee插座”序列

实际观测，发现偶尔有两侧都执行的情况，也就是说都没有看到对方先打开zigbee插座的动作，倒也可以理解，毕竟什么动作都需要时间。
于是HA另外安排一条自动化，专门记录两侧都执行的情况、修正计数器：
  - 触发：小米场景执行记录“正常指纹开锁”（来自于Miot Auto集成，感谢al-one大佬）。
  - 条件：“ha更快”计数器在20秒内更新过
  - 动作：“ha更快”计数器减1、“无法分辨”计数器加1

十多天的记录：

结论和分析：
1. HA更快47次、米家更快4次、无法分辨3次；90%的情况下，HA本地执行更快；
2. esp32由于WiFi和蓝牙共用天线，而且不知道门锁广播的时间参数，不可避免的会出现丢失最初的消息的现象，从而造成虽然是本地执行但仍会慢于米家的情况。改用以太网连接、全时侦听应该会好很多；
3. 米家虽然是云端执行，但是在网络不那么繁忙的时候，时效性还是可以的。

未完待续：

- 修改版HA内置组件xiaomi_ble刚通过测试，还没有参加比拼，下一步安排。以太网、本地蓝牙、处理器性能过剩，估计会比esp32好不少。

- 没有中枢网关，不知道中枢网关的本地化能否在这一点上和HA相比。

xieahui

做个记号 等待结果！！

bugensui

有的时候相差0.5秒，体验都有质的飞跃，就比如放在厨房的电池版人体传感器，和插电板人体存在，普通的人体总感觉慢半拍，不够爽

wpw72

为楼主一丝不苟的钻研精神点赞

stkroot

既然有“同时”的情况，说明HA计数肯定也存在延迟。可以认为数据有误差，只能作为参考。

可以试试搞个多色灯，米家和HA分别控制灯到不同颜色，最后灯是保持哪个颜色，就说明那边执行更慢。

XCray

stkroot 发表于 2024-6-4 15:04
既然有“同时”的情况，说明HA计数肯定也存在延迟。可以认为数据有误差，只能作为参考。

可以试试搞个多色 ...

看来我在主贴里写的没能让你看明白，汗。

通过抢先开启zigbee插座、判断zigbee插座状态、如果米家自动化执行了app能看到且HA里也能看到而且小爱音箱会播报、HA自动化执行情况系统里会有记录这几点，已经足够准确判断了。

“同时”的情况，不是HA计数存在延迟，事实上这个计数延迟也不影响什么。延迟的本质是门锁发出蓝牙广播、esp32解码上报给HA、蓝牙网关解码上报给米家云端、HA/云端服务器决策发出指令、zigbee网关收到指令转发给zigbee插座、HA/云端服务器更新zigbee插座状态等这些环节都需要时间。

另外因为这款门锁的广播使用的manufacturer data，需要esp32/蓝牙网关/ha内置xiaomi_ble组件在收到ADV_SCAN_IND后分别向其发送SCAN_REQ、然后各自接收门锁回复的SCAN_RSP，这才能获取到开锁事件数据。显然，这里也存在争抢和不可预知性。

stkroot

我看懂了啊，但你文章里说了

实际观测，发现偶尔有两侧都执行的情况，也就是说都没有看到对方先打开zigbee插座的动作

这种情况，就说明"zigbee插座"状态读取有延时。
也就是HA计数+1时，可能米家的已经执行了，只是没被HA及时发现

XCray

stkroot 发表于 2024-6-4 19:57
我看懂了啊，但你文章里说了

是的，不管是HA还是米家，获取到zigbee状态更新肯定都会有延迟。

也有可能是HA已经执行了、米家没有及时发现。所以后面那个自动化针对这种情况，计数的同时，修正“HA更快”计数器

stkroot

所以，我觉得比快不如比慢。

在读取有延迟的情况下，快不一定真快，慢一定是真慢

stkroot

多色灯，两边同时改变灯的颜色，最后灯保持哪个颜色，哪个就肯定后执行