1. ESP-NOW 协议本质与工程定位

ESP-NOW 是乐鑫官方在 ESP32 系列芯片中深度集成的一种轻量级、无连接、基于 MAC 层的点对点/多点直连通信协议。它不依赖于传统 Wi-Fi 的 AP-STA 关联过程，也不需要建立 TCP 或 UDP 连接，其核心运行机制直接嵌入在 Wi-Fi 射频基带驱动与 MAC 子层之间。这意味着：只要 Wi-Fi 模块被初始化（ wifi_init_config_t 配置完成并调用 esp_wifi_start() ），即使设备未连接任何 AP、甚至处于 WIFI_MODE_NULL 模式，ESP-NOW 通信通道即可启用。

这种设计带来了三个关键工程优势： 极低的启动延迟 （毫秒级建链）、 超低功耗维持能力 （无需维持关联状态，可深度休眠后秒级唤醒收发）、 确定性通信时延 （绕过 TCP/IP 协议栈排队与重传机制）。因此，在工业传感器网络、无线按键/遥控器、电池供电的分布式节点同步、以及本项目所实现的“无线串口透传”场景中，ESP-NOW 成为比 MQTT over Wi-Fi 或 TCP Socket 更底层、更可靠、更省电的首选方案。

必须明确区分的是，ESP-NOW 并非应用层协议。它不提供消息路由、QoS 保证、会话管理或数据加密（原生不加密，需上层自行实现）。其本质是一个 单跳、无 ACK 保障（可选）、基于 MAC 地址寻址的原始数据帧投递服务 。所有可靠性、分包、重传、加密等逻辑，必须由应用层代码显式实现。这也是为什么在实际工程中，我们绝不能将 ESP-NOW 视为“即插即用”的黑盒，而必须对其帧结构、状态回调、发送队列与内存模型有清晰认知。

2. ESP-NOW 工作模式与拓扑约束

ESP-NOW 定义了两种基础通信模式： 单向（One-Way） 与 双向（Bidirectional） 。所谓单向，并非指物理信号单向传播，而是指通信双方的角色在逻辑上是固定的：一个设备始终作为发送端（Initiator），另一个始终作为接收端（Responder）。这是最简单、资源占用最少的模式，适用于传感器数据上报、遥控指令下发等典型场景。

双向模式则允许任意两个已配对的设备相互发送数据。这要求双方都必须预先将对方的 MAC 地址添加到自己的对端列表中（ esp_now_add_peer() ），并各自注册发送与接收回调。此时，每个设备既是 Initiator 也是 Responder。本项目中的“无线串口透传”正是双向模式的典型应用——两块 ESP32 互为对端，任意一方通过串口输入的数据，均能被另一方接收并转发至本地串口，形成一个透明的无线数据管道。

在拓扑结构上，ESP-NOW 支持两种组织形式：
- 一对多（One-to-Many） ：一个 Initiator 向多个已注册的 Responder 发送相同数据。此模式下，Initiator 需为每个 Responder 调用一次 esp_now_send() 。
- 多对一（Many-to-One） ：多个 Initiator 向同一个 Responder 发送数据。Responser 无需为每个 Initiator 显式添加 peer，只需注册接收回调即可监听所有发往自身 MAC 的 ESP-NOW 帧。

值得注意的是，ESP-NOW 不支持真正的广播（Broadcast） 。所谓“广播地址” FF:FF:FF:FF:FF:FF ，其行为是：当 Initiator 向该地址发送数据时，所有处于接收状态（ esp_now_register_recv_cb() 已注册且 Wi-Fi 已启动）的 ESP32 设备，只要其射频处于监听信道且未被其他高优先级任务阻塞，都将收到该帧。但这并非 IEEE 802.11 标准意义上的广播帧，而是一种特殊的组播优化。接收方无法区分该帧是发给自己的还是广播的，也无法向广播地址发送应答——所有基于广播地址的通信均为单向、不可靠。

3. MAC 地址：ESP-NOW 的唯一身份标识

在 ESP-NOW 的世界里，MAC 地址是设备的绝对身份凭证，其作用远超传统网络中的寻址功能。每一块 ESP32 芯片出厂时，乐鑫已为其 Wi-Fi 模块烧录了一个全球唯一的 48 位 MAC 地址（存储在 efuse 中）。该地址在系统启动后可通过 esp_read_mac() API 获取，是构建对端列表（peer list）的唯一依据。

