做 IoT 设备开发这几年我在配网环节踩过的坑比在业务逻辑里踩的还多。尤其是帮客户排查“设备明明配上网了却频繁掉线、响应慢、App 显示离线”这类问题时最后查来查去基本都指向同一个根源配网时只关心“连没连上”没关心“信号到底好不好”。标题里“WiFi 配网状态与 RSSI 信号强度”这个组合其实就是 IoT 产品从“能跑”到“好用”之间最容易被忽略的那道坎。这篇文章我打算从一次真实项目经历出发完整拆解配网状态机的设计思路、RSSI 信号强度的采集与滤波方法再把产品化过程中遇到的坑和排查手法一并整理出来。适合正在做智能家居、传感器网关、ESP32 类联网硬件以及负责设备端联网体验的嵌入式开发同学参考。整篇文章的核心就一句话配网成功只是起点RSSI 才是衡量这次配网到底能不能稳定用的关键指标。1. 重新理解“配网成功”不是连上路由器就万事大吉1.1 一次完整配网要经历的三层链路很多刚接触 IoT 开发的工程师对“配网成功”的理解停留在WiFi connected这个事件上。但实际上从设备上电到真正可以云平台通信中间要经过三层验证第一层设备与路由器完成握手拿到 BSSID、信道、加密方式这一层叫“链路层通”。第二层设备通过 DHCP 拿到 IP 地址能够与局域网内其他设备互通这一层叫“网络层通”。第三层设备通过 TCP/TLS 连接上云平台完成鉴权和注册这一层叫“应用层通”。只有三层全部走通才算真正意义上的“配网成功”。我们项目里最初犯过的错误就是只检测了第一层就弹窗告诉用户“配置成功”结果大量设备卡在 DHCP 阶段用户以为是路由器问题其实是设备端根本没有把状态机设计完整。所以后来我们重新定义了配网状态至少拆成以下六个状态状态含义触发条件IDLE待配网设备上电无有效 WiFi 配置SCANNING扫描中进入配网模式触发周边网络扫描CONNECTING连接中拿到用户选择的热点信息发起连接OBTAINING_IP获取 IPWiFi 已关联开始 DHCP 请求CLOUD_CONNECTING云连接中IP 获取成功开始连接云平台ONLINE在线云平台连接成功心跳上报正常所有状态都要有超时时间超时后自动回到 IDLE 或进入错误提示分支。比如CONNECTING状态下 15 秒没有触发OBTAINING_IP就直接抛出“密码错误或信号太弱”的错误码而不是让用户干等。1.2 RSSI 信号强度在这条链路上的作用被低估了RSSI 全称 Received Signal Strength Indicator接收信号强度指示单位是 dBm。由于它是个负值很多人看不太习惯。简单记住一个对照经验就够了-30dBm ~ -50dBm信号极好贴近路由器几乎所有速率都能跑满。-50dBm ~ -60dBm信号良好日常使用基本无感。-60dBm ~ -70dBm信号一般丢包开始出现视频会卡顿。-70dBm ~ -80dBm信号较差连接能维持但重传率高响应延迟明显。-80dBm 以下信号极差随时可能断开基本不可用。RSSI 在配网链路中的作用远远不止是“显示几格信号”。我们实测过一个场景设备放在客厅路由器在卧室中间隔了两堵承重墙。手机 App 显示 WiFi 信号满格因为它站在设备旁边而设备端扫描到的路由器 RSSI 只有 -76dBm。用户按照手机信号满格的预期去判断自然觉得“路由器没问题是设备有问题”。所以我们在配网流程里强制加了一步设备选完热点后先上报扫描到的 RSSI 值如果低于阈值直接弹窗提醒用户“当前信号较弱建议将设备靠近路由器”。这一步把因信号问题导致的配网失败率直接降了差不多四成。RSSI 不是锦上添花的功能而是配网体验里的第一道质量闸门。2. 配网状态机的完整设计与 RSSI 采集方案2.1 状态机迁移细节让每个状态都“可观测、可干预”设计配网状态机时我喜欢把“可观测”放在第一位。所谓可观测就是每个状态都要有明确的进入条件、退出条件、超时时间以及对应的日志输出。你可以把这套状态机跑起来后通过串口日志就能像看电影一样看出设备当前卡在哪一步。我们项目里具体的迁移逻辑大致是这样的设备首次上电Flash 中没有保存任何 WiFi 配置进入IDLE状态。用户按下配网键或设备自动进入配网模式进入SCANNING状态开始扫描周边网络。扫描结果通过蓝牙或 SoftAP 通道回传给手机 App用户选择要连接的热点并输入密码。设备收到密码后进入CONNECTING状态调用 WiFi 库发起连接。连接成功拿到 BSSID、信道后立即进入OBTAINING_IP状态等待 DHCP 分配地址。IP 获取成功进入CLOUD_CONNECTING状态尝试连接云平台。云平台返回注册成功进入ONLINE状态配网流程结束。每个状态都配备一个超时定时器CONNECTING和OBTAINING_IP建议设 15~20 秒CLOUD_CONNECTING建议设 10 秒。超过时间后设备要主动上报当前状态码并回到IDLE等待用户重试。这里有一个容易被忽略的点用户输入密码错误和信号太弱表现出来的现象可能是一模一样的——连接超时。为了区分这两类问题我们会在CONNECTING期间持续记录 WiFi 库回调的错误码以及重试次数最终将诊断信息一并上报到 App 端。2.2 RSSI 单次采样不可信必须做滤波处理RSSI 这个值有一个特点即使设备静止不动相邻两次采样结果也会跳动幅度通常在 ±5dBm 左右如果在有人走动、微波炉工作等环境里抖动会更夸张。如果直接把原始 RSSI 拿来判断信号等级、触发告警几乎一定会出现误报。我们常用的方案是指数加权移动平均EWMA。它不像算术平均那样需要存一堆历史样本而是用一个递归公式对新的采样值做平滑计算复杂度非常低放在中断里跑都没问题。// EWMA 滤波示例 #define RSSI_ALPHA 0.3f static float rssi_filtered 0.0f; static uint8_t rssi_init_done 0; float rssi_update(float rssi_raw) { if (!rssi_init_done) { rssi_filtered rssi_raw; rssi_init_done 1; } else { rssi_filtered RSSI_ALPHA * rssi_raw (1.0f - RSSI_ALPHA) * rssi_filtered; } return rssi_filtered; }RSSI_ALPHA取值 0.3 是我在多个项目中试出来的折中值。它能让滤波结果在一两秒内跟上真实信号变化同时又滤掉了瞬时抖动。如果取值太小比如 0.1信号响应会非常迟钝用户把设备从客厅挪到路由器旁边App 端要好几分钟才更新信号格数体验很差如果取值太大比如 0.8滤波基本失效信号格会频繁跳动。还有一点要特别注意配网后 10 秒内的 RSSI 不能直接采。因为设备在刚完成连接时WiFi 射频和天线校准还没有完全稳定而且此时信道竞争比较激烈采到的值往往比稳定后低 5~10dBm。我们的做法是配网完成在线后延迟 10 秒再启动 RSSI 稳态采集否则很容易误判成“信号弱”。2.3 把 RSSI 信号强度映射成用户看得懂的信息原始 RSSI 是 dBm非技术用户看不懂。产品设计上需要做一层映射把 RSSI 转成百分比或者信号格数。Android 系统里信号格数的计算方法是逐级阈值判断这个思路可以直接借鉴。我们项目的映射策略分成两个维度信号百分比将 -30dBm 设为 100%-90dBm 设为 0%中间线性映射。信号等级提示分为强、中、弱、极弱四档用于 App 端提示语。// RSSI 转百分比 int rssi_to_percent(int rssi) { if (rssi -30) return 100; if (rssi -90) return 0; return (int)((rssi 90) * 100 / 60); } // RSSI 转等级 const char* rssi_to_level(int rssi) { if (rssi -55) return strong; if (rssi -65) return medium; if (rssi -75) return weak; return extremely_weak; }这里有一个经验教训信号格数千万不要做成线性五格。很多山寨产品把 -30dBm 到 -80dBm 平均分成五段结果就是用户看到设备永远只有两格信号即使把设备放在路由器旁边也一样体验感极差。真正合理的做法是参考手机系统的分段阈值让“满格”在 -50dBm 以上就能出现这样用户把设备靠近路由器后能看到明显反馈才愿意去调整摆放位置。3. 核心实现从配网触发到信号采集的全链路代码3.1 配网方式选型SmartConfig、SoftAP 和 BLE 配网对比配网方式的选择直接决定了状态机的复杂度和 RSSI 采集的姿势。我基于实际项目经验把几种常见方式做了个对比配网方式原理优点缺点适用场景SmartConfig手机 App 用特殊编码的 UDP 广播发送 WiFi 密码设备混杂模式监听操作简单配网速度快兼容性差部分路由器 AP 隔离下会失败乐鑫 ESP8266/ESP32 系列SoftAP设备开启热点手机连上设备热点后通过 HTTP 下发 WiFi 密码兼容性最好操作步骤多需要切换手机 WiFi全平台通吃最稳妥BLE 配网手机通过蓝牙将 WiFi 密码传给设备设备连接路由器后再回传结果交互体验最佳可同时采集 RSSI需要设备带蓝牙模块功耗成本增加带 BLE 的智能锁、传感器关于“ESP32 蓝牙和 WiFi 可以一起用吗”这个问题结论是可以但要注意共存问题。ESP32 的 BLE 和 WiFi 共用同一套 2.4G 射频前端软件上采用了时分复用机制如果 BLE 通信量大WiFi 的吞吐就会明显下降。我们在 BLE 配网时采用的是 BLE 只负责传密码和状态配网结果统一走 WiFi 通道回报BLE 在配网完成后立即断开连接释放资源这样能保证后续 WiFi 信号采集的稳定性。我个人更推荐 SoftAP 作为兜底方案。因为 SmartConfig 在小区宽带光猫、企业级 AP 这种开了 AP 隔离的网络里成功率很低而 BLE 配网又要求硬件支持。SoftAP 虽然操作繁琐但它不需要任何特殊网络环境支持任何一个能开热点的手机都能完成配网。3.2 配网后的三层连通性检测完成 WiFi 连接事件回调后代码里必须主动做三层验证不能只依赖驱动层的“连接成功”回调。下面是我们在正式产品中使用的检测顺序IP 层检测调用WiFi.localIP()判断 IP 是否为0.0.0.0如果为全零说明 DHCP 没成功。DNS 检测尝试用WiFi.dnsIP()读取 DNS 服务器地址如果返回空说明路由器下发配置不完整。应用层检测向云平台发起 MQTT 或 HTTPS 连接以实际业务通道建立成功为准。这段逻辑如果抽象成代码大致是bool check_network_online(int timeout_ms) { // 第一层确认 IP if (WiFi.localIP().toString() 0.0.0.0) { return false; } // 第二层确认 DNS if (WiFi.dnsIP().toString() 0.0.0.0) { return false; } // 第三层确认云连接 if (!mqtt_client.connected()) { return false; } return true; }这里我特别想强调第三层的重要性。很多开发者觉得“WiFi 连上就是配网成功”结果用户的路由器是好的、WiFi 也能连上但宽带欠费了外网不通。设备端如果不做应用层检测就会显示“配网成功”但 App 上设备永远离线用户完全不知道问题出在宽带还是设备。加上第三层检测后我们可以明确提示“设备已连上 WiFi但无法连接服务器请检查宽带”这个诊断对用户体验提升非常明显。3.3 RSSI 稳态采集模块的工程化细节配网完成后的 RSSI 采集不要直接放在主循环里裸奔。我们设计了一个独立的signal_monitor模块定时 5 秒采集一次原始 RSSI经过 EWMA 滤波后向下游模块发布稳定的信号等级事件。这个模块还要处理一个边界问题设备睡眠唤醒后以及网络切换时RSSI 需要重新进入稳定期。我们的策略是模块内部维护一个rssi_status枚举从CALIBRATING到STABLE未进入STABLE之前不对外发布信号等级事件。信号等级事件至少要携带四个信息滤波器输出的 RSSI 值单位 dBm映射后的百分比0~100信号等级strong/medium/weak/extremely_weak采样对应的 BSSID用于多 AP 环境下区分是哪个路由器我见过不少项目在日志里只打印“RSSI: -65”没有 BSSID结果用户家里有两个 SSID 相同的路由器时设备一会儿连 A 一会儿连 B信号跳来跳去根本无法定位问题。加上 BSSID 上报后一眼就能看出是不是设备在两个 AP 之间反复横跳。4. 现场排障实录我把配网环节常踩的坑都列出来4.1 手机热点和路由器同名设备连错了网络我们测试时遇到过一个特别经典的场景测试人员用手机开热点配网设备顺利连上App 也显示在线但没多久设备就掉线了。后来排查发现测试人员在办公室用手机开热点热点名称设成了和公司访客 WiFi 一样的名字。设备扫描到两个同名网络选择了信号更强的公司访客 WiFi用手机热点的密码去连公司 WiFi结果当然连不上连不上又回退到重启配网循环。这类问题的根因在于配网时设备必须同时校验 SSID 和 BSSID。SSID 是网络名字BSSID 是路由器 MAC 地址两台路由器名字可以一样但 BSSID 一定不同。我们后来在配网协议里增加了 BSSID 校验字段设备连接时只认用户选择的那个 BSSID彻底解决了同名热点误连的问题。4.2 信号强度突然跳变罪魁祸首是天线分集有段时间我们收到好几个用户反馈说设备信号“一会儿满格一会儿一格”但设备摆放位置根本没有动过。排查了很久最后发现是模组自带的天线分集功能在作祟。很多 WiFi 模组支持双天线分集系统会实时选择信号更好的那根天线两天天线的物理位置稍有差异就会导致 RSSI 读数在特定方向上出现明显跳变。解决方案是在固件中关闭天线分集或者将 RSSI 采样期间固定使用同一根天线。我们测试下来关闭分集后 RSSI 稳定性明显提升代价是极限弱信号环境下-80dBm 以下的稳定性会有轻微下降但整体收益远大于损失。4.3 配网成功但反复重连问题指向路由器安全设置另一个高频问题是设备配网时没问题但几分钟后 WiFi 断开然后反复重连。用抓包工具一看发现路由器在设备连接成功后不久就发送了DEAUTH帧把设备踢下线了。这种问题通常是路由器开启了弱信号踢除功能或者AP 隔离。弱信号踢除是路由器的一个省心功能当设备 RSSI 低于阈值时路由器主动断开设备连接避免占着信道资源不干活。但 IoT 设备往往是固定位置摆放信号虽然不是很好但足够稳定使用路由器一踢设备就要重新连接、重新获取 IP、重新连接云平台整个周期里用户感知就是“设备掉线了”。我们的应对策略分两步第一配网时如果检测到 RSSI 低于 -70dBm直接提示用户信号偏弱建议调整设备位置第二在设备固件里实现断线重连退避算法连续三次快速断线后延长重试间隔到 60 秒以上避免设备跟路由器较劲把自己“打死”了。4.4 5G 频段和双频合一路由器的坑当前主流的 IoT WiFi 模组大多只支持 2.4G 频段而现代路由器普遍支持双频合一也就是 2.4G 和 5G 使用同一个 SSID。问题在于手机连接时通常会优选 5G 频段而设备只能连 2.4G。当用户把从 App 里看到的“当前 WiFi 信息”下发给设备时如果下发的信息里包含了 5G 频段的 BSSID设备就会因为找不到对应信道而连接失败。处理方案是在配网协议中增加频段标识字段。App 端读取手机当前连接的 WiFi 信息时必须检查networkCapabilities里的频段信息如果当前是 5G 频段就要提示用户切换到 2.4G 频段再配网。双频合一路由器则建议在 App 内直接展示提示“如果配网失败请尝试关闭路由器的双频合一功能”。5. 从功能到体验信号相关功能的验收与产品化建议5.1 怎么验收 RSSI 相关功能距离-信号实测法RSSI 相关功能开发完了不能只靠功能测试必须做量化验收。我习惯的做法是在办公区模拟三种典型环境近距离无遮挡1 米、中距离隔一堵墙5 米、远距离隔两堵墙10 米。每个点位用手机的专业 WiFi 分析工具作为参照同时读取设备上报的 RSSI 值对比偏差是否在合理范围内。其中一个小技巧是手机横屏状态下 RSSI 读数会稳定很多。因为很多手机的握持姿势会影响天线方向进而影响 RSSI 读数测试时尽量减少握持带来的变量。Android 用户可以用系统自带的开发者选项里的“WiFi 扫描报告”功能或者第三方工具查看实时 RSSI。iOS 由于系统限制无法直接看到 dBm 值只能通过信号格间接判断所以验收主力机建议用 Android。5.2 RSSI 不是唯一指标组合判断才是王道单纯依赖 RSSI 判断网络质量还是会踩坑。比如一个环境里微波炉开着RSSI 读数可能是 -50dBm但 Wi-Fi 实际吞吐已经掉到只剩十分之一。因为微波炉工作在 2.4G 频段会产生强干扰而 RSSI 只能反映“收到信号的强度”不能反映“信道是否被噪声污染”。更可靠的做法是引入**信噪比SNR**辅助判断。SNR 表示信号与噪声的比值单位也是 dB。如果 RSSI 不低但 SNR 很低说明这个信道上噪声很大网络质量差。部分 WiFi 模组驱动可以读取噪声底噪noise floor进而计算 SNR。如果模组不支持也可以通过测试 TCP 往返时延和重传率来做间接判断。我们项目最终的信号质量评估是三层综合RSSI信号强度≥ -65dBmSNR ≥ 25dB丢包率 ≤ 1%只有这三项同时满足才判定为“信号优秀”。5.3 日志规范配网日志里必须打这些点最后说一个很实在的经验量产产品出了问题最怕的就是用户反馈“连不上”但设备端日志里什么都看不见。我们后来把配网日志固定为了一套标准格式每个节点都有唯一前缀线上问题时直接搜索前缀就能定位。一套完整的配网日志至少要包含以下信息设备 MAC 和固件版本触发配网的方式按键、蓝牙、App 指令扫描到的网络数量及各网络 SSID/BSSID/RSSI用户选中的网络信息SSID、BSSID、加密方式各状态迁移的时间和结果CONNECTING开始时间、OBTAINING_IP结束时间失败时的错误码和重试次数配网完成后的稳态 RSSI 和 SNR日志里每一步都加时间戳格式统一用[WIFI] 2024-06-01 12:00:00.123这种风格。线上用户反馈问题时只需要把设备端日志导出就能快速定位是用户密码问题、路由器问题还是设备天线问题。这是一笔前期投入小、后期排查效率提升巨大的投资。回到开头那句话配网在 IoT 产品里的地位就像地基之于高楼。RSSI 这个指标看起来只是一个小小的信号强度值但它直接决定了配网成功率、设备在线率、用户对产品的最初印象。我在实际项目中最大的体会是做配网功能千万不要只满足于“能连上”要主动去测量信号、展示信号、诊断信号把网络质量的信息完整地暴露出来。这样产品才能真正做到让用户“一次配网长期稳定”而不是把问题留给后端的几千条工单去处理。
IoT设备WiFi配网状态与RSSI信号强度：从能连到好用的关键
做 IoT 设备开发这几年我在配网环节踩过的坑比在业务逻辑里踩的还多。尤其是帮客户排查“设备明明配上网了却频繁掉线、响应慢、App 显示离线”这类问题时最后查来查去基本都指向同一个根源配网时只关心“连没连上”没关心“信号到底好不好”。标题里“WiFi 配网状态与 RSSI 信号强度”这个组合其实就是 IoT 产品从“能跑”到“好用”之间最容易被忽略的那道坎。这篇文章我打算从一次真实项目经历出发完整拆解配网状态机的设计思路、RSSI 信号强度的采集与滤波方法再把产品化过程中遇到的坑和排查手法一并整理出来。适合正在做智能家居、传感器网关、ESP32 类联网硬件以及负责设备端联网体验的嵌入式开发同学参考。整篇文章的核心就一句话配网成功只是起点RSSI 才是衡量这次配网到底能不能稳定用的关键指标。1. 重新理解“配网成功”不是连上路由器就万事大吉1.1 一次完整配网要经历的三层链路很多刚接触 IoT 开发的工程师对“配网成功”的理解停留在WiFi connected这个事件上。但实际上从设备上电到真正可以云平台通信中间要经过三层验证第一层设备与路由器完成握手拿到 BSSID、信道、加密方式这一层叫“链路层通”。第二层设备通过 DHCP 拿到 IP 地址能够与局域网内其他设备互通这一层叫“网络层通”。第三层设备通过 TCP/TLS 连接上云平台完成鉴权和注册这一层叫“应用层通”。只有三层全部走通才算真正意义上的“配网成功”。我们项目里最初犯过的错误就是只检测了第一层就弹窗告诉用户“配置成功”结果大量设备卡在 DHCP 阶段用户以为是路由器问题其实是设备端根本没有把状态机设计完整。所以后来我们重新定义了配网状态至少拆成以下六个状态状态含义触发条件IDLE待配网设备上电无有效 WiFi 配置SCANNING扫描中进入配网模式触发周边网络扫描CONNECTING连接中拿到用户选择的热点信息发起连接OBTAINING_IP获取 IPWiFi 已关联开始 DHCP 请求CLOUD_CONNECTING云连接中IP 获取成功开始连接云平台ONLINE在线云平台连接成功心跳上报正常所有状态都要有超时时间超时后自动回到 IDLE 或进入错误提示分支。比如CONNECTING状态下 15 秒没有触发OBTAINING_IP就直接抛出“密码错误或信号太弱”的错误码而不是让用户干等。1.2 RSSI 信号强度在这条链路上的作用被低估了RSSI 全称 Received Signal Strength Indicator接收信号强度指示单位是 dBm。由于它是个负值很多人看不太习惯。简单记住一个对照经验就够了-30dBm ~ -50dBm信号极好贴近路由器几乎所有速率都能跑满。-50dBm ~ -60dBm信号良好日常使用基本无感。-60dBm ~ -70dBm信号一般丢包开始出现视频会卡顿。-70dBm ~ -80dBm信号较差连接能维持但重传率高响应延迟明显。-80dBm 以下信号极差随时可能断开基本不可用。RSSI 在配网链路中的作用远远不止是“显示几格信号”。我们实测过一个场景设备放在客厅路由器在卧室中间隔了两堵承重墙。手机 App 显示 WiFi 信号满格因为它站在设备旁边而设备端扫描到的路由器 RSSI 只有 -76dBm。用户按照手机信号满格的预期去判断自然觉得“路由器没问题是设备有问题”。所以我们在配网流程里强制加了一步设备选完热点后先上报扫描到的 RSSI 值如果低于阈值直接弹窗提醒用户“当前信号较弱建议将设备靠近路由器”。这一步把因信号问题导致的配网失败率直接降了差不多四成。RSSI 不是锦上添花的功能而是配网体验里的第一道质量闸门。2. 配网状态机的完整设计与 RSSI 采集方案2.1 状态机迁移细节让每个状态都“可观测、可干预”设计配网状态机时我喜欢把“可观测”放在第一位。所谓可观测就是每个状态都要有明确的进入条件、退出条件、超时时间以及对应的日志输出。你可以把这套状态机跑起来后通过串口日志就能像看电影一样看出设备当前卡在哪一步。我们项目里具体的迁移逻辑大致是这样的设备首次上电Flash 中没有保存任何 WiFi 配置进入IDLE状态。用户按下配网键或设备自动进入配网模式进入SCANNING状态开始扫描周边网络。扫描结果通过蓝牙或 SoftAP 通道回传给手机 App用户选择要连接的热点并输入密码。设备收到密码后进入CONNECTING状态调用 WiFi 库发起连接。连接成功拿到 BSSID、信道后立即进入OBTAINING_IP状态等待 DHCP 分配地址。IP 获取成功进入CLOUD_CONNECTING状态尝试连接云平台。云平台返回注册成功进入ONLINE状态配网流程结束。每个状态都配备一个超时定时器CONNECTING和OBTAINING_IP建议设 15~20 秒CLOUD_CONNECTING建议设 10 秒。超过时间后设备要主动上报当前状态码并回到IDLE等待用户重试。这里有一个容易被忽略的点用户输入密码错误和信号太弱表现出来的现象可能是一模一样的——连接超时。为了区分这两类问题我们会在CONNECTING期间持续记录 WiFi 库回调的错误码以及重试次数最终将诊断信息一并上报到 App 端。2.2 RSSI 单次采样不可信必须做滤波处理RSSI 这个值有一个特点即使设备静止不动相邻两次采样结果也会跳动幅度通常在 ±5dBm 左右如果在有人走动、微波炉工作等环境里抖动会更夸张。如果直接把原始 RSSI 拿来判断信号等级、触发告警几乎一定会出现误报。我们常用的方案是指数加权移动平均EWMA。它不像算术平均那样需要存一堆历史样本而是用一个递归公式对新的采样值做平滑计算复杂度非常低放在中断里跑都没问题。// EWMA 滤波示例 #define RSSI_ALPHA 0.3f static float rssi_filtered 0.0f; static uint8_t rssi_init_done 0; float rssi_update(float rssi_raw) { if (!rssi_init_done) { rssi_filtered rssi_raw; rssi_init_done 1; } else { rssi_filtered RSSI_ALPHA * rssi_raw (1.0f - RSSI_ALPHA) * rssi_filtered; } return rssi_filtered; }RSSI_ALPHA取值 0.3 是我在多个项目中试出来的折中值。它能让滤波结果在一两秒内跟上真实信号变化同时又滤掉了瞬时抖动。如果取值太小比如 0.1信号响应会非常迟钝用户把设备从客厅挪到路由器旁边App 端要好几分钟才更新信号格数体验很差如果取值太大比如 0.8滤波基本失效信号格会频繁跳动。还有一点要特别注意配网后 10 秒内的 RSSI 不能直接采。因为设备在刚完成连接时WiFi 射频和天线校准还没有完全稳定而且此时信道竞争比较激烈采到的值往往比稳定后低 5~10dBm。我们的做法是配网完成在线后延迟 10 秒再启动 RSSI 稳态采集否则很容易误判成“信号弱”。2.3 把 RSSI 信号强度映射成用户看得懂的信息原始 RSSI 是 dBm非技术用户看不懂。产品设计上需要做一层映射把 RSSI 转成百分比或者信号格数。Android 系统里信号格数的计算方法是逐级阈值判断这个思路可以直接借鉴。我们项目的映射策略分成两个维度信号百分比将 -30dBm 设为 100%-90dBm 设为 0%中间线性映射。信号等级提示分为强、中、弱、极弱四档用于 App 端提示语。// RSSI 转百分比 int rssi_to_percent(int rssi) { if (rssi -30) return 100; if (rssi -90) return 0; return (int)((rssi 90) * 100 / 60); } // RSSI 转等级 const char* rssi_to_level(int rssi) { if (rssi -55) return strong; if (rssi -65) return medium; if (rssi -75) return weak; return extremely_weak; }这里有一个经验教训信号格数千万不要做成线性五格。很多山寨产品把 -30dBm 到 -80dBm 平均分成五段结果就是用户看到设备永远只有两格信号即使把设备放在路由器旁边也一样体验感极差。真正合理的做法是参考手机系统的分段阈值让“满格”在 -50dBm 以上就能出现这样用户把设备靠近路由器后能看到明显反馈才愿意去调整摆放位置。3. 核心实现从配网触发到信号采集的全链路代码3.1 配网方式选型SmartConfig、SoftAP 和 BLE 配网对比配网方式的选择直接决定了状态机的复杂度和 RSSI 采集的姿势。我基于实际项目经验把几种常见方式做了个对比配网方式原理优点缺点适用场景SmartConfig手机 App 用特殊编码的 UDP 广播发送 WiFi 密码设备混杂模式监听操作简单配网速度快兼容性差部分路由器 AP 隔离下会失败乐鑫 ESP8266/ESP32 系列SoftAP设备开启热点手机连上设备热点后通过 HTTP 下发 WiFi 密码兼容性最好操作步骤多需要切换手机 WiFi全平台通吃最稳妥BLE 配网手机通过蓝牙将 WiFi 密码传给设备设备连接路由器后再回传结果交互体验最佳可同时采集 RSSI需要设备带蓝牙模块功耗成本增加带 BLE 的智能锁、传感器关于“ESP32 蓝牙和 WiFi 可以一起用吗”这个问题结论是可以但要注意共存问题。ESP32 的 BLE 和 WiFi 共用同一套 2.4G 射频前端软件上采用了时分复用机制如果 BLE 通信量大WiFi 的吞吐就会明显下降。我们在 BLE 配网时采用的是 BLE 只负责传密码和状态配网结果统一走 WiFi 通道回报BLE 在配网完成后立即断开连接释放资源这样能保证后续 WiFi 信号采集的稳定性。我个人更推荐 SoftAP 作为兜底方案。因为 SmartConfig 在小区宽带光猫、企业级 AP 这种开了 AP 隔离的网络里成功率很低而 BLE 配网又要求硬件支持。SoftAP 虽然操作繁琐但它不需要任何特殊网络环境支持任何一个能开热点的手机都能完成配网。3.2 配网后的三层连通性检测完成 WiFi 连接事件回调后代码里必须主动做三层验证不能只依赖驱动层的“连接成功”回调。下面是我们在正式产品中使用的检测顺序IP 层检测调用WiFi.localIP()判断 IP 是否为0.0.0.0如果为全零说明 DHCP 没成功。DNS 检测尝试用WiFi.dnsIP()读取 DNS 服务器地址如果返回空说明路由器下发配置不完整。应用层检测向云平台发起 MQTT 或 HTTPS 连接以实际业务通道建立成功为准。这段逻辑如果抽象成代码大致是bool check_network_online(int timeout_ms) { // 第一层确认 IP if (WiFi.localIP().toString() 0.0.0.0) { return false; } // 第二层确认 DNS if (WiFi.dnsIP().toString() 0.0.0.0) { return false; } // 第三层确认云连接 if (!mqtt_client.connected()) { return false; } return true; }这里我特别想强调第三层的重要性。很多开发者觉得“WiFi 连上就是配网成功”结果用户的路由器是好的、WiFi 也能连上但宽带欠费了外网不通。设备端如果不做应用层检测就会显示“配网成功”但 App 上设备永远离线用户完全不知道问题出在宽带还是设备。加上第三层检测后我们可以明确提示“设备已连上 WiFi但无法连接服务器请检查宽带”这个诊断对用户体验提升非常明显。3.3 RSSI 稳态采集模块的工程化细节配网完成后的 RSSI 采集不要直接放在主循环里裸奔。我们设计了一个独立的signal_monitor模块定时 5 秒采集一次原始 RSSI经过 EWMA 滤波后向下游模块发布稳定的信号等级事件。这个模块还要处理一个边界问题设备睡眠唤醒后以及网络切换时RSSI 需要重新进入稳定期。我们的策略是模块内部维护一个rssi_status枚举从CALIBRATING到STABLE未进入STABLE之前不对外发布信号等级事件。信号等级事件至少要携带四个信息滤波器输出的 RSSI 值单位 dBm映射后的百分比0~100信号等级strong/medium/weak/extremely_weak采样对应的 BSSID用于多 AP 环境下区分是哪个路由器我见过不少项目在日志里只打印“RSSI: -65”没有 BSSID结果用户家里有两个 SSID 相同的路由器时设备一会儿连 A 一会儿连 B信号跳来跳去根本无法定位问题。加上 BSSID 上报后一眼就能看出是不是设备在两个 AP 之间反复横跳。4. 现场排障实录我把配网环节常踩的坑都列出来4.1 手机热点和路由器同名设备连错了网络我们测试时遇到过一个特别经典的场景测试人员用手机开热点配网设备顺利连上App 也显示在线但没多久设备就掉线了。后来排查发现测试人员在办公室用手机开热点热点名称设成了和公司访客 WiFi 一样的名字。设备扫描到两个同名网络选择了信号更强的公司访客 WiFi用手机热点的密码去连公司 WiFi结果当然连不上连不上又回退到重启配网循环。这类问题的根因在于配网时设备必须同时校验 SSID 和 BSSID。SSID 是网络名字BSSID 是路由器 MAC 地址两台路由器名字可以一样但 BSSID 一定不同。我们后来在配网协议里增加了 BSSID 校验字段设备连接时只认用户选择的那个 BSSID彻底解决了同名热点误连的问题。4.2 信号强度突然跳变罪魁祸首是天线分集有段时间我们收到好几个用户反馈说设备信号“一会儿满格一会儿一格”但设备摆放位置根本没有动过。排查了很久最后发现是模组自带的天线分集功能在作祟。很多 WiFi 模组支持双天线分集系统会实时选择信号更好的那根天线两天天线的物理位置稍有差异就会导致 RSSI 读数在特定方向上出现明显跳变。解决方案是在固件中关闭天线分集或者将 RSSI 采样期间固定使用同一根天线。我们测试下来关闭分集后 RSSI 稳定性明显提升代价是极限弱信号环境下-80dBm 以下的稳定性会有轻微下降但整体收益远大于损失。4.3 配网成功但反复重连问题指向路由器安全设置另一个高频问题是设备配网时没问题但几分钟后 WiFi 断开然后反复重连。用抓包工具一看发现路由器在设备连接成功后不久就发送了DEAUTH帧把设备踢下线了。这种问题通常是路由器开启了弱信号踢除功能或者AP 隔离。弱信号踢除是路由器的一个省心功能当设备 RSSI 低于阈值时路由器主动断开设备连接避免占着信道资源不干活。但 IoT 设备往往是固定位置摆放信号虽然不是很好但足够稳定使用路由器一踢设备就要重新连接、重新获取 IP、重新连接云平台整个周期里用户感知就是“设备掉线了”。我们的应对策略分两步第一配网时如果检测到 RSSI 低于 -70dBm直接提示用户信号偏弱建议调整设备位置第二在设备固件里实现断线重连退避算法连续三次快速断线后延长重试间隔到 60 秒以上避免设备跟路由器较劲把自己“打死”了。4.4 5G 频段和双频合一路由器的坑当前主流的 IoT WiFi 模组大多只支持 2.4G 频段而现代路由器普遍支持双频合一也就是 2.4G 和 5G 使用同一个 SSID。问题在于手机连接时通常会优选 5G 频段而设备只能连 2.4G。当用户把从 App 里看到的“当前 WiFi 信息”下发给设备时如果下发的信息里包含了 5G 频段的 BSSID设备就会因为找不到对应信道而连接失败。处理方案是在配网协议中增加频段标识字段。App 端读取手机当前连接的 WiFi 信息时必须检查networkCapabilities里的频段信息如果当前是 5G 频段就要提示用户切换到 2.4G 频段再配网。双频合一路由器则建议在 App 内直接展示提示“如果配网失败请尝试关闭路由器的双频合一功能”。5. 从功能到体验信号相关功能的验收与产品化建议5.1 怎么验收 RSSI 相关功能距离-信号实测法RSSI 相关功能开发完了不能只靠功能测试必须做量化验收。我习惯的做法是在办公区模拟三种典型环境近距离无遮挡1 米、中距离隔一堵墙5 米、远距离隔两堵墙10 米。每个点位用手机的专业 WiFi 分析工具作为参照同时读取设备上报的 RSSI 值对比偏差是否在合理范围内。其中一个小技巧是手机横屏状态下 RSSI 读数会稳定很多。因为很多手机的握持姿势会影响天线方向进而影响 RSSI 读数测试时尽量减少握持带来的变量。Android 用户可以用系统自带的开发者选项里的“WiFi 扫描报告”功能或者第三方工具查看实时 RSSI。iOS 由于系统限制无法直接看到 dBm 值只能通过信号格间接判断所以验收主力机建议用 Android。5.2 RSSI 不是唯一指标组合判断才是王道单纯依赖 RSSI 判断网络质量还是会踩坑。比如一个环境里微波炉开着RSSI 读数可能是 -50dBm但 Wi-Fi 实际吞吐已经掉到只剩十分之一。因为微波炉工作在 2.4G 频段会产生强干扰而 RSSI 只能反映“收到信号的强度”不能反映“信道是否被噪声污染”。更可靠的做法是引入**信噪比SNR**辅助判断。SNR 表示信号与噪声的比值单位也是 dB。如果 RSSI 不低但 SNR 很低说明这个信道上噪声很大网络质量差。部分 WiFi 模组驱动可以读取噪声底噪noise floor进而计算 SNR。如果模组不支持也可以通过测试 TCP 往返时延和重传率来做间接判断。我们项目最终的信号质量评估是三层综合RSSI信号强度≥ -65dBmSNR ≥ 25dB丢包率 ≤ 1%只有这三项同时满足才判定为“信号优秀”。5.3 日志规范配网日志里必须打这些点最后说一个很实在的经验量产产品出了问题最怕的就是用户反馈“连不上”但设备端日志里什么都看不见。我们后来把配网日志固定为了一套标准格式每个节点都有唯一前缀线上问题时直接搜索前缀就能定位。一套完整的配网日志至少要包含以下信息设备 MAC 和固件版本触发配网的方式按键、蓝牙、App 指令扫描到的网络数量及各网络 SSID/BSSID/RSSI用户选中的网络信息SSID、BSSID、加密方式各状态迁移的时间和结果CONNECTING开始时间、OBTAINING_IP结束时间失败时的错误码和重试次数配网完成后的稳态 RSSI 和 SNR日志里每一步都加时间戳格式统一用[WIFI] 2024-06-01 12:00:00.123这种风格。线上用户反馈问题时只需要把设备端日志导出就能快速定位是用户密码问题、路由器问题还是设备天线问题。这是一笔前期投入小、后期排查效率提升巨大的投资。回到开头那句话配网在 IoT 产品里的地位就像地基之于高楼。RSSI 这个指标看起来只是一个小小的信号强度值但它直接决定了配网成功率、设备在线率、用户对产品的最初印象。我在实际项目中最大的体会是做配网功能千万不要只满足于“能连上”要主动去测量信号、展示信号、诊断信号把网络质量的信息完整地暴露出来。这样产品才能真正做到让用户“一次配网长期稳定”而不是把问题留给后端的几千条工单去处理。