LightMesh 灯联网

硬件角色先固定：网关、节点、门铃三条线分开

网关负责 Wi-Fi、MQTT 和 Mesh 转发；灯控节点负责执行灯效；门铃保持独立网络链路，不进入 Mesh。 这样做的好处是故障定位清晰：门铃视频卡顿不会影响 Mesh 灯控，Mesh 组网问题也不会破坏门铃配网和页面。

组网流程：Mesh 事件回调驱动状态机

固件注册 Mesh 事件回调后，根据 connected、disconnected、layer change、routing table change 等事件更新自身层级、root 状态和路由表。 root 产生后才启动 MQTT 桥接；普通节点拿到 root 地址后向上游周期性上报状态。

mesh_event_handler()
 ├─ MESH_EVENT_STARTED：读取 mesh_id / layer
 ├─ MESH_EVENT_CONNECTED：记录父节点，root 启动 MQTT
 ├─ MESH_EVENT_ROOT_ADDRESS：节点保存 root 地址
 └─ MESH_EVENT_LAYER_CHANGE：刷新灯效颜色与状态

操作系统线程：收发任务分离，避免回调里做重活

FreeRTOS 里拆出 `MPTX` 和 `MPRX` 两个任务：发送任务做状态上报和周期维护，接收任务阻塞等待 Mesh 数据。 回调函数只更新连接状态，不在事件回调里下载 OTA 或做复杂 JSON 处理，避免阻塞系统事件循环。

xTaskCreate(esp_mesh_p2p_tx_main, "MPTX", 3072, NULL, 5, NULL);
xTaskCreate(esp_mesh_p2p_rx_main, "MPRX", 3072, NULL, 5, NULL);

消息模型：P2P 上行，root 聚合后再进 MQTT

节点不上云，不直接持有 MQTT 连接。节点把状态通过 Mesh P2P 发给 root，root 维护节点表，再发布到 `farmely/light/<id>/up/status`。控制方向相反：App → MQTT → root → Mesh node。

Node status → esp_mesh_send(root, MESH_DATA_P2P)
Root table  → root_publish_node_status()
Cloud/App   → farmely/light/{id}/down/cmd

OTA 设计：网关自升级，节点由 root 转发升级命令

网关收到 `farmely/gateway/<id>/down/ota` 后直接执行 OTA；灯控节点收到的是 `farmely/light/<id>/down/ota`，root 解析目标设备后把 url、sha256、fw_version 和 msg_id 封装为 Mesh OTA 命令转发给节点。

handle_mqtt_ota_command()
 ├─ gateway OTA → mesh_ota_start()
 └─ light OTA   → mesh_forward_ota_request()