这样，小米蓝牙网关TTL口消息触发的部分自动化时延可缩短起码1秒

XCray

因其他事情想起来翻看原来调试mqttl代码时记录的比较完整的TTL消息记录，发现每一行是对我们有价值的信息（_async.ble_event），在其前面约1秒，都有一条对应的事件报告发送记录，eid、mac、edata长度（elen）都是匹配的。

10:51:26.428 [M: miio C: warning F: mible_gateWay_evtRptToServer L: 525]: [scan_server], send rpt. eid:5, elen:10, mac:xxxxxxxxxxxx
10:51:27.429 [M: miio C: info F: mum_send_common_data L: 1021]: up:{"retry":0,"method":"_async.ble_event","params":{"dev":{"did":"1010010815","mac":"xxxxxxxxxxxx","pdid":407},"evt":[{"eid":5,"edata":"000200000100db8ec85e"}],"frmCnt":113,"gwts":481}}

意思很明显，第一条warning说向服务器发送了事件报告，后面一条info应该就是收到服务器返回的消息之后的提示（mum_send_command_data——妈妈发出的指令数据？）
这个现象，似乎说明了这款蓝牙网关并不会对蓝牙消息进行解密、只是简单的转发给服务器，服务器解密后再告诉蓝牙网关——而蓝牙网关根本不关心。

这1秒的延迟还是在网络状况很好的时候记录的最小时延。网络不好或服务器不稳定时，这一延迟能到十秒左右，甚至干脆丢失。
那么这个有什么用呢？——可以缩短蓝牙设备触发的某些自动化的时延、基本达到本地化的效果（0时延）。

对于不依赖于edata数据、非敏感型（解除警戒状态）的自动化，比如进门开灯之类的，可以改用第一条消息触发，这样，至少可以缩短1秒的时延，在小米服务器或网络状况不佳时，也可以避免更长的时延。

ghostist

嗯哼 我这个伸手党等着编译好的固件嘞
上次请教你 尝试自己编译重连wifi的版本，前后折腾了快一周吧  环境也部署了  代码也改了  编译就是报错，各种报错....
解决了好几轮缺少的依赖....最后被折麽到不想搞了...文件夹现在还在我桌面上嘞

XCray

ghostist 发表于 2021-5-31 08:51
嗯哼 我这个伸手党等着编译好的固件嘞
上次请教你 尝试自己编译重连wifi的版本，前后折腾了快一周吧  环境 ...

别等了，我已经改用n大打通的ESPHome这条道路了，没必要再发布编译后的固件。
改起来很简单：在消息处理那个handle_()函数的开头加了这么几句：

    //监测门锁的开锁消息
    if(strstr(data, "eid:5, elen:10, mac:ed:xxxxxxxxx")){
      ESP_LOGD(TAG, "eid5elen10lock");
      publish("mqttl/eid5elen10lock", data);
    }

复制代码

除了mac，别忘了修改eid，最好是从ttl原始消息里复制，避免多个空格少个空格之类的。

然后在自动化里用对应主题的mqtt消息触发：

  trigger:
  - platform: mqtt
    topic: mqttl/eid5elen10lock

复制代码

当然，主题你可以随便改，两头匹配即可。

完整的代码可以到我原来那个帖子的最前面去找：
(多个)蓝牙网关 TTL->MQTT，支持任意米家蓝牙设备接入HA/NR - 『HomeAssistant』综合讨论区 - 『瀚思彼岸』» 智能家居技术论坛 - Powered by Discuz! (hassbian.com)

ghostist

XCray 发表于 2021-5-31 11:36
别等了，我已经改用n大打通的ESPHome这条道路了，没必要再发布编译后的固件。
改起来很简单：在消息处理那 ...

哦吼 没注意
我先迁移到esphome下
话说我之前一直用的挺稳定，除了断电不重连mqtt
延迟基本在2s内