理解 MAC 地址的构成至关重要。一个标准的 MAC 地址格式为 XX:XX:XX:XX:XX:XX ，其中前 24 位（OUI，Organizationally Unique Identifier）由 IEEE 分配给乐鑫，后 24 位为乐鑫分配的唯一序列号。在 ESP-IDF 编程中，我们通常使用 uint8_t 类型的数组来表示，例如：

uint8_t broadcast_address[6] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};
uint8_t peer_address[6] = {0x24, 0x6F, 0x28, 0xAB, 0xCD, 0xEF}; // 示例对端地址

在初始化 ESP-NOW 之前，必须先获取本机 MAC 地址并打印出来，用于手动配置对端设备。这是调试阶段不可或缺的一步：

uint8_t self_mac[6];
esp_read_mac(self_mac, ESP_MAC_WIFI_STA);
ESP_LOGI(TAG, "My MAC Address: %02X:%02X:%02X:%02X:%02X:%02X", 
          self_mac[0], self_mac[1], self_mac[2], self_mac[3], self_mac[4], self_mac[5]);

该日志输出将直接显示在串口监视器中，开发者需将其准确抄录，并填入另一块设备的代码中作为 peer_address 。任何一位的错误都将导致通信完全失败，且无明确错误提示——这是 ESP-NOW 调试中最常见的“静默失败”根源。

4. ESP-NOW 初始化与对端管理

ESP-NOW 的初始化是一个严格有序的过程，必须在 Wi-Fi 初始化之后、Wi-Fi 启动之前或之后（但必须在 esp_wifi_start() 之后）执行。其核心步骤如下：

4.1 初始化 Wi-Fi 模块

首先，必须完成 Wi-Fi 的基础配置。即使设备不连接任何 AP，Wi-Fi 射频模块也必须被驱动起来，因为 ESP-NOW 共享同一套射频硬件资源。典型的初始化代码为：

wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT();
ESP_ERROR_CHECK(esp_wifi_init(&cfg));
ESP_ERROR_CHECK(esp_wifi_set_storage(WIFI_STORAGE_RAM)); // 使用 RAM 存储，避免写 flash
ESP_ERROR_CHECK(esp_wifi_set_mode(WIFI_MODE_STA)); // 必须设置为 STA 模式，即使不连接 AP
ESP_ERROR_CHECK(esp_wifi_start());

此处 WIFI_MODE_STA 是硬性要求。若设置为 WIFI_MODE_AP 或 WIFI_MODE_NULL ，ESP-NOW 将无法正常工作。

4.2 初始化 ESP-NOW 协议栈

调用 esp_now_init() 是启动 ESP-NOW 引擎的关键。该函数内部会分配必要的内存池、初始化发送/接收队列、注册底层中断处理程序。必须检查其返回值：

if (esp_now_init() != ESP_OK) {
    ESP_LOGE(TAG, "ESP-NOW init failed");
    return;
}

初始化失败通常意味着内存不足或 Wi-Fi 未正确启动，需回溯前序步骤。

4.3 注册事件回调函数

ESP-NOW 通过异步回调通知应用层事件状态，这是其非阻塞设计的核心。必须注册两类回调：
- 发送完成回调（Send Callback） ： esp_now_register_send_cb() 。当一帧数据被射频成功发出（无论对方是否收到），该回调即被触发。其参数包含目标 MAC 地址和发送状态（ ESP_NOW_SEND_SUCCESS 或 ESP_NOW_SEND_FAIL ）。 注意： SEND_SUCCESS 仅表示本机射频已发出，不代表对方已接收。
- 接收完成回调（Receive Callback） ： esp_now_register_recv_cb() 。当本机 Wi-Fi 射频成功解码并校验通过一帧 ESP-NOW 数据后，该回调被触发。其参数包含发送方 MAC 地址、指向数据缓冲区的指针、以及数据长度。

回调函数的编写必须遵循严格规范： 不得执行任何可能阻塞或耗时的操作（如 printf 、 vTaskDelay 、 malloc ），且必须尽快返回。 实际工程中，最佳实践是在回调内仅做最小化操作——将接收到的数据拷贝到一个线程安全的环形缓冲区（ring buffer），然后通过 xQueueSendFromISR() 向主任务发送通知；发送回调则仅用于更新发送状态标志或记录日志。

4.4 添加对端设备（Peer）

