目录
一、总体方案概述
二、架构组成
2.1 系统拓扑
2.2 硬件端（MCU + WiFi 模组）
2.3 WiFi 网关
2.4 云端服务器
三、低功耗保活技术设计模式
3.1 模式一：定时唤醒 + MQTT 保活
3.1.1 设备端
3.1.2 优势
3.2 模式二：网关保活代理 + 本地网络唤醒
3.2.1 网关功能
3.2.2 设备端
3.2.3 优势
3.3 模式三：长连接+轻睡眠 + TCP KeepAlive
适用于：市电供电设备（如网关、摄像头）；
四、具体技术实现点
4.1 设备端（ESP32）低功耗方案（低功耗 + MQTT 保活）
4.1.1 核心原则：
4.1.2 保活策略
4.1.3 睡眠策略
4.1.4 唤醒策略
4.1.5 WiFi 连接优化
4.1.6 MQTT 优化策略
4.1.7 OTA 与低功耗共存
4.2 通信层
通信模式
4.3 云端服务端设计（MQTT + WebSocket）
4.3.1 MQTT 层（设备通信）
1.Broker选择建议
2.性能优化点
3.MQTT Broker 端（如 EMQX/Mosquitto）
4.3.2 WebSocket 层（云 → APP）
1.架构建议
2.性能优化点
3.云端到 APP（WebSocket）
4.3.3 数据库与消息缓存
总结：
五、优化建议
六、场景举例
在 IoT 场景中，为了确保设备能在低功耗状态下长时间运行，同时与服务器保持基本的连接活性，通常需要软硬件协同设计低功耗保活机制。下面是服务器、硬件与 WiFi 网关协同下的低功耗保活技术方案：
一、总体方案概述
低功耗保活的目标是在减少设备功耗的前提下，维持设备与服务器之间的最小必要通信，以保证
-
远程可控性；
-
在线状态识别；
-
消息下发可靠性。
适用场景： 智能门锁、传感器、摄像头、温湿度设备、开关等。
二、架构组成
终端设备：ESP32/ESP8266（WiFi/BLE）、LoRaWAN设备、低功耗传感器等。
WiFi网关：ESP32（集成WiFi/BLE）、Raspberry Pi Zero（低功耗网关）。
云端：AWS IoT Core（MQTT Broker）、Lambda（无服务器计算）、DynamoDB（数据存储）。
APP：通过WebSocket接收实时数据推送。
2.1 系统拓扑
[终端设备]←(BLE/WiFi)→[WiFi网关] ←MQTT→ [MQTT Broker / 云平台] ←WebSocket→ [APP客户端]
↑ ↑
定时/中断唤醒 实时消息推送/控制指令2.2 硬件端（MCU + WiFi 模组）
-
MCU：如 STM32、ESP32 等；
-
低功耗模组：支持深睡眠/轻睡眠（ESP32 的
ESP_SLEEP模式）； -
电池供电；
-
支持定时唤醒、中断唤醒（按键、定时器、外部触发等）；
2.3 WiFi 网关
-
功能：为设备提供局域网连接，进行保活检测、数据转发；
-
特性：支持 NAT KeepAlive、UDP打洞、MQTT中转等功能；
-
保活代理：网关代为心跳/设备状态上报，减少设备上线频率。
2.4 云端服务器
-
接入层：WebSocket/MQTT Broker；
-
状态管理：心跳检测、离线判定、消息队列；
-
下发策略：支持唤醒或缓存待下发指令；
-
与网关协同：通过网关唤醒设备或完成间接通信。
三、低功耗保活技术设计模式
3.1 模式一：定时唤醒 + MQTT 保活
3.1.1 设备端
-
默认处于深睡眠状态；
-
每隔
N 分钟唤醒一次：-
建立 MQTT 连接；
-
上报心跳、状态；
-
接收服务器下发指令（超时未收到即重新睡眠）；
-
保持在线时间 < 5s。
-
3.1.2 优势
-
简单、无须额外网关；
-
适合无实时性要求的场景（如环境监测）。
3.2 模式二：网关保活代理 + 本地网络唤醒
3.2.1 网关功能
-
长时间与云端保持连接；
-
本地轮询检测设备是否仍在线；
-
有需要时通过本地网络（如 UDP 广播/WiFi 唤醒）唤醒设备。
3.2.2 设备端
-
默认深睡眠；
-
支持局域网唤醒（WoW/WiFi 模块定期监听广播）；
-
唤醒后完成任务，再次休眠。
3.2.3 优势
-
延长电池寿命；
-
实现准实时通信；
-
云端通过网关间接与设备通信，设备上线频率极低。
