上一篇文章我们把 ESP-NOW 从零跑通了一条单向链路A 板发送、B 板接收串口把数据打出来。那块 demo 板放在桌面上闪着灯看起来一切正常。但真正把这个协议往一个实际项目里放的时候你会发现单向发送只是把大象的一只脚摸清了。这篇文章继续聊 ESP-NOW 的第二轮实战双向确认、一对多拓扑、可靠性设计以及低功耗节点怎么在 Deep Sleep 唤醒后快速完成一次收发。目标是让已经跑过基础 demo 的开发者能直接把 ESP-NOW 用到具备完整功能的场景里智能开关要回传状态传感器节点要确认网关收到数据电池供电的采集端要能在低功耗模式下稳定工作。如果你正准备做这类事情这篇文章里的代码、时序和踩坑记录可以直接拿过去改改就上。1. 双向通信的硬需求发出去不代表送到业务层必须自己握手1.1 单向 demo 的盲区send 成功只代表帧已上射频Part 1 的例子里发送端通常就是循环调用esp_now_send()然后看返回ESP_OK就觉得发出去了。接收端回调一打数据出来了demo 就算完成。但这里藏着一个很多人没意识到的坑esp_now_send()返回ESP_OK只代表帧已经成功交给 Wi-Fi 硬件发送并不代表接收端真的收到了更不代表接收端处理成功了。我们做个实验就能验证把接收端断电发送端继续调用esp_now_send()返回值大概率还是ESP_OK。只有在注册了发送回调esp_now_send_cb_t之后你才会收到一个status可能是ESPNOW_SEND_SUCCESS也可能是ESPNOW_SEND_FAIL。但即使收到ESPNOW_SEND_SUCCESS它也只说明这帧数据在空口上被成功发送了对方有没有正确处理协议层给不了答案。这不是 ESP-NOW 的偷懒而是所有无连接无线协议的共性。就像你往楼下喊了一嗓子声音确实出去了但对方到底听见没有、听懂没有你得等他回一句话才知道。所以只要业务上需要确认对方确实收到并且处理成功了就必须在应用层自己做一套请求-应答机制。1.2 请求-应答模型实现一个带 ACK 的远程控制帧最简单的可靠通信模型就是模仿网络协议里最经典的 ACK 机制A 给 B 发一条命令帧B 收到后立刻回一条 ACK 帧A 收到 ACK 才认为这次发送真正完成了。以 Arduino-ESP32 框架为例我实际项目里用到的双向通信骨架大概是这样的。先定义消息类型和数据结构typedef enum { MSG_TYPE_CMD 0, MSG_TYPE_ACK, MSG_TYPE_DATA } msg_type_t; typedef struct { uint8_t type; // msg_type_t uint8_t seq; // 序列号ACK 回同一序列号 uint8_t cmd; // 命令字比如 0x01 开灯 uint8_t reserved; uint32_t timestamp; // 发送端时间戳 } control_frame_t; // 对端设备的 MAC 地址 uint8_t peer_mac[6] {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};初始化 ESP-NOW 并添加对端这部分要做的准备比 Part 1 多一些我一般会把初始化封装成一个函数void espnow_init_bidirectional() { WiFi.mode(WIFI_STA); // ESP-NOW 在 STA 模式下工作最稳定 WiFi.disconnect(); if (esp_now_init() ! ESP_OK) { Serial.println(esp_now init failed); return; } esp_now_register_send_cb(espnow_send_cb); esp_now_register_recv_cb(espnow_recv_cb); esp_now_peer_info_t peer {}; memcpy(peer.peer_addr, peer_mac, 6); peer.channel 1; // 信道必须与对端一致 peer.encrypt false; // 裸传输后面可以开加密 esp_now_add_peer(peer); }发送端维护一个简单的状态命令发出去之后等待对应的 ACK 回来超时再重发。核心逻辑大致如下uint8_t current_seq 0; bool ack_received false; unsigned long last_send_time 0; void send_cmd_with_ack(uint8_t cmd) { control_frame_t frame; frame.type MSG_TYPE_CMD; frame.seq current_seq; frame.cmd cmd; frame.timestamp millis(); ack_received false; esp_now_send(peer_mac, (uint8_t *)frame, sizeof(frame)); last_send_time millis(); // 等待 ACK超时 500ms while (!ack_received millis() - last_send_time 500) { delay(10); } } void espnow_send_cb(const uint8_t *mac_addr, esp_now_send_status_t status) { // 这里只能判断这帧是否成功发出不能判断业务 ACK if (status ! ESPNOW_SEND_SUCCESS) { Serial.println(send failed at RF level); } } void espnow_recv_cb(const uint8_t *mac_addr, const uint8_t *data, int data_len) { if (data_len ! sizeof(control_frame_t)) return; control_frame_t *rx (control_frame_t *)data; if (rx-type MSG_TYPE_CMD) { // 收到命令先回 ACK control_frame_t ack; ack.type MSG_TYPE_ACK; ack.seq rx-seq; ack.cmd rx-cmd; ack.timestamp rx-timestamp; esp_now_send(mac_addr, (uint8_t *)ack, sizeof(ack)); // 再执行具体命令 if (rx-cmd 0x01) { // 开灯 } } else if (rx-type MSG_TYPE_ACK) { if (rx-seq current_seq) { ack_received true; } } }这段代码的关键在于 ACK 里回带了序列号seq。如果不带序列号发送端无法分辨这个 ACK 是回应哪一条命令的特别是在连续快速发送多条命令时ACK 串了会导致状态错乱。加一个seq字段成本只有 1 字节换来的是通信状态可追踪。1.3 底层 ACK 与应用层 ACK 的边界快递回执与内容验收有个问题经常被问到ESP-NOW 协议本身不是有 ACK 吗为什么还要应用层再做一套 ACK没错默认情况下 ESP-NOW 在数据链路层是会做 ACK 的也就是每帧数据发出后对端 Wi-Fi 硬件收到会回一个链路层确认。这也是为什么esp_now_send_cb里能拿到ESPNOW_SEND_SUCCESS或ESPNOW_SEND_FAIL。但链路层 ACK 只说明帧被对端网卡收到了不能说明对端应用层处理成功了。比如接收端收到帧后在回调里解析失败、业务逻辑报错或者设备只剩 1% 电量收到数据但没来得及保存就关机了这些情况链路层 ACK 统统不知道。拿生活类比就是快递物流显示已签收但包裹里的东西是坏的、或者签收人根本不在家物流系统不会管。应用层 ACK 就是让你在业务层面确认收到的是对的东西。实际项目里链路层 ACK 通常用来判断是否需要重发整帧应用层 ACK 用来判断业务是否完成。多层确认各管各的两者结合才能构建出可靠的通信链路。对于大多数传感器上报场景链路层 ACK 加上超时重试就够了但涉及控制类命令、状态变更、固件参数下发这类必须确保执行的场景应用层 ACK 不能省。2. 一对多组网广播唤不醒特定设备伪组播才是常态2.1 广播地址 FF:FF:FF:FF:FF:FF 的边界集体唤醒可以精准控制不行ESP-NOW 支持广播地址就是FF:FF:FF:FF:FF:FF。发送端不需要为广播地址添加 peer直接调用esp_now_send就能把帧发出去所有处于同一信道、支持 ESP-NOW 的设备都能收到。这个机制在特定场景下非常香批量唤醒。比如几十个低功耗传感器节点都在 Deep Sleep网关想告诉它们现在开始上报用单播就得一个个发频次低、耗时长用广播一条指令出去所有节点同时醒来效率高得多。但广播的缺点也突出无法精准控制没有对端 ACK。你在esp_now_send_cb里回调拿到ESPNOW_SEND_SUCCESS那只是说广播帧在空口被发出去了至于这一个包有几个设备收到一个都没有还是全部收到回调不告诉你。而且广播帧还会占用大量空口时间低速率下尤其明显。我在一个 30 节点的测试环境里试过如果所有节点都用广播做业务数据上报冲突率会高到离谱丢包率直接可以到 10% 以上。所以广播的定位就一句话适合通知、唤醒、时间同步不适合业务数据确认。业务数据要可靠送达得走下面的伪组播方案。2.2 多 peer 逐个单播和目标 ID 过滤两种伪组播的实际取舍ESP-NOW 没有一个组播组的概念但实际项目里经常需要发给多个设备。我实践中常用两种方式来模拟组播。第一种方式手动维护一张 peer 列表需要发送时逐个单播。这个方法可靠性最高因为每一条单播都有独立的发送状态回调能逐个确认。代价是空中占用线性上升10 个设备就是 10 帧20 个就是 20 帧。如果设备数量少、数据重要就选这个。第二种方式一帧数据里带上目标设备 ID接收端收到后先检查 ID不是自己的就丢弃。这种方式在空中仍然是一次广播或一次单播但接收端增加了过滤层。设备 ID 可以是设备编号、设备类型、或者分组 ID。比如我可以定义group_id0x01表示客厅设备广播帧里带上group_id0x01只有客厅设备处理卧室设备直接丢弃。两种方案放一起对比方案能否逐个确认到达空中开销实现复杂度适合场景多 peer 逐个单播可以每帧有独立回调O(n)n 为设备数量低循环调用即可控制命令、固件参数下发目标 ID 过滤取决于发送方式广播则不能确认O(1)一次广播中需要维护 ID 表分组通知、批量配置混用关键设备单播其余广播视混合比例较高大群组重点保障实际项目里我更推荐混用网关给一组设备同步参数用广播带group_id的方式效率高重要控制指令比如窗帘电机、门锁这类必须到达的设备用单播并等待 ACK。2.3 信道一致性所有节点必须坐进同一个频段房间ESP-NOW 是基于 Wi-Fi 帧的所以信道一致性是硬约束。节点在信道 1对端在信道 6无论你调用多少次esp_now_send对方都收不到。这里有一个很容易忽略的坑如果设备同时连着路由器信道是跟随路由器的。某些路由器的 2.4GHz 频段有自动信道优化功能可能在某个时间点忽然切换信道比如从 1 跳到 11。对普通网页访问来说这个切换影响不大终端会自动重连但对 ESP-NOW 来说设备信道变了另外一端还停在老信道两边就直接失联了而且这种失联在日志上没有任何报错非常难排查。我的建议是所有 ESP-NOW 设备在使用期间显式固定信道在初始化阶段调用esp_wifi_set_channel(1, WIFI_SECOND_CHAN_NONE);如果同一环境里还有别的 Wi-Fi 网络要共存固定信道前先做个现场勘查选一个干扰最小的信道通常 1、6、11 三选一。别依赖路由器的自动信道也别相信所有设备默认会落在同一信道。3. 可靠性三件套超时重传、序列号去重、上报错峰3.1 实测丢包率从几乎为 0到惨不忍睹只隔一个干扰源ESP-NOW 在理想环境下确实很稳定。两块板子放同一张桌子距离半米周围没有其他 Wi-Fi 设备我一小时发 3600 帧丢包率为 0。但一旦场景变成现实环境情况就急转直下隔一堵墙丢包率开始有小数点旁边放一个 USB 3.0 硬盘盒在传数据丢包率能冲到 3% 以上如果几个 ESP-NOW 节点同时高频发送互相碰撞导致的丢包率会更高。为什么因为 2.4GHz 这个频段太拥挤了。Wi-Fi、蓝牙、Zigbee、微波炉都在这个频段附近而 ESP-NOW 没有 CSMA/CA 那种强冲突避让机制发送前虽然会做空闲检测但多节点同时发送的概率还是不低。再加上 ESP-NOW 默认速率在 1Mbps 到 11Mbps 之间低速率意味着每帧在空中占用时间长碰撞窗口就更大。所以做 ESP-NOW 项目我从来不敢赌丢包率很低不用做重传。设计通信协议时一定要把重传、去重、错峰这三件事一起考虑进去。3.2 重传状态机指数退避和随机抖动缺一不可重传不能简单粗暴地没收到就再发一次。如果发送端和接收端之间持续存在干扰盲目重传只会让空口更拥塞形成恶性循环。我用的是一个带指数退避的轻量状态机。const int MAX_RETRY 5; const unsigned long BASE_TIMEOUT 100; // 初始超时 100ms const unsigned long MAX_TIMEOUT 1000; // 最大超时 1s int retry_count 0; unsigned long timeout_ms; void send_with_retry() { retry_count 0; timeout_ms BASE_TIMEOUT; send_frame(); } void on_ack_received() { retry_count 0; // 收到 ACK重置状态 timeout_ms BASE_TIMEOUT; } void on_timeout() { if (retry_count MAX_RETRY) { // 彻底失败告诉业务层这次发送失败 mark_transmission_failed(); return; } retry_count; timeout_ms * 2; // 指数退避 // 加随机抖动避免多个节点在相同时刻一起重发 timeout_ms random(0, 50); send_frame(); }这里有个细节每次重发要重新生成一个新的seq值不能沿用旧的。因为对端可能早就收到第一帧了只是 ACK 丢了你重发一个相同seq的帧对端在去重表里发现已经处理过可能直接丢弃然后你的 ACK 还是不会回来白白浪费一次重试。改用新seq对端就会认为这是新消息重新处理并回 ACK。还有超时时间从 100ms 起步是我测试下来比较合理的值。ESP-NOW 一帧在空口的传输时间非常短正常 100ms 内 ACK 肯定回来了。如果 100ms 没回来大概率是信道有问题或对端不在线这时候继续死等没有意义直接进入退避重试更高效。3.3 去重表重传带来的副作用必须用序列号消掉有了重传机制接收端就一定存在收到重复帧的可能。如果接收端收到重复的开灯命令再执行一次开灯灯不会坏但如果是收到重复的切换继电器状态命令继电器就会来回翻转整个系统直接逻辑混乱。去重的做法不复杂维护一张最近收到的帧记录表(源 MAC、序列号、收到时间)。每条新帧进来先查表命中就丢弃未命中就加入表。表里记录设置了超时时间一般 5 到 10 秒就清理一遍防止表被撑爆。typedef struct { uint8_t mac[6]; uint8_t seq; unsigned long last_time; bool used; } dedup_entry_t; dedup_entry_t dedup_table[32]; bool is_duplicate(uint8_t *mac, uint8_t seq) { unsigned long now millis(); for (int i 0; i 32; i) { if (dedup_table[i].used now - dedup_table[i].last_time 10000) { dedup_table[i].used false; // 过期清理 } } for (int i 0; i 32; i) { if (dedup_table[i].used memcmp(dedup_table[i].mac, mac, 6) 0 dedup_table[i].seq seq) { return true; } } // 写入新条目 for (int i 0; i 32; i) { if (!dedup_table[i].used) { memcpy(dedup_table[i].mac, mac, 6); dedup_table[i].seq seq; dedup_table[i].last_time now; dedup_table[i].used true; break; } } return false; }注意一个实际问题ESP32 的序列号是 8 位uint8_t最多 256 个值。如果发送端发得很快接收端表里可能还留着某个seq的记录但发送端已经循环用到相同seq了。这种极端情况碰撞概率极低但设计严格的系统可以把seq扩展到 16 位或者加上时间戳一起校验。对于大多数场景8 位序列号加 10 秒过期清理已经完全够用。3.4 多对一上报的拥塞控制让每个节点学会排队一对多和广播解决了怎么同时给一批设备发指令的问题反过来还有另一个方向的问题多个传感器节点同时向网关上报数据。这个问题在很多 ESP-NOW 教程里被忽略了但实际项目里它是丢包重灾区。20 个传感器如果都设置成每 60 秒上报一次各位可以发现一个诡异的现象所有节点几乎在同一时刻醒来因为定时器都是从整点开始算的然后一窝蜂挤着发送。结果就是空口瞬间冲突爆炸大量帧丢失触发重传重传再次同频碰撞形成所谓重传风暴。解法也很直接上报时间加随机偏移。我习惯在每个节点启动时生成一个 0 到 1000ms 的随机延迟存储到 RTC 内存里每次上报时先等这个延迟再发。更进一步可以让网关在广播时间同步包时顺手为每个节点分配不同的上报时隙类似 TDMA 的思路。虽然精度不高但足以让各节点错开碰撞窗口。对单节点来说这个改动只是加了一行delay(random(0, 1000))但整个系统的收包成功率能提升一个级别这个优化性价比极高。4. Deep Sleep 唤醒后快速收发低功耗节点的完整时序4.1 唤醒后重新建立 ESP-NOW 链路的正确顺序电池供电的采集节点设计上几乎都会用 Deep Sleep每隔几分钟醒来一次采集数据、发送、再睡。这里有个很多人踩过的坑从 Deep Sleep 醒来后Wi-Fi 和 ESP-NOW 是需要重新初始化的不能直接调用esp_now_send。如果省略初始化大概率得到ESP_ERR_ESPNOW_NOT_INIT之类的错误。正确的初始化顺序是esp_wifi_init(wifi_config); // 配置 STA 模式 esp_wifi_set_storage(WIFI_STORAGE_RAM); esp_wifi_start(); esp_wifi_set_channel(CHANNEL, WIFI_SECOND_CHAN_NONE); esp_now_init(); esp_now_add_peer(peer);先把 Wi-Fi 拉起来再初始化 ESP-NOW再添加对端。有的例程里是先用esp_wifi_start、再用esp_now_init顺序反了就会 init 失败。这个顺序问题在 ESP-IDF 里尤其严格Arduino 框架因为封装了esp_now_begin()内部帮你处理了一部分但我们做低功耗程序时经常直接操作底层 API习惯了严格顺序能少踩很多坑。4.2 先发数据再等 ACK最省功耗的收发时序设计低功耗节点的黄金法则是能睡就睡醒来越短越好。所以唤醒后的流程在设计上要尽量精简。我优化过无数遍的流程是唤醒初始化 Wi-Fi 和 ESP-NOW立刻发送上报帧等待 ACK超时重试 1 到 3 次无论成败直接进入 Deep Sleep注意等待 ACK 不能用delay死等那样会浪费大部分唤醒时间。正确做法是用状态机配合超时计时让 ACK 回调在中断上下文之外第一时间处理。如果在等待 ACK 期间没有收到超时后立即重发重试两三次仍然没有 ACK说明对端不在线或信号太差继续耗着只会耗电果断入睡等下一个周期。这里我实测过的功耗数据可以给大家参考。ESP32 系列在 Deep Sleep 模式下电流大约 5 到 10 微安取决于外围电路。唤醒后 Wi-Fi 初始化加发送一帧数据整个过程大约 30 到 80 毫秒期间平均电流可能在 80 到 120 毫安。把这些数字放到一个 5 分钟上报一次的节点上平均电流可以压到 20 到 30 微安左右这已经是电池能撑很久的水平了。4.3 错峰唤醒RTC 内存里存一个随机偏移上一节提到上报错峰对于低功耗节点还有一个专门的做法把随机偏移存在 RTC 内存里而不是每次唤醒后临时计算。为什么因为 Deep Sleep 唤醒后如果直接调用random()种子如果没有正确保存每次重启的随机序列可能相同或者差异很小反而达不到错峰的效果。把偏移在首次启动时生成并存进 RTC 内存之后每次醒来读取就绕开了随机种子的问题。RTC_DATA_ATTR uint16_t wake_offset 0; RTC_DATA_ATTR bool offset_initialized false; void setup() { if (!offset_initialized) { wake_offset random(0, 1000); offset_initialized true; } // 唤醒后先等自己的偏移时间 delay(wake_offset); // 再开始初始化 Wi-Fi 和 ESP-NOW }这个方案的巧妙之处在于节点错峰不仅发生在上报时刻还发生在唤醒时刻。所有节点即使定时器同时触发也会错开醒来的时间窗口从根源上减少无线信道的碰撞窗口。4.4 功耗账本瞬间电流比平均电流更值得担心上面算了平均电流但实际做电池供电项目时真正的敌人是瞬间浪涌电流。Wi-Fi 启停的瞬间电流尖峰可以超过 300 毫安如果电池内阻大或者供电线路细这个尖峰瞬间拉低电压可能造成设备直接复位表现为一唤醒就死循环重启。排查方法很土但有效用示波器同时抓电源轨和 GPIO 唤醒引脚看唤醒瞬间电压跌落幅度。如果一个 2000mAh 的锂电池在唤醒瞬间电压掉了 0.5V 以上就要考虑在电源输入端并一个大电容比如 470uF 到 1000uF或者改用低内阻的锂电池。电容并上之后唤醒时先由电容放电维持电压电池慢慢补充整个系统的稳定性会有质的改善。这个经验我用 ESP-NOW 项目里至少遇到 5 次设备莫名重启最后全是供电问题没有一次是协议问题。5. 排查链路把时好时坏变成可定位的技术问题5.1 初始化失败的常见原因Wi-Fi 模式不对其他都是借口每次看到有人在社区问esp_now_init返回错误十有八九是 Wi-Fi 模式没设置对。ESP-NOW 需要设备处于 STA 模式或 AP 模式下才能初始化如果 WiFi 处于关闭状态就调用esp_now_init返回值必然报错。另外注意一点在 Arduino 框架里WiFi.mode(WIFI_STA)本身会有一个短暂的过程极端情况下立刻接着调esp_now_begin可能还没就绪。我会在初始化和对端添加之间加一个小延时或者用循环等待的方式确保 Wi-Fi 状态到位。WiFi.mode(WIFI_STA); while (!WiFi.STA.started()) { delay(10); } esp_now_begin();5.2 单向通反向不通peer 表是双向的不是单向好友第二个高频问题A 能发到 BB 发回 A 就失败。原因往往特别智障但特别容易犯——A 添加了 B 作为 peer但 B 没有添加 A 作为 peer。ESP-NOW 的 peer 表是每个设备各自维护的不是一个全局的好友关系。A 有 B 的条目不代表 B 有 A 的条目。排查方向打印两个设备的 peer 表。ESP-IDF 可以用esp_now_get_peer遍历Arduino 框架也有对应的esp_now_peer_num等接口。发现谁缺了就补上esp_now_add_peer。这个问题在双向通信里是 90% 的反向不通根因。5.3 信道漂移导致的间歇性失联固定信道是最直接的解法这个问题前面提过一次但值得从排错角度再说一遍。现象表现为设备刚上电时通信正常过一段时间突然收不到数据了重启设备又好。如果你在日志里看不到任何报错大概率是信道漂了。如果节点连着路由器做 Wi-Fi 数据中转路由器切换信道后节点跟随路由器切到了新信道而另一端还停在初始的信道。排查方法很简单把两边设备的当前信道打出来esp_wifi_get_channel(primary, secondary)如果不一致那就是信道漂了。根治办法就是固定信道或者更彻底一点设备完全不连路由器只跑 ESP-NOW这样信道完全由你自己掌控。5.4 用接收信息和 RSSI 做现场诊断ESP-NOW 的接收回调有个容易被忽略的信息RSSI接收信号强度指示。在 Arduino-ESP32 的新版本里esp_now_recv_cb的第一个参数是esp_now_recv_info_t里面包含rx_ctrl可以拿到 RSSI。void espnow_recv_cb(const esp_now_recv_info_t *info, const uint8_t *data, int data_len) { Serial.print(RSSI: ); Serial.println(info-rx_ctrl-rssi); // 注意旧版本回调是 (mac_addr, data, len)拿不到 RSSI使用时注意区分 }RSSI 在排错时特别有用。比如某个设备时好时坏打出来的 RSSI 稳定在 -70dBm 以下那大概率是信号弱如果 RSSI 波动特别大一下 -40 一下 -80那多半是周围又移动物体或干扰源需要调整天线位置或换信道。我平时调试 ESP-NOW 都有一个习惯接收端日志只输出两行一是发送端 MAC 的前三个字节二是 RSSI。这两条信息足够快速判断现场大部分问题了。写到这里ESP-NOW 的 Part 2 也差不多收尾了。最后再分享一个小习惯我在把任何一套双向通信方案固化到代码库之前都会用两块板子加一个衰减器模拟弱信号环境人为制造几十个百分点的丢包率然后把重传、去重、错峰这三件事全部打开观察整个系统能不能自我恢复。花半天时间做这个压力测试到了正式部署之后能省下好几天的现场调试时间很划算。