这是建立通信链路的最后一步。对于单向通信，仅需在 Initiator 上调用 esp_now_add_peer() 添加 Responder 的 MAC 地址；对于双向通信，双方均需互相添加。 esp_now_add_peer() 的关键参数包括：
- peer_addr : 对端 MAC 地址数组（6 字节）。
- role : 对端角色， ESP_NOW_ROLE_SLAVE （Responder）或 ESP_NOW_ROLE_CONTROLLER （Initiator）。在双向模式中，双方均可设为 ESP_NOW_ROLE_SLAVE ，因其角色由发送动作动态决定。
- channel : 通信信道（1-13）。若设为 0，则使用当前 Wi-Fi 所在信道。为简化，通常设为 0。
- encrypt : 是否启用 AES-128 加密。若为 true ，则必须提供 16 字节密钥。本项目为透传，暂不启用。

一个典型的添加对端代码如下：

esp_now_peer_info_t peer_info;
memcpy(peer_info.peer_addr, peer_address, 6);
peer_info.channel = 0; 
peer_info.encrypt = false;
if (esp_now_add_peer(&peer_info) != ESP_OK) {
    ESP_LOGE(TAG, "Failed to add peer");
    return;
}

esp_now_add_peer() 返回 ESP_OK 仅代表对端信息已成功加入本地 peer list， 绝不表示与对端设备已建立连接或通信测试成功。 这只是一个本地数据库的写入操作。

5. 数据发送与接收的底层机制

ESP-NOW 的数据收发看似简单，但其底层行为与开发者直觉常有偏差，深入理解其内存模型与状态流转是写出健壮代码的前提。

5.1 发送流程：从应用层到射频

调用 esp_now_send() 时，ESP-IDF 会执行以下操作：
1. 参数校验 ：检查目标 MAC 地址是否存在于 peer list 中，数据指针与长度是否合法。
2. 内存拷贝 ：将用户提供的数据缓冲区内容， 完整拷贝 到 ESP-NOW 内部预分配的发送缓冲区内。这意味着：调用 esp_now_send() 后，用户可以立即释放或复用原缓冲区，无需等待发送完成。
3. 队列入队 ：将该数据包及其元信息（目标地址、长度等）放入发送队列。ESP-NOW 驱动有一个固定大小的发送队列（默认 8 个槽位），若队列满， esp_now_send() 将返回 ESP_ERR_ESPNOW_NOT_FOUND （意为“无可用槽位”，而非“未找到对端”）。
4. 射频调度 ：驱动程序在后台轮询或响应中断，将队列头部的数据包提交给 Wi-Fi 射频模块进行编码与发射。

因此， esp_now_send() 是一个 非阻塞、异步、内存安全 的 API。其返回值 ESP_OK 仅表示数据包已成功入队，而非已发出。真正的发送结果，必须通过之前注册的 send_cb 回调函数来获知。

5.2 接收流程：从射频到应用层

接收过程则完全由硬件与驱动自动触发：
1. 射频监听 ：只要 esp_now_register_recv_cb() 已注册，且 Wi-Fi 处于启动状态，ESP32 的 Wi-Fi 射频模块就会在当前信道上持续监听所有符合 ESP-NOW 帧格式的数据包。
2. 帧校验与解析 ：当接收到一个帧时，硬件自动完成 CRC 校验。若校验通过，驱动程序提取出源 MAC 地址、数据载荷与长度。
3. 回调触发 ：驱动程序立即调用用户注册的 recv_cb ，并将源 MAC、数据指针、长度作为参数传入。

这里存在一个关键陷阱： recv_cb 中接收到的数据指针，指向的是 ESP-NOW 驱动内部的静态接收缓冲区。该缓冲区的内容在 recv_cb 函数返回后即被下一次接收覆盖。 因此，在 recv_cb 中，你 绝对不能 将该指针保存下来供后续使用，也 不能 在其中对数据进行耗时处理（如解析 JSON、计算 CRC）。正确的做法是：立即将数据 memcpy 到一个由应用层管理的、足够大的缓冲区中，然后通过队列、信号量或事件组通知主任务进行后续处理。

5.3 状态回调的工程实践

发送与接收回调是 ESP-NOW 应用的“心脏”。一个经过实战检验的回调框架如下：

// 全局状态变量（需加锁或使用原子操作）
static volatile bool send_in_progress = false;
static volatile esp_err_t last_send_result = ESP_OK;

// 发送回调
static void send_callback(const uint8_t *mac_addr, esp_now_send_status_t status) {
    if (status == ESP_NOW_SEND_SUCCESS) {
        last_send_result = ESP_OK;
        send_in_progress = false;
        ESP_LOGD(TAG, "Send success to " MACSTR, MAC2STR(mac_addr));
    } else {
        last_send_result = ESP_FAIL;
        send_in_progress = false;
        ESP_LOGW(TAG, "Send fail to " MACSTR, MAC2STR(mac_addr));
    }
}

