米家蓝牙器件接入HA的较佳方案：蓝牙网关+TTL+MQTT，ex榉树锁

crazysiri

XCray 发表于 2020-6-7 22:30
我理解（猜测），网关没区别，只是蓝牙终端设备（比如门锁）每种型号上报的消息数量和格式不一样。
~~~~~ ...

所以大概率就是我的锁上报的信息少…我跟了一段时间我这就能检测到开锁和电量，也不知道是门外还是门内

余歌唱晚

准备买小白万能遥控器了

XCray

crazysiri 发表于 2020-6-7 22:38
所以大概率就是我的锁上报的信息少…我跟了一段时间我这就能检测到开锁和电量，也不知道是门外还是门内 ...

也不一定。

按说米家的锁，消息上报应该是最完整的。不妨把你跟的结果整理一下发出来。

门外还是门内，蓝牙还是密码，开门者到底何人，是在edata当中区分的，事件eid都是一个

XCray

余歌唱晚 发表于 2020-6-7 23:34
准备买小白万能遥控器了

我用榉树网关+榉树锁，消息确实很少，只有3种：

- 每分钟一次的状态报告
- 开锁事件
- 每天一次的电量报告

不知道是不是网关并没有把全部的有用消息都在TTL输出？如果能用同一把锁配合不同网关做个对比分析就好了。

XCray

增加了“蓝牙温湿度计2”，就是方方的那个：

            elif db_pdid == 1371: #蓝牙温湿度计2
                  topic = "mqtttmhm/%s/%s"%(db_did,db_eid)
                  payload = int(revstr(db_edata),16)
                  if db_eid == 4100 or db_eid ==4102:
                       payload = payload / 10
                  elif db_eid != 4106:
                       syslog.syslog('蓝牙温湿度未知eid：%s' % respon)

复制代码

这个蓝牙温湿度传感器，只有3条消息：
- 4100——温度，量纲0.1度
- 4102——湿度，量纲0.1%
- 4106——电量，量纲1%

相应地，hass中yaml配置：

sensor:
  - platform: mqtt
    name: btTemp
    icon: 'mdi:thermometer'
    state_topic: 'mqtttmhm/xxxxxx/4100'
    device_class: temperature
    unit_of_measurement: °C
  - platform: mqtt
    name: btHumi
    icon: 'mdi:water-percent'
    state_topic: 'mqtttmhm/xxxxxx/4102'
    device_class: humidity
    unit_of_measurement: '%'
  - platform: mqtt
    name: btBatt
    icon: 'mdi:battery-charging'
    state_topic: 'mqtttmhm/xxxxxx/4106'
homeassistant:
  customize:
    sensor.btTemp:
      friendly_name: 蓝牙温度
    sensor.btHumi:
      friendly_name: 蓝牙湿度
    sensor.btBatt:
      friendly_name: 蓝牙电量

复制代码

把xxxxxx替换成你自己的传感器pdid即可。

XCray

telanx 发表于 2020-5-28 00:11
米家蓝牙温湿度计，圆的那个，大佬研究下啊。谢谢！

刚顺便买了个米家蓝牙温湿度计2，方的那个。

消息符合标准定义，很容易就加进来了。

圆的估计也差不多，可能pdid产品代码会不一样，稍微修改一下程序应该就可以了。

XCray

观测到一个就连榉树官方都没有用到的、而且比较有用的消息：eid：7——门事件。

在米家app里，榉树门锁可以触发自动化的条件有：电量低于10%/5%、任意（正常）开锁、指定钥匙开锁、门锁面板被撬、错误密码频繁尝试导致键盘被锁这几个。

其对应的TTL接口的消息，推测：
- 电量对应电量报告，每天一次。也许电量低的时候会更频繁。
- 任意（正常）开锁、指定钥匙开锁，确信对应之前的锁事件（就是小米说的已废弃的eid=5）。因为没有观察到其他消息。
- 错误密码频繁尝试导致键盘被锁，很可能也是对应锁事件，用特殊的KeyID来表示，还没有观察到。
- 门锁面板被撬，可能对应这里的门事件。

按照小米文档，门事件eid为7，数据1个字节，取值00~05，分别表示：开门、关门、超时未关、敲门、撬门、门卡住。

我这次观察到的，是“02 超时未关”，当时确实有20多秒的时间没有关门。

敲门肯定不会有了，因为就没有对应的传感器。

撬门可能对应于上面说的门锁面板被撬，无法验证。

门卡住？更不知道了。

就这个“02 超时未关”，很显然榉树官方都没到（开头说的，自动化触发条件没有这个）。而强大的HA，当然可以把它用起来，超过20来秒不关门，放个狗叫声啥的提醒一下~~~

对了，门磁传感器也有类似的能力，但那个时长是1分钟，似乎长了点。

代码很简单：

elif db_eid == 7: #门事件
    timest = revstr(db_edata[2:10])
    timest = time.strftime("%Y-%m-%d",time.localtime(int(timest,16)))
    payload = '{"Status":%d,"UpdTime":"%s"}'%(int(db_edata[0:2],16),timest)
    topic = "mqttlock/door"
    syslog.syslog('发生门事件：%s' % respon)

复制代码

最后一行做个记录，也许还会有其他的消息呢。

XCray

到现在这个脚本跑了两个星期了，期间也逐步得到优化完善。

值得一说的是，观察到丢数据的现象。

整条丢数据的现象倒是没发现过（我专门分析过接收到门锁状态报告的时间间隔，很规律，一分钟多点一次，如果有数据丢失，这儿应该能看出来），只是偶尔发现丢字符的现象，有时候丢个“]”，有时候丢个数字，大概5天出现一次（两个星期，发生了3次）。

丢“]”那次，导致json解析失败；丢数字的两次，一次导致不知道啥设备，一次导致数值错误，不过这几次都是发生在花花草草上，也许是传感器上报的数据就有问题，也许是因为我用杜邦线连接不够稳定？
两天后，又发生了一次丢字符现象，这次是结尾丢了一个大括号‘{’，导致json解析错误。差不多隔了两个小时，还有一次错误消息，说是'utf-8' codec can't decode byte 0xea in position 65: invalid continuation byte。这两次错误，一个是另一个花花草草，一个是门锁的状态报告。

因为每次丢失字符或者接收误码都不一样、数量也不算多，暂时不做处理。如果以后发现规律再从代码上进行弥补吧。

现在还不好判断丢字符或误码到底是发生在哪个环节，传感器、蓝牙干扰、TTL连线、串口芯片？都有可能

余歌唱晚

XCray 发表于 2020-6-8 06:18
我用榉树网关+榉树锁，消息确实很少，只有3种：

- 每分钟一次的状态报告

感觉也够了

XCray

余歌唱晚 发表于 2020-6-11 16:47
感觉也够了

嗯，怎么说呢？

满足基本要求没问题了，最关键的开锁事件有就解决了最急迫的需求。

而且每分钟一次的状态报告显得还啰嗦、多余，我更倾向于基于事件的报告而不是这种频繁的周期性报告。

电量报告每天一次，也够用了。

门事件算是锦上添花，可以省去一个门磁传感器。

比较欠缺的，是传感器比较少、开锁事件太简单、附加信息太少，不像米家的锁，上锁和开锁都有事件，还可以区分门内操作还是门外操作