目錄
一、總體方案概述
二、架構組成
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 優勢
-
延長電池壽命;
-
實現準實時通信;
-
云端通過網關間接與設備通信,設備上線頻率極低。