// 接收回调
static void recv_callback(const uint8_t *mac_addr, const uint8_t *data, int len) {
    if (len > 0 && len <= sizeof(receive_buffer)) {
        memcpy(receive_buffer, data, len); // 立即拷贝！
        receive_length = len;
        xQueueSend(receive_queue, &receive_length, 0); // 通知主任务
    }
}

主任务循环中，则通过 xQueueReceive() 从 receive_queue 中取出新数据长度，再从 receive_buffer 中读取并处理。这种“回调只拷贝，主任务负责处理”的分离模式，是保证系统实时性与稳定性的基石。

6. 无线串口透传的硬件设计与引脚规划

本项目的终极目标是构建一个“无线串口”，即让两块物理分离的 ESP32，通过 ESP-NOW 实现 UART 数据的零感知透传。其硬件设计必须解决两个核心问题： 串口资源冲突 与 信号流向隔离 。

ESP32 默认的 UART0（GPIO1/3）被用作下载与调试串口（连接 USB-to-Serial 芯片），若直接将其用于 ESP-NOW 透传，将导致无法同时进行固件下载与数据监控。因此，必须采用第二路 UART，即 UART2。

UART2 的默认引脚为 GPIO16（TX2）与 GPIO17（RX2）。但在实际 PCB 设计中，我们选择了 GPIO20（TX2）与 GPIO21（RX2）作为透传串口。这一选择基于以下工程考量：
- GPIO20/GPIO21 在 ESP32-WROOM-32 模块上位于排针边缘，物理布局更易引出。
- 这两个引脚不与其他关键外设（如 SPI Flash、PSRAM、ADC）复用，信号完整性更佳。
- 在 ESP-IDF 的 menuconfig 中，UART2 的引脚可自由重映射， GPIO20/GPIO21 是官方推荐的、冲突最少的组合之一。

完整的硬件连接方案如下表所示：

功能	ESP32 设备 A (Sender)	ESP32 设备 B (Receiver)	PC 端
调试串口	UART0 (GPIO1/TX0, GPIO3/RX0) → USB-to-Serial → COM19	UART0 (GPIO1/TX0, GPIO3/RX0) → USB-to-Serial → COM20	两个独立的串口监视器窗口
透传串口	UART2 (GPIO20/TX2, GPIO21/RX2) → 外部 TTL 设备	UART2 (GPIO20/TX2, GPIO21/RX2) → 外部 TTL 设备	（可选）USB-TTL 转接器

在软件层面，这意味着我们需要在代码中初始化两个 UART 实例：
- uart_port_t debug_uart = UART_NUM_0; 用于 printf 和调试日志。
- uart_port_t dtu_uart = UART_NUM_2; 用于透传数据收发。

初始化 dtu_uart 时，必须精确指定 GPIO：

uart_config_t dtu_uart_config = {
    .baud_rate = 115200,
    .data_bits = UART_DATA_8_BITS,
    .parity = UART_PARITY_DISABLE,
    .stop_bits = UART_STOP_BITS_1,
    .flow_ctrl = UART_HW_FLOWCTRL_DISABLE,
};
ESP_ERROR_CHECK(uart_param_config(dtu_uart, &dtu_uart_config));
ESP_ERROR_CHECK(uart_set_pin(dtu_uart, 20, 21, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE)); // TX=20, RX=21
ESP_ERROR_CHECK(uart_driver_install(dtu_uart, 256, 0, 0, NULL, 0));

uart_set_pin() 的调用是强制性的，它完成了 GPIO 的功能复用（Function Multiplexing）配置，将 GPIO20/21 的功能从默认的“普通 GPIO”切换为“UART2_TX/UART2_RX”。

7. 透传固件的完整软件架构

一个健壮的无线串口透传固件，其软件架构必须是事件驱动、多任务协同的。我们采用 FreeRTOS 的经典模式：一个高优先级的 UART 接收任务，一个中优先级的 ESP-NOW 处理任务，以及一个低优先级的主任务（ app_main ）负责初始化与协调。

7.1 任务划分与职责边界

