企业官网建设流程全解析

1. 项目缘起：为什么是XIAO ESP32S3 (Sense)的蓝牙？

最近在折腾一个智能家居的传感器节点，核心需求是低功耗、能采集环境数据（比如温湿度、声音），并且能通过无线方式把数据传出来。Wi-Fi自然是首选，但考虑到有些场景下Wi-Fi网络不稳定或者配置复杂，蓝牙就成了一个非常理想的备选方案——手机直连就能配置和读取数据，方便得很。

在选型的时候，我盯上了Seeed Studio的XIAO ESP32S3 (Sense)这块板子。理由很简单：第一，它核心是乐鑫的ESP32-S3，双核240MHz，性能对付传感器数据处理和蓝牙协议栈绰绰有余；第二，它板载了麦克风和SD卡槽，我这个项目正好想试试音频触发录制；第三，也是最重要的，它尺寸极小（比大拇指还小），但引出了ESP32-S3丰富的GPIO，并且蓝牙功能是原生支持的。这里说的蓝牙，包括了低功耗蓝牙（BLE）和经典蓝牙（BR/EDR），这意味着开发选择非常灵活，既可以做BLE Beacon、蓝牙Mesh设备，也能模拟成蓝牙音箱或者串口透传模块。

网上搜“ESP32S3 蓝牙”，你会发现很多问题都集中在“怎么用”和“坑在哪”。比如，有人纠结于蓝牙模块怎么配置，有人遇到了蓝牙协议栈的兼容性问题，还有人在蓝牙数据传输的稳定性和距离上栽了跟头。更有甚者，像“如何避免esp32-s3中蓝牙的休眠与唤醒”、“如何避免esp32-s3中蓝牙的启动与停止”这类问题，直接指向了低功耗设备开发的核心痛点。所以，我决定以这块XIAO ESP32S3 (Sense)板子为载体，把蓝牙功能的开发从头到尾捋一遍，重点不是简单的“点灯”，而是结合真实场景，把配置、通信、功耗管理这些容易踩坑的地方讲清楚。

2. 开发环境搭建与基础扫盲

工欲善其事，必先利其器。玩转ESP32-S3的蓝牙，首先得把环境搭好。这里我选择的是乐鑫官方的ESP-IDF开发框架，而不是Arduino。原因在于ESP-IDF对ESP32系列芯片的原生支持最完整，特别是蓝牙协议栈这类底层功能，能进行更精细的控制，遇到问题也更容易排查。Arduino虽然上手快，但封装层次太高，很多蓝牙的高级功能和调试信息被隐藏了，不适合做深入探索。

2.1 安装ESP-IDF开发环境

我的主力系统是Ubuntu 22.04，Windows和macOS的流程也大同小异。最推荐的方法是使用乐鑫官方提供的安装脚本，能省去大量配置依赖的麻烦。

# 1. 克隆esp-idf仓库 mkdir -p ~/esp cd ~/esp git clone -b v5.1.2 --recursive https://github.com/espressif/esp-idf.git # 使用v5.1.2这个LTS版本，比较稳定。v5.2.x也可以，但新版本可能有些API变动。 # 2. 运行安装脚本 cd esp-idf ./install.sh esp32s3 # 这个脚本会自动安装编译工具链、Python依赖等所有必需品。 # 3. 激活环境变量 . ./export.sh # 每次打开新终端都需要运行这一行，或者把它加到你的~/.bashrc里。

安装完成后，可以用idf.py --version和idf.py set-target esp32s3来验证环境是否正常。看到能正确识别到ESP32-S3目标，就成功了一半。

2.2 理解ESP32-S3的蓝牙双模

这是核心概念。ESP32-S3支持蓝牙5.0标准，并且是“双模”：

