4. 开发环境搭建
做物联网这几年，我见过太多配网失败的场景了。用户拿着手机对着设备一顿操作，结果灯闪了半天还是连不上。说实话，大部分问题都出在「配网方式」的选择上。
今天我们就来聊聊，为什么BLE配网成了主流方案。它的核心设计思想到底是什么？
4.1 为什么BLE更适合配网？
先问一个问题：WiFi设备本身就能联网，为什么还要用BLE来帮它配网？
你想想看，一个刚出厂的WiFi设备，它不知道家里的WiFi密码，也不知道路由器的SSID。它唯一能做的就是把自己变成一个热点（AP模式），或者扫描周围的WiFi信号。这两种方式都有明显的短板。
传统WiFi配网的痛点：
- AP模式配网：手机要断开当前WiFi，连到设备的热点上。这个过程用户体验很差，手机网络会中断，而且设备热点通常没有互联网连接。
- SmartConfig/乐鑫快连：依赖WiFi广播包的长度编码，成功率受路由器影响很大。我在项目中遇到过，某些企业级路由器直接过滤了这些特殊长度的广播包，导致配网死活不成功。
- 配网耗时：传统方式平均需要15-30秒，用户等得心焦。
而BLE配网，说白了就是让设备先通过低功耗蓝牙和手机建立一条「控制通道」。这条通道不依赖WiFi网络，手机不用断开当前连接，设备也不用先联网。双方先聊起来，把WiFi信息传过去，设备再去连路由器。
这样做的好处很明显：
| 对比维度 | 传统WiFi配网 | BLE辅助配网 |
|---|---|---|
| 手机网络状态 | 需断开当前WiFi | 保持在线，不影响使用 |
| 配网成功率 | 受路由器限制大 | BLE独立通道，稳定可靠 |
| 用户交互 | 几乎无交互反馈 | 可实时显示进度、错误信息 |
| 配网耗时 | 15-30秒 | 3-8秒（含WiFi连接） |
| 安全性 | 密码明文广播 | 支持加密传输 |
我个人习惯用BLE配网还有一个原因：调试方便。开发阶段，我可以直接用手机APP查看设备广播的详细信息，甚至能实时修改WiFi配置参数，不用反复烧录固件。
4.2 BLE配网的典型流程
一个完整的BLE配网流程，可以分为四个阶段。我画了一张图，方便你理解整体脉络。
4.3 设备发现：找到对的设备
设备上电后，会通过BLE广播通道发送广播包。广播包里包含设备名称、Service UUID、还有一些自定义数据。
手机APP这边，会持续扫描周围的BLE广播。但有个问题：周围可能有几十个BLE设备，怎么找到你要配网的那一个？
我常用的做法是：
- 使用自定义Service UUID：比如我们团队统一用
0000FEE0-0000-1000-8000-00805F9B34FB作为配网服务的UUID。手机只扫描包含这个UUID的设备，过滤掉无关的。 - 广播包携带设备标识：在广播包的Manufacturer Specific Data字段里，放入设备MAC地址的后3字节或者产品序列号。手机可以据此精确匹配。
- 用户辅助确认：让用户点击设备上的按钮，设备进入「可配网」状态，广播包里的标志位会变化。手机检测到这个变化后，自动发起连接。
我的经验：广播包的长度有限（31字节），要精打细算。我一般把Service UUID放在核心位置，设备名称用简写，自定义数据只放最关键的信息。曾经有个项目，因为广播包塞了太多数据，导致某些手机扫描不到设备，排查了好久才发现是广播包超长被截断了。
4.4 能力协商：别让双方「鸡同鸭讲」
手机和设备建立BLE连接后，第一件事不是急着传WiFi密码，而是先「握手」。这一步很多人会忽略，但我觉得它特别重要。
能力协商主要交换这些信息：
| 协商内容 | 说明 | 典型值 |
|---|---|---|
| 协议版本号 | 双方使用的配网协议版本 | v1.0 / v2.0 |
| 支持的安全模式 | 是否加密、加密方式 | 明文 / AES-CCM |
| 最大MTU大小 | BLE单包能传输的最大字节数 | 23 / 128 / 247 |
| WiFi能力 | 设备支持的WiFi频段、加密方式 | 2.4G / 5G / WPA2 |
| 配网状态 | 设备当前是否已配网 | 未配网 / 已配网 |
举个例子，如果手机端支持5G WiFi，但设备只支持2.4G，那手机在WiFi扫描时就应该过滤掉5G的信号，避免用户选了5G的SSID导致配网失败。
我记得有一次，客户反馈设备配网成功率低。排查后发现，设备端WiFi芯片只支持WPA2加密，但手机下发的WiFi信息里包含了WPA3的配置参数。设备解析失败，直接放弃了连接。后来在能力协商阶段增加了加密方式字段，手机根据设备能力动态调整下发的参数，问题就解决了。
4.5 WiFi信息下发：把密码安全地传过去
这是整个配网流程的核心步骤。手机把WiFi的SSID和密码，通过BLE的Write操作写入设备的特征值（Characteristic）。
这里有几个关键点：
- 数据格式：我习惯用JSON或者TLV格式封装WiFi信息。JSON可读性好，但解析开销大；TLV格式紧凑，适合资源受限的MCU。
- 分包策略：如果WiFi信息超过MTU大小，需要分包发送。每个包要有序号和总包数，设备端按序重组。
- 加密传输：WiFi密码是敏感信息，明文传输有风险。建议在能力协商阶段确定加密方式，对WiFi信息进行加密后再传输。
// WiFi信息TLV格式示例
// Tag: 0x01 = SSID, 0x02 = Password, 0x03 = BSSID, 0xFF = 结束
uint8_t wifi_info[] = {
0x01, 0x0A, // Tag=SSID, Length=10
'M', 'y', 'H', 'o', 'm', 'e', 'W', 'i', 'F', 'i',
0x02, 0x08, // Tag=Password, Length=8
'1', '2', '3', '4', '5', '6', '7', '8',
0xFF, 0x00 // 结束标志
};注意：WiFi密码中可能包含特殊字符（如空格、引号、换行符），在封装数据时要做好转义处理。我曾经遇到一个用户，密码里有个反斜杠，结果设备解析时把后面的字符都吞掉了。后来我们在协议里明确规定，密码字段使用Base64编码，彻底规避了这个问题。
4.6 连接确认：给用户一个交代
设备收到WiFi信息后，会尝试连接路由器。这个过程中，设备需要通过BLE实时回传状态给手机。
我一般定义这几个状态：
- 0x00：收到WiFi信息，开始连接
- 0x01：正在扫描WiFi信号
- 0x02：正在认证（输入密码）
- 0x03：正在获取IP地址
- 0x04：连接成功
- 0xFF：连接失败（附带错误码）
手机APP收到这些状态后，可以实时更新UI，让用户知道配网进行到哪一步了。如果连接失败，还能显示具体的错误原因，比如「密码错误」、「路由器未找到」、「DHCP超时」等。
这里有个细节：设备连接WiFi成功后，BLE连接不要立即断开。我习惯让设备保持BLE连接10-15秒，等手机确认收到「连接成功」的通知后，再主动断开。这样可以避免手机端因为网络切换而丢失最后的确认消息。
4.7 安全性考量初探
说到安全性，很多人的第一反应是「WiFi密码不能明文传输」。但实际项目中，安全问题远不止这一点。
我整理了几个常见的安全风险：
| 风险点 | 描述 | 应对措施 |
|---|---|---|
| 广播包窃听 | 攻击者通过扫描BLE广播获取设备信息 | 广播包不包含敏感信息，仅用于设备发现 |
| 中间人攻击 | 攻击者伪造设备或手机，拦截WiFi信息 | 使用BLE配对绑定（Bonding），建立安全连接 |
| 重放攻击 | 攻击者截获加密的WiFi信息后重复发送 | 在数据包中加入时间戳或随机数（Nonce） |
| 暴力破解 | 攻击者通过多次尝试猜测WiFi密码 | 限制配网尝试次数，增加重试延迟 |
| 固件篡改 | 攻击者通过OTA更新植入恶意固件 | 固件签名验证，只运行经过签名的固件 |
对于大多数消费级产品，做到「BLE连接加密 + WiFi信息加密传输」就基本够用了。但对于金融、医疗等对安全性要求高的场景，还需要考虑设备身份认证、安全芯片等更复杂的方案。
我的建议：不要为了追求绝对安全而过度设计。我曾经见过一个项目，安全方案做得极其复杂，结果配网成功率降到60%以下，用户投诉不断。安全性和用户体验之间要找到平衡点。对于家用IoT设备，AES-CCM加密 + 随机数防重放，已经能挡住绝大多数攻击了。
嗯，到这里，BLE配网的核心设计思想就讲完了。说白了，BLE配网的本质就是「借道」——借用BLE这条低功耗、高可靠的通道，帮WiFi设备完成最关键的「身份认证」和「信息交换」。理解了这一点，后面章节的具体实现就会顺理成章。