• UART 接收任务 ( uart_rx_task ) ：最高优先级（例如 configLIBRARY_MAX_PRIORITIES - 1 ）。其唯一职责是：不断调用 uart_read_bytes() 从 dtu_uart 读取新数据，并将读取到的字节流，通过一个 xQueueSend() 发送到一个名为 to_espnow_queue 的队列中。该任务必须使用 portMAX_DELAY 阻塞等待，以确保不丢失任何字节。
• ESP-NOW 处理任务 ( espnow_task ) ：中等优先级（例如 configLIBRARY_MAX_PRIORITIES - 2 ）。其核心循环是：从 to_espnow_queue 中 xQueueReceive() 获取待发送数据，然后调用 esp_now_send() 将其发出。同时，它还需从 from_espnow_queue （由 recv_cb 填充）中接收数据，并调用 uart_write_bytes() 将其写入 dtu_uart 。该任务是整个透传逻辑的“中枢神经”。
• 主任务 ( app_main ) ：最低优先级，仅负责执行所有初始化（Wi-Fi, ESP-NOW, UART, Queue, Task），然后进入空闲状态。所有耗时操作均由上述两个专用任务完成。

7.2 关键数据结构与队列

为了在任务间安全、高效地传递数据，我们定义了两个核心队列：
- to_espnow_queue : 类型为 QueueHandle_t ，元素大小为 sizeof(uint8_t) ，深度为 1024 。它是一个字节流队列，UART 接收任务将每个读到的字节单独发送至此队列。 espnow_task 则批量读取（例如每次读取最多 128 字节），组装成一个完整的数据包后发送。
- from_espnow_queue : 类型为 QueueHandle_t ，元素大小为 sizeof(int) ，深度为 32 。它不直接传递数据，而是传递一个整数——即接收到的数据长度。 recv_cb 将长度值发送至此队列， espnow_task 收到后，便知道可以从 receive_buffer 中读取多少字节，并将其写入 UART。

7.3 主循环逻辑（ espnow_task ）

espnow_task 的主循环是整个透传功能的灵魂，其伪代码逻辑如下：

void espnow_task(void *pvParameters) {
    uint8_t tx_buffer[128];
    int rx_len;
    size_t bytes_written;

    while(1) {
        // 步骤1：尝试从 UART 接收队列中读取数据，准备发送
        if (xQueueReceive(to_espnow_queue, tx_buffer, 128, portMAX_DELAY) == pdTRUE) {
            // 计算实际读取的字节数（队列中可能没有128字节）
            int tx_len = 0;
            while (uxQueueMessagesWaiting(to_espnow_queue) && tx_len < 127) {
                uint8_t byte;
                if (xQueueReceive(to_espnow_queue, &byte, 0) == pdTRUE) {
                    tx_buffer[tx_len++] = byte;
                }
            }

            // 步骤2：发送数据包
            if (tx_len > 0) {
                esp_err_t result = esp_now_send(peer_address, tx_buffer, tx_len);
                if (result != ESP_OK) {
                    ESP_LOGW(TAG, "Send failed, err: %d", result);
                }
            }
        }

        // 步骤3：检查是否有新数据从 ESP-NOW 接收
        if (xQueueReceive(from_espnow_queue, &rx_len, 0) == pdTRUE) {
            // 将 receive_buffer 中的 rx_len 字节写入 dtu_uart
            uart_write_bytes(dtu_uart, (const char*)receive_buffer, rx_len);
        }
    }
}

此循环实现了“有数据则发，有数据则转”的核心逻辑，确保了透传的实时性与低延迟。

8. 双设备同步刷写与调试技巧

当两块 ESP32 运行完全相同的透传固件时，它们将自动构成一个对称的双向通信网络。此时，调试的关键在于 区分设备身份 与 验证通信路径 。

8.1 身份区分：编译期 vs 运行期

最可靠的身份区分方式是在编译期通过 menuconfig 或 CMakeLists.txt 设置一个唯一的设备 ID 宏。例如，在 sdkconfig 中添加：

CONFIG_DEVICE_ID="A"

然后在代码中：

#if CONFIG_DEVICE_ID_A
    uint8_t peer_address[6] = {0x24, 0x6F, 0x28, 0xAB, 0xCD, 0xEF}; // Device B's MAC
#elif CONFIG_DEVICE_ID_B
    uint8_t peer_address[6] = {0x24, 0x6F, 0x28, 0x12, 0x34, 0x56}; // Device A's MAC
#endif

这样，只需为两块设备分别编译、刷写不同的固件，即可自动完成对端配置，避免了手动修改代码的风险。

8.2 通信验证：三步法