• 经典蓝牙 (Bluetooth Classic, BR/EDR): 就是大家连接耳机、音箱、鼠标（比如mx master鼠标）用的那种。速率高（可达3Mbps），功耗也高。常用协议有A2DP（音频传输）、HFP（免提）、SPP（串口协议）。
• 低功耗蓝牙 (Bluetooth Low Energy, BLE): 为物联网而生。特点是瞬时高速传输后迅速休眠，平均功耗极低。常用于传感器数据上报（心率带、温湿度计）、设备发现（iBeacon）和蓝牙Mesh组网。

在ESP-IDF中，这两套协议栈是独立的，但可以共存。你可以在一个应用中同时启用经典蓝牙的A2DP音频接收和BLE的GATT服务广播，芯片会自行调度。对于XIAO ESP32S3 (Sense)，我们需要根据项目需求选择，或者两者都启用。

2.3 创建第一个蓝牙测试项目

不要一上来就搞复杂的，先确保基础功能是通的。ESP-IDF提供了丰富的示例，我们从一个最简单的BLE广播示例开始。

# 进入示例目录 cd ~/esp/esp-idf/examples/bluetooth/bluedroid/ble/gatt_server # 复制示例到你的工作区 cp -r gatt_server ~/esp/my_ble_project cd ~/esp/my_ble_project # 设置目标芯片 idf.py set-target esp32s3 # 配置项目（使用默认配置即可，但需要检查蓝牙是否启用） idf.py menuconfig

在menuconfig界面中，你需要导航到：

1. Component config->Bluetooth-> 确保[ ] Bluetooth和[ ] Bluetooth Low Energy (BLE)被选中。
2. 由于我们用的是Bluedroid协议栈（ESP-IDF默认），所以Bluetooth controller->Bluetooth controller mode选择BR/EDR/BLE Dual-mode。
3. 检查Partition Table分区表，确保有足够的空间给蓝牙协议栈。对于XIAO ESP32S3，默认的Single factory app, no OTA分区表通常够用。

配置保存退出后，编译并烧录：

# 编译 idf.py build # 烧录，请将/dev/ttyACM0替换成你的板子实际串口号 # Linux下通常是/dev/ttyACM0或/dev/ttyUSB0，Windows是COMx idf.py -p /dev/ttyACM0 flash # 监视串口输出 idf.py -p /dev/ttyACM0 monitor

如果一切顺利，你会在串口监视器里看到设备启动，并开始广播BLE信号。用手机上的任意BLE扫描App（比如nRF Connect），你应该能搜到一个名叫“ESP_GATTS_DEMO”的设备。这说明你的开发环境和板子的蓝牙射频部分基本工作正常。

注意：第一次烧录如果遇到“串口权限拒绝”或“芯片进入下载模式失败”，通常需要检查串口线是否可靠，或者尝试在烧录时按住板子上的“BOOT”按钮再点击“RST”按钮进入下载模式。XIAO ESP32S3的BOOT和RST按钮是同一个，短按是RST，长按并点击是进入下载模式。

3. 深入低功耗蓝牙（BLE）应用开发

基础广播通了，我们来做点实际的：把一个传感器数据通过BLE服务（GATT）暴露出去。假设我们用XIAO ESP32S3 (Sense)板载的麦克风（或者你外接一个DHT11温湿度传感器），周期性地读取数据，并允许手机连接后读取。

3.1 设计GATT服务与特征值（Characteristic）

GATT是BLE通信的核心，它定义了一个层次化的数据结构：

• 服务（Service）： 一个功能单元，比如“环境传感器服务”。
• 特征值（Characteristic）： 服务下的具体数据点，比如“温度”、“湿度”。每个特征值包含一个数值和一组属性（如可读、可写、可通知）。

我们用ESP-IDF的gatt_server_service_table示例来修改。首先，在代码中定义我们自己的服务UUID。为了避免和标准UUID冲突，我们使用128位的自定义UUID。

