ESPHOME通过创米小白TTL输出接入米家蓝牙设备

jungyo

支持哪些蓝牙设备，是否还需要Node-RED?

121665460

0703005 发表于 2020-11-30 00:57
esp01s 无解了  我在不同的店铺买了三个  同样没有输出，算了 不弄了

你的蓝牙网关是什么，我用的榉树，没有ots这个。
去掉这几行试试
   char *otsMessage = strstr(data,"ots:");
    if(!otsMessage){
      return;
    }

XCray

N大这个思路曾经是我努力想实现的，当时还发过一个帖子：！ESP Home实现基于蓝牙网关-TTL的智能门锁等蓝牙设备接入

那时候对esphome还处于小白状态，整体思路也不是最优选择——当时想的是在esphome里直接定制传感器，实在太复杂就只好放弃了。
后来用arduino ide直接编写，整体思路逐渐清晰、完善后基本达到了实用状态，再迁移回esphome的想法在去年8月份有过，后来犯懒就没弄（对自己的c++功底自信不足也是一个原因哈），幸好N大出手了！

不过看到这个帖子，我也想废弃掉原来的方式、改用esphome了，这么做显然有几个好处：
1. esphome统一管理
2. 摆脱对arduino ide的依赖
3. 享受esphome更成熟更强大的组件代码

去年11月底看到这个帖子之后就下载了N大的代码，只不过当时沉迷于雪场，竟然酒吧这件事儿给忘了。今天又看到，干脆动起手来！

简单修改一下代码，主要是mqtt消息topic，这样ha侧的配置就不用动了，无缝切换，爽！

代码已上传至我原来的帖子：
[新奇玩法] (多个)蓝牙网关 TTL->MQTT，支持任意米家蓝牙设备接入HA/NR

XCray

maybeloveu 发表于 2020-11-26 16:24
XCray 的固件的确丢消息严重。使用夜灯蓝牙人体传感器非常多丢的。
esphome 没用过，步骤能详细写吗？ ...

在我开始玩这个之前，已经有人说过丢消息的问题了。我自己曾经长时间利用榉树门锁的周期性事件（约71秒1条）来这个问题，后来发现主要原因是esp8266或晶振在温度偏高时不稳定，也曾经专门发过帖子：
[经验分享] 我好像找到了ESP8266转发TTL串口发生丢消息问题的根本原因

另外，散热与丢消息之间的关联，也有好几位朋友（包括k大）验证过，这个结论还是经得住推敲的。
在确保散热的情况下一直用到现在（今天打算改成N大的esphome模式），丢消息的现象总共没发生过几次。

neroxps

XCray 发表于 2021-5-27 08:08
在我开始玩这个之前，已经有人说过丢消息的问题了。我自己曾经长时间利用榉树门锁的周期性事件（约71秒1条 ...

我总感觉是米家其他蓝牙网关吃掉了消息~这个我一个月也会丢一次两次~其他时间还行~我主要修改还是吧串口过来的消息弄成 vector  参考至 tuya 的 esphome 插件~这样就不需要定义内存空间长度，不担心因为超长的 rxmessage 导致溢出或 json 解读失败~

XCray

neroxps 发表于 2021-5-27 12:58
我总感觉是米家其他蓝牙网关吃掉了消息~这个我一个月也会丢一次两次~其他时间还行~我主要修改还是吧串口过 ...

我一直只有一个蓝牙网关，根据其他坛友的描述，多个网关并存的时候，确实有可能造成同一个设备在不同蓝牙网关之间“漫游”的情况——我猜这恰恰会发生在这到几个网关的信号都比较差的条件下。

这就会存在两个可能：有些消息被另外一个网关收到并处理了、有的消息干脆哪个网关都没收到。

理论上，每个蓝牙网关都应该随身配置一个esp模块、完成TTL消息的转发。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
另外，我心里总是有个念头挥之不去：为啥不用ESPHome的原生API呢？难道原生API就做不到吗？

翻了翻eshome.io，基本有了一个清晰的、可以实现的思路：
让esp模块触发homeassistant.event、在event data里传递did、eid、edata这些数据，然后在HA侧继续借助template的力量实现各种传感器。

参考：Native API Component — ESPHome

试了n次，终于编译通过了，初步测试取得进展： ttl_evt.zip (2.21 KB, 下载次数: 4)

2021-5-27 19:57 上传

点击文件名下载附件

HA侧生成的某个事件数据如下：

{
    "event_type": "esphome.TTLjsonGot",
    "data": {
        "did": "xxxxxx",
        "edata": "000086",
        "eid": "4103"
    },
    "origin": "LOCAL",
    "time_fired": "2021-05-27T11:50:12.096994+00:00",
    "context": {
        "id": "1872a9a0ce7680d9848da80e5d56aa26",
        "parent_id": null,
        "user_id": null
    }
}

复制代码

接下来就可以在yaml里定义各种传感器了。

不过琢磨了一下事件触发传感器更新的模板，感觉也挺麻烦的，算了，不折腾了~~~

neroxps

XCray 发表于 2021-5-27 15:19
我一直只有一个蓝牙网关，根据其他坛友的描述，多个网关并存的时候，确实有可能造成同一个设备在不同蓝牙 ...

emmm http 我感觉没mqtt靠谱

XCray

neroxps 发表于 2021-5-27 19:30
emmm http 我感觉没mqtt靠谱

也许吧，我是看esphome自己的文档里有这么一段：

Advantages over MQTT
The ESPHome native API has many advantages over using MQTT for communication with Home Automation software (currently only Home Assistant). But MQTT is a great protocol and will never be removed. Features of native API (vs. MQTT):

Much more efficient: ESPHome encodes all messages in a highly optimized format with protocol buffers - for example binary sensor state messages are about 1/10 of the size.

One-click configuration: ESPHome just needs one click to set up in Home Assistant - no more messing around with retained MQTT discovery messages and alike.

One less single point of failure: In the ESPHome native API each ESP is its own server. With MQTT, when the broker shuts off nothing can communicate anymore.

Stability: Since ESPHome has far more control over the protocol than with MQTT, it’s really easy for us to roll out stability improvements.

Low Latency: The native API is optimized for very low latency, usually this is only a couple of milliseconds and far less than can be noticed by the eye.

高效、稳定、低延迟，减少了对mqtt的依赖，也就意味着少了一个单点故障的可能性。