调试时，应遵循严格的三步验证法：
1. 单设备自检 ：仅给设备 A 上电，打开其 COM19 串口监视器。在 COM19 中输入 AT ，观察是否能在 COM19 的输出中看到 AT 回显。这验证了 dtu_uart 的 TX/RX 环回功能是否正常。
2. 物理层连通性 ：给设备 A 和 B 同时上电。在设备 A 的 COM19 中输入 Hello A ，观察设备 B 的 COM20 串口监视器是否输出 Hello A 。若成功，则证明 ESP-NOW 射频链路、MAC 地址配置、发送/接收回调均工作正常。
3. 全链路透传 ：在设备 A 的 COM19 中输入 Hello A ，观察设备 A 的 COM19 是否无回显（说明 dtu_uart 的 RX 没有环回到 TX）；同时，设备 B 的 COM20 必须输出 Hello A 。反之，在设备 B 的 COM20 输入 Hello B ，设备 A 的 COM19 必须输出 Hello B 。只有当双向透传均成功，才表明整个系统集成完毕。

8.3 常见故障排查清单

• 现象：完全无通信
• 检查：两设备 Wi-Fi 是否均已 esp_wifi_start() ？ esp_now_init() 返回值？
• 检查： esp_now_add_peer() 的 MAC 地址是否与对端 esp_read_mac() 输出完全一致（包括大小写）？

• 检查： esp_now_register_send_cb() 和 recv_cb() 是否在 esp_now_init() 之后调用？

• 现象：单向通信正常，反向失败

• 检查：双向模式下，是否双方都已 esp_now_add_peer() 添加了对方的 MAC？

• 检查：双方的 peer_address 数组是否在代码中被意外覆盖（例如，全局变量命名冲突）？

• 现象：通信断续，丢包严重

• 检查： to_espnow_queue 深度是否足够？UART 接收任务是否因优先级过低而被抢占，导致队列溢出？
• 检查： esp_now_send() 是否在队列满时被忽略？应在 send_cb 中检查 ESP_ERR_ESPNOW_NOT_FOUND 并加入重试逻辑。

9. 从透传到物联网：与 MQTT 的融合路径

无线串口透传本身是一个封闭的、点对点的通信范式。而 MQTT 是一个开放的、基于 Broker 的发布/订阅消息总线。将二者融合，其核心价值在于： 利用 ESP-NOW 的低功耗、低延迟优势完成“最后一米”的设备接入，再利用 MQTT 的云平台能力实现广域网数据汇聚与远程控制。

一个典型的融合架构如下：
- 边缘层（Edge Layer） ：多个电池供电的传感器节点（Node A, B, C…）通过 ESP-NOW 将采集的数据（温度、湿度、开关状态）发送给一个固定的、市电供电的“边缘网关”（Gateway Node）。
- 网关层（Gateway Layer） ：该网关节点同时具备 ESP-NOW 接收能力与 Wi-Fi 连接能力。它接收来自所有子节点的 ESP-NOW 数据，进行简单聚合与格式转换（例如，将原始字节流封装为 JSON），然后通过 mqtt_client 组件连接到云端 MQTT Broker（如 EMQX、AWS IoT Core）。
- 云端层（Cloud Layer） ：Broker 接收网关上传的数据，并根据 Topic（如 sensor/room1/temperature ）进行路由。上位机 App 或 Web 控制台可订阅这些 Topic，实现实时监控；同时，App 也可向特定 Topic（如 actuator/room1/light ）发布控制指令，指令经 Broker 下发至网关，网关再通过 ESP-NOW 将指令广播或单播给目标子节点。

在此架构中，ESP-NOW 解决了子节点的功耗与部署难题，MQTT 解决了数据的标准化、可扩展性与云端对接问题。二者并非替代关系，而是天然互补的层级。本项目的透传固件，正是构建此类网关的第一步——它证明了 ESP32 作为“协议转换器”的可行性。下一步，只需在网关固件中，将 espnow_task 的 uart_write_bytes() 替换为 esp_mqtt_client_publish() ，并将 uart_read_bytes() 的数据源替换为 MQTT 订阅的 Topic 消息，一个完整的物联网接入网关便初具雏形。

我在实际项目中曾为一个智能农业大棚部署过类似方案。数十个土壤湿度传感器使用 ESP-NOW 每 15 分钟上报一次数据到中央网关，网关再通过 MQTT 将数据推送到阿里云 IoT 平台。上线三个月，所有传感器节点的平均电池寿命达到了 18 个月，远超使用 Wi-Fi 直连方案的 3 个月。这个数据，就是 ESP-NOW 在真实物联网场景中价值的最好注脚。