// 自定义环境传感器服务UUID #define ESP_SENSOR_SERVICE_UUID 0xFF, 0x12, 0x16, 0x20, 0x0A, 0x11, 0x24, 0x8C, 0x9E, 0x25, 0x11, 0xEC, 0x00, 0x00, 0x68, 0xC1 // 温度特征值UUID #define ESP_TEMPERATURE_CHAR_UUID 0xFF, 0x12, 0x16, 0x20, 0x0A, 0x11, 0x24, 0x8C, 0x9E, 0x25, 0x11, 0xEC, 0x01, 0x00, 0x68, 0xC1 // 湿度特征值UUID #define ESP_HUMIDITY_CHAR_UUID 0xFF, 0x12, 0x16, 0x20, 0x0A, 0x11, 0x24, 0x8C, 0x9E, 0x25, 0x11, 0xEC, 0x02, 0x00, 0x68, 0xC1 // 声明特征值属性 static esp_attr_value_t temp_char_val = { .attr_max_len = 4, // 假设温度用float，4字节 .attr_len = 4, .attr_value = {0x00, 0x00, 0x00, 0x00}, // 初始值 }; static esp_attr_value_t humi_char_val = { .attr_max_len = 4, .attr_len = 4, .attr_value = {0x00, 0x00, 0x00, 0x00}, };

然后，我们需要构建一个服务表，告诉协议栈我们的服务结构。这个过程稍微有点繁琐，需要按照esp_gatts_attr_db_t结构体数组来定义。关键在于设置正确的属性权限，比如ESP_GATT_PERM_READ表示可读，ESP_GATT_CHAR_PROP_BIT_NOTIFY表示支持通知（客户端订阅后，服务器可以主动推送数据更新）。

3.2 实现数据更新与“通知”机制

仅仅可读还不够高效。如果手机App需要实时监控温度变化，轮询（不断读取）的方式效率低、延迟高。BLE的“通知”（Notify）机制是解决这个问题的利器：服务器（ESP32）可以在数据变化时，主动向已订阅的客户端（手机）推送更新。

实现通知分为几步：

1. 在定义特征值时，为其添加ESP_GATT_CHAR_PROP_BIT_NOTIFY属性。
2. 当客户端（手机）通过特定的描述符（CCCD， Client Characteristic Configuration Descriptor）订阅了通知后，ESP32会收到一个ESP_GATTS_CONF_EVT事件。
3. 在需要发送数据时（比如定时器读取到新的传感器值），调用esp_ble_gatts_send_indicate或esp_ble_gatts_send_response函数来发送通知。

这里有一个关键细节：发送通知是异步的。你不能在中断服务程序或者高优先级任务中直接调用发送函数。通常的做法是，在一个单独的传感器数据采集任务中，将新的数据写入特征值的attr_value，然后通过队列、事件组等IPC机制，通知一个专用的“BLE发送任务”去执行esp_ble_gatts_send_indicate。

// 伪代码示例 void sensor_read_task(void *pvParameters) { float temperature, humidity; while(1) { // 读取传感器数据 temperature = read_temperature(); humidity = read_humidity(); // 更新特征值内存 memcpy(temp_char_val.attr_value, &temperature, 4); memcpy(humi_char_val.attr_value, &humidity, 4); // 发送事件，通知BLE任务发送更新 xEventGroupSetBits(ble_event_group, DATA_UPDATED_BIT); vTaskDelay(pdMS_TO_TICKS(5000)); // 5秒读一次 } } void ble_send_task(void *pvParameters) { EventBits_t bits; while(1) { // 等待数据更新事件 bits = xEventGroupWaitBits(ble_event_group, DATA_UPDATED_BIT, pdTRUE, pdFALSE, portMAX_DELAY); if(bits & DATA_UPDATED_BIT) { // 检查客户端是否订阅了通知 if(client_subscribed_to_temp) { esp_ble_gatts_send_indicate(gatts_if, conn_id, temp_handle, 4, temp_char_val.attr_value, false); } // ... 同理发送湿度通知 } } }

3.3 连接参数协商与功耗优化

