欢乐熊大话蓝牙知识17:多连接 BLE 怎么设计服务不会乱？分层思维来救场！

本文链接：https://blog.csdn.net/hoony123/article/details/148540869

多连接 BLE 怎么设计服务不会乱？分层思维来救场！

作者按：
你是不是也遇到过 BLE 多连接时，调试现场像网吧“掉线风暴”？
温度传感器连上了，心率带丢了；一边 OTA 更新，一边通知卡壳。
别怕！今天我们用“分层思维”帮你搞清楚多连接服务设计怎么不乱套！

在这里插入图片描述

🧩 一、多连接 BLE 是怎么回事？

默认 BLE 连接是“一对一”——一个 Central 连接一个 Peripheral。
但现代芯片（如 EFR32、nRF52、ESP32）支持一个 Central 同时连接多个 Peripheral，甚至多个连接角色共存（Dual Role）。

想象一下你的手机开了蓝牙：

连了手表看心率；
又连了温湿度节点采集环境；
还偷偷在和智能秤同步数据…

🤯 全连上后就像开了场 BLE 群聊大会，每个设备讲自己的故事，还要求你听得清楚不混音。

🧠 二、为啥多连接时服务容易“打架”？

常见多连接混乱现象：

问题	原因
收到数据却不知道谁发的？	Service/Characteristic UUID 设计不唯一或缺上下文
通知消息乱入？	不同设备使用相同 Characteristic UUID
连接后发现不了服务？	GATT 服务过多，服务发现冲突或阻塞
连接后丢数据？	每个连接没有独立处理缓冲或事件优先级不对

BLE 的 GATT 是每个连接独立的，但如果你不做逻辑分层，把多个设备的数据全塞进一个“锅”里炖——那当然锅就炸了！

🧱 三、分层思维结构图解

来，用个生活化的比喻：

多连接 BLE = 多个客户来饭店点菜

层级	BLE 模型	饭店比喻
连接层（Link）	每个 Peripheral 的连接	每个客户坐在不同桌子
服务层（GATT）	设备功能模块，如温湿度/OTA	每桌菜单内容
特征层（Characteristic）	每项服务的读写项	菜单中每道菜
应用层（处理逻辑）	数据处理与路由	厨师做菜并上菜到指定桌号

所以要解决多连接混乱的根本就是：

✅ 每桌（连接）独立菜单
✅ 每菜（数据）明确属于哪桌
✅ 厨房（处理模块）有序出菜不串单

在这里插入图片描述

🧪 四、分层设计策略：开发实战指南

1. 每个连接独立维护 `connection_handle`

// GATT 回调里根据连接 ID 分流
void on_characteristic_changed(uint16_t conn_handle, uint16_t char_handle, uint8_t* data) {
    if (conn_handle == SENSOR_NODE_1) {
        handle_sensor_data_1(data);
    } else if (conn_handle == HR_MONITOR) {
        handle_heart_rate(data);
    }
}

2. 为不同设备定义独立的 Service UUID

// 温湿度服务 UUID
#define UUID_SERVICE_ENV     "181A"

// 心率服务 UUID
#define UUID_SERVICE_HRM     "180D"

// OTA 升级服务 UUID
#define UUID_SERVICE_OTA     "FE59"

避免“所有设备都叫 0xFFF0”，那是 BLE 世界的“张三李四”！

3. 把每个设备逻辑封装成模块

typedef struct {
  uint16_t conn_handle;
  uint8_t  sensor_buffer[64];
  bool     notify_enabled;
} sensor_node_t;

sensor_node_t sensor_nodes[MAX_CONN];

void process_env_sensor(sensor_node_t* node, uint8_t* data);

每个设备一个“房间”，互不打扰，有状态、有缓冲。

4. 合理规划事件优先级 & 超时

避免某个设备持续发送通知“霸占总线”。设置每个连接的 timeout / interval / notification rate。

5. 用调试日志打印设备来源

printf("[DEVICE-%d] Received characteristic value: %02X", conn_handle, data[0]);

眼睛看得见，问题好排查。
在这里插入图片描述

🎯 五、小结：多连接不乱，全靠分层“强迫症”

如果 BLE 多连接是一场多人演出，分层设计就是你作为导演维稳现场的剧本：

每人有台词（UUID 唯一）
每句台词标记角色（conn_handle 分发）
每段剧情不混线（逻辑模块封装）

📌 附：服务分层结构示意图

┌────────────────────────────┐
│        Central (主控)       │
├──────┬────────┬────────────┤
│设备1 │ 设备2  │ 设备3       │
├──────┼────────┼────────────┤
│UUIDA │ UUIDB  │ UUIDC       │
│数据处理A│处理B │ 处理C     │
└──────┴────────┴────────────┘
每个连接独立服务 / 特征 / 数据处理逻辑