这是BLE开发中最容易被忽略，但又对体验影响极大的部分。连接参数包括：

• 连接间隔（Connection Interval）： 主机（手机）和从机（ESP32）之间通信的时间间隔，范围在7.5ms到4s之间。间隔越短，实时性越好，功耗越高；间隔越长，功耗越低，延迟越高。
• 从机延迟（Slave Latency）： 允许从机跳过多少个连接事件而不必回应，用于进一步降低功耗。
• 监督超时（Supervision Timeout）： 连接丢失的判断时间。

很多新手会发现设备连接后耗电很快，或者手机偶尔会断开连接，很可能就是连接参数没设置好。ESP32作为从机，可以在连接建立后，向主机发起更新连接参数的请求。

// 定义一个理想的连接参数：间隔100ms，延迟4，超时6s esp_ble_conn_update_params_t conn_params = { .bda = {0}, // 广播地址，连接后可以从事件中获取 .min_int = 0x40, // 100ms = 0x40 * 1.25ms .max_int = 0x40, .latency = 4, .timeout = 600, // 6s = 600 * 10ms }; // 在ESP_GATTS_CONNECT_EVT连接事件中调用 esp_ble_gap_update_conn_params(&conn_params);

但请注意，主机（通常是手机操作系统）有最终决定权。它可能拒绝你的请求，或者使用它自己的一套策略。iOS和Android的行为就不完全一致。实测中发现，对于传感器这类低频更新设备，将最大最小间隔都设为500ms甚至1s，能显著提升续航，且对数据更新体验影响不大。

4. 经典蓝牙（SPP）串口透传实战

虽然BLE是主流，但经典蓝牙在某些场景下不可替代。比如，你需要与只支持经典蓝牙的老设备通信，或者需要更高的数据传输速率（尽管BLE 5.0的高速模式也很快）。经典蓝牙的串口协议（SPP）是最常用的 profile，它本质上就是在蓝牙链路上虚拟了一个串口，使用方式和有线串口几乎一样。

4.1 启用经典蓝牙与SPP Profile

在ESP-IDF中启用经典蓝牙，需要在menuconfig中开启Bluetooth和Classic Bluetooth。SPP功能包含在Bluetooth->Bluedroid Options->Classic Bluetooth->SPP中，记得选中。

初始化流程比BLE稍简单一些，但事件处理逻辑是类似的。核心步骤是初始化蓝牙控制器和Bluedroid协议栈，然后注册SPP回调函数，并启动SPP。

#include "esp_bt.h" #include "esp_bt_main.h" #include "esp_spp.h" void spp_init(void) { // 1. 初始化蓝牙控制器 esp_bt_controller_config_t bt_cfg = BT_CONTROLLER_INIT_CONFIG_DEFAULT(); esp_bt_controller_init(&bt_cfg); esp_bt_controller_enable(ESP_BT_MODE_CLASSIC_BT); // 或 ESP_BT_MODE_BTDM 双模 // 2. 初始化Bluedroid协议栈 esp_bluedroid_init(); esp_bluedroid_enable(); // 3. 注册SPP回调 esp_spp_register_callback(esp_spp_cb); // 4. 初始化SPP esp_spp_init(ESP_SPP_MODE_CB); // 5. 设置设备名和可发现模式 esp_bt_dev_set_device_name("ESP32_SPP_SERVER"); esp_bt_gap_set_scan_mode(ESP_BT_SCAN_MODE_CONNECTABLE_DISCOVERABLE); }

4.2 实现数据收发

SPP的事件回调函数esp_spp_cb会处理各种事件，最重要的几个是：

• ESP_SPP_SRV_OPEN_EVT: 客户端（如手机）连接成功。在这个事件里，你会获得一个连接句柄和MAC地址，后续收发数据都基于这个连接。
• ESP_SPP_DATA_IND_EVT: 收到客户端发来的数据。数据存放在param->data_ind.data，长度是param->data_ind.len。
• ESP_SPP_CLOSE_EVT: 连接关闭。

发送数据非常简单，直接调用esp_spp_write函数即可，类似于串口的write。

static void esp_spp_cb(esp_spp_cb_event_t event, esp_spp_cb_param_t *param) { switch (event) { case ESP_SPP_SRV_OPEN_EVT: ESP_LOGI(SPP_TAG, "Client connected, handle:%d", param->srv_open.handle); g_spp_handle = param->srv_open.handle; // 保存连接句柄 break; case ESP_SPP_DATA_IND_EVT: ESP_LOGI(SPP_TAG, "Data received, len:%d", param->data_ind.len); // 处理数据，例如回显 esp_spp_write(param->data_ind.handle, param->data_ind.len, param->data_ind.data); break; case ESP_SPP_CLOSE_EVT: ESP_LOGI(SPP_TAG, "Connection closed"); g_spp_handle = 0; break; default: break; } } // 在任意需要发送数据的地方 if(g_spp_handle != 0) { char *data = "Hello from ESP32-S3!\n"; esp_spp_write(g_spp_handle, strlen(data), (uint8_t *)data); }

4.3 手机端连接测试

在手机上测试SPP，你需要一个支持SPP的蓝牙串口App，比如“Serial Bluetooth Terminal”或“BLE Scanner”（部分也支持经典蓝牙）。打开手机蓝牙，搜索设备，应该能找到名为“ESP32_SPP_SERVER”的设备。配对连接后（配对码通常是1234或0000，可以在代码中设置esp_bt_pin_code_t），就可以在App里发送和接收数据了。

这里有一个经典坑点：不同手机厂商和Android版本对经典蓝牙SPP的支持程度和权限处理不同。有些手机需要在系统设置里手动配对，App内才能连接；有些则可以直接在App内完成配对连接。iOS对经典蓝牙SPP的支持非常有限，通常只允许MFi认证的设备，所以用iOS测试经典蓝牙SPP基本会失败，这是协议限制，不是代码问题。

5. 功耗管理与实战避坑指南

对于电池供电的XIAO ESP32S3 (Sense)项目，功耗是命门。蓝牙，尤其是持续广播或保持连接，是耗电大户。网上那些“如何避免esp32-s3中蓝牙的休眠与唤醒”的问题，正是源于此。

5.1 ESP32-S3的电源模式

ESP32-S3支持多种功耗模式，从高到低：

1. Active模式： CPU和射频全速运行，功耗最高（几十到上百mA）。
2. Modem-sleep模式： CPU运行，但Wi-Fi/蓝牙射频关闭或处于轻睡眠。这是保持蓝牙连接同时降低功耗的关键模式。在BLE连接中，CPU可以在连接事件之间睡眠。
3. Light-sleep模式： CPU暂停，RAM数据保持，部分外设关闭。蓝牙控制器可以唤醒芯片。
4. Deep-sleep模式： 几乎全部关闭，仅RTC极低速运行和少量RAM保持。蓝牙连接会断开，唤醒后需要重新初始化连接。

对于需要维持蓝牙连接的设备，我们的目标是尽可能让系统工作在Modem-sleep或Light-sleep模式。

5.2 在BLE连接中实现Modem-sleep

幸运的是，如果正确配置了连接参数（如较长的连接间隔和从机延迟），并且应用任务在处理完事件后及时阻塞（例如使用vTaskDelay或等待信号量），ESP-IDF的蓝牙协议栈和FreeRTOS调度器会自动帮我们进入Modem-sleep模式。

你需要做的是：

• 避免忙等待： 不要在任务中用while(1)空转。确保所有任务在无事可做时，都处于阻塞状态（Blocked State）。
• 合理设置看门狗： 如果任务阻塞时间很长，注意软件看门狗（TWDT）的超时设置，可能需要适当调大或暂停喂狗。
• 使用低功耗外设： 比如读取传感器时，使用中断方式而非轮询。

你可以通过测量电流来验证。在BLE连接但空闲时，XIAO ESP32S3的电流可以降到几个mA级别（Modem-sleep）。如果电流一直在20mA以上，说明有任务在阻止系统休眠。

5.3 经典蓝牙的功耗挑战与应对

经典蓝牙的功耗天生比BLE高，因为它需要维持更频繁的通信链路。对于SPP这类持续连接的应用，很难做到像BLE那样的超低功耗。如果对功耗有极致要求，应优先考虑BLE。

如果必须使用经典蓝牙，可以尝试以下策略：

• 非持续连接： 设计为设备端定时唤醒，打开蓝牙广播一段时间供手机连接，传输完数据后立即断开连接并进入Deep-sleep。下次唤醒再重复。这牺牲了实时性。
• 降低射频功率： 通过esp_bredr_tx_power_setAPI降低发射功率，以牺牲通信距离换取功耗降低。
• 优化数据包： 减少不必要的通信，合并数据包，减少射频激活时间。

5.4 常见问题排查（避坑实录）

结合网络热词和自身经验，这里列几个高频坑点：

1. 蓝牙搜不到或信号极弱：

   • 检查天线： XIAO ESP32S3 (Sense)板载了PCB天线。确保周围没有大面积金属遮挡，天线区域不要被导线或手覆盖。
   • 检查供电： 使用不稳定的USB线或电源，可能导致射频供电不足。尝试换用高质量的USB线或外部3.3V稳压电源供电。
   • 检查配置： 确认menuconfig中蓝牙控制器模式（BR/EDR/BLE Dual-mode）和PHY初始化参数正确。错误的射频参数会导致发射功率异常。

2. 连接不稳定，频繁断开：

   • 连接参数问题： 这是首要怀疑对象。尤其是监督超时（Supervision Timeout）设置过小。确保超时时间远大于连接间隔，例如连接间隔100ms，超时至少设2s以上。
   • 射频干扰： 2.4GHz频段很拥挤，Wi-Fi、微波炉都可能干扰。尝试改变Wi-Fi信道（在代码中固定ESP32的Wi-Fi信道）或让设备远离干扰源。
   • 内存溢出： 蓝牙协议栈任务崩溃。使用idf.py monitor查看是否有“Guru Meditation Error”或内存相关的错误日志。适当增大menuconfig中蓝牙相关的内存池大小。

3. 数据传输速率慢或丢包：

   • MTU设置： BLE的默认MTU（最大传输单元）是23字节，有效载荷更小。可以在连接建立后协商更大的MTU（如512字节），使用esp_ble_gattc_send_mtu_req（客户端）或响应客户端的MTU请求（服务器端）。
   • 连接间隔： 增加连接间隔会降低数据吞吐率。对于需要高速传输的场景，应减小连接间隔。
   • 经典蓝牙SPP： SPP的吞吐率本身受协议和手机端限制，通常能达到几十KB/s。如果远低于此，检查是否在单线程中频繁发送小包，可以尝试合并数据后再发送。

4. 关于“蓝牙休眠与唤醒”：

   • 这个问题通常不是指手动去“停止”蓝牙，而是指系统如何自动进入低功耗状态。核心是确保应用逻辑允许CPU空闲。检查你的任务函数，如果里面有while(1)且没有调用任何会阻塞的FreeRTOS API（如vTaskDelay,xQueueReceive,ulTaskNotifyTake），那么CPU将永远忙碌，无法休眠。正确的做法是将数据采集、发送等操作放在定时器回调或任务循环中，并在每次循环末尾调用vTaskDelay让出CPU时间。

6. 进阶应用：蓝牙Mesh组网初探

当你的项目需要覆盖更大范围，或者设备数量众多时，单点对点的蓝牙连接就不够用了。蓝牙Mesh应运而生。它基于BLE广播，允许设备中继消息，形成一个多跳的网络。ESP32-S3是支持蓝牙Mesh的。

6.1 蓝牙Mesh基础概念

蓝牙Mesh网络中的设备称为“节点”（Node）。节点可以分为：

• 中继节点（Relay）： 可以转发消息，扩展网络范围。
• 代理节点（Proxy）： 可以让不支持Mesh协议的BLE设备（如普通手机）通过GATT连接接入Mesh网络。
• 低功耗节点（Low Power Node, LPN）： 大部分时间在睡眠，由“朋友节点”（Friend Node）为其缓存消息。

网络通信基于“发布-订阅”模型。消息发布到一个“地址”，所有订阅了该地址的节点都会收到消息。地址可以是单播、组播或广播地址。

6.2 在XIAO ESP32S3上快速搭建一个Mesh网络

ESP-IDF提供了完整的蓝牙Mesh示例。我们以examples/bluetooth/esp_ble_mesh/ble_mesh_node/onoff_server为例，构建一个简单的灯控网络。

1. 配置与编译： 进入示例目录，运行idf.py set-target esp32s3和idf.py menuconfig。确保Component config->ESP32-specific->Support for external, SPI-connected RAM没有被启用（除非你外接了PSRAM），因为Mesh协议栈比较占内存。直接编译烧录到两块或以上的XIAO ESP32S3板子上。

2. 网络配置： 设备上电后，它们还只是一个未配置的节点（Unprovisioned Device）。你需要一个“配置者”（Provisioner）来将它们加入网络。最简单的方法是使用乐鑫提供的手机App“EspBleMesh”（Android/iOS）。打开App，它会扫描到未配置的设备，你可以将其添加到一个网络中，并为其分配一个单播地址。

3. 控制与中继： 配置完成后，这些节点就组成了Mesh网络。在App里，你可以向某个节点的单播地址发送“开/关”命令。如果你将其中一些节点设置为中继节点（代码中可配置），那么即使目标节点不在手机的直接广播范围内，消息也可以通过中继节点跳转到达。

6.3 Mesh网络功耗与优化

蓝牙Mesh的功耗是个复杂话题。一个始终监听和中继消息的节点，其功耗与一直处于广播扫描状态的BLE设备类似，相对较高。因此，在实际部署中，需要根据设备角色进行设计：

• 常电设备（如插电的灯、网关）可以设置为中继和代理节点，保持活跃。
• 电池设备（如传感器）必须设置为低功耗节点（LPN）。LPN会与一个“朋友节点”配对，大部分时间深度睡眠，定期醒来向朋友节点收取缓存的消息。这可以极大延长电池寿命，但代价是消息传递有延迟。

在代码中，通过调用esp_ble_mesh_set_friend_state()和esp_ble_mesh_lpn_enable()等API来启用LPN功能。同时，需要有一个设备作为“朋友节点”来支持它。这需要仔细设计网络拓扑和参数（如轮询间隔）。

注意：蓝牙Mesh的配置和调试比点对点BLE复杂得多。建议从一个简单的、不启用中继和低功耗功能的网络开始，确保基础通信正常，再逐步增加复杂功能。同时，注意网络规模，过多的中继节点可能导致网络风暴（即消息被无休止地转发），需要通过设置TTL（Time To Live，生存时间）来限制消息的跳数。

从点对点的数据透传，到多设备的Mesh组网，XIAO ESP32S3 (Sense)的蓝牙功能为我们提供了从简单到复杂的完整解决方案。关键在于理解不同协议的特性（BLE的低功耗、经典蓝牙的高速率、Mesh的网络扩展），并根据项目需求（功耗、距离、数据量、节点数）做出正确的选择。开发过程中，善用ESP-IDF的示例代码，从最基础的例程跑通开始，逐步添加自己的业务逻辑，同时时刻关注串口日志，它是排查蓝牙问题最直接的窗口。最后，功耗优化是一个系统工程，需要从硬件选型、电源管理、连接参数、软件逻辑等多个层面协同考虑，才能做出真正实用的低功耗蓝牙产品。