關(guān)實(shí)戰(zhàn)：從硬件選型到App控制完整鏈路)
看到不少人在智能家居上折騰最頭疼的就是“協(xié)議不統(tǒng)一”和“平臺(tái)鎖定”這兩個(gè)問題。用樹莓派當(dāng)網(wǎng)關(guān)性能和價(jià)格都過了頭還費(fèi)電用STM32自己做WiFi模塊和藍(lán)牙模塊電路復(fù)雜化調(diào)起來特別折磨人。ESP32幾乎是這個(gè)場(chǎng)景下的最優(yōu)解一顆芯片同時(shí)集成了WiFi和BLE雙核240MHz的處理能力拿來做協(xié)議匯聚綽綽有余價(jià)格卻只要十幾塊錢。這篇文章我用實(shí)際做過的整套方案把從硬件選型、開發(fā)環(huán)境、雙模通信、傳感器接入到App控制端的完整鏈路都拆開給你看應(yīng)該能幫你少走不少彎路。1. 方案定位與整體思路拆解1.1 為什么是ESP32而不是樹莓派或STM32很多人第一次做智能家居網(wǎng)關(guān)都會(huì)在樹莓派、STM32和ESP32之間猶豫。我的判斷標(biāo)準(zhǔn)很簡單看你需要什么級(jí)別的“智力”放在設(shè)備端。樹莓派本質(zhì)是一臺(tái)跑Linux的小電腦它當(dāng)然能裝Home Assistant、Node-RED這些全家桶也能同時(shí)接USB攝像頭和一堆傳感器。但代價(jià)是功耗基本在3W以上開機(jī)要以分鐘計(jì)系統(tǒng)卡了還得去排查SD卡分區(qū)問題。如果你只是想控制幾個(gè)燈、讀取幾個(gè)傳感器、做點(diǎn)自動(dòng)化聯(lián)動(dòng)樹莓派是典型的重型武器殺雞用牛刀還費(fèi)電。STM32是另一種極端。它的實(shí)時(shí)性和生態(tài)在工業(yè)控制領(lǐng)域沒得說但問題是無線通信能力要靠外掛模塊實(shí)現(xiàn)。一片ESP8266搞定WiFi一片nRF52832搞定藍(lán)牙兩套固件、兩套電源、兩套天線布局中途還要處理模塊間的UART通信協(xié)議。電路復(fù)雜度和調(diào)試成本直接翻倍特別是天線阻抗匹配和射頻走線對(duì)新手門檻極高。ESP32卡在兩者之間剛好合適。它集成了2.4GHz WiFi和藍(lán)牙雙模雙核Xtensa處理器跑到240MHz520KB SRAM加4MB Flash跑輕量級(jí)的FreeRTOS任務(wù)調(diào)度毫無壓力。更重要的是它支持SmartConfig一鍵配網(wǎng)、BLE GATT服務(wù)、OTA升級(jí)以及各類外設(shè)接口。這意味著你完全可以把它既當(dāng)傳感器節(jié)點(diǎn)又當(dāng)智能家居網(wǎng)關(guān)——所有設(shè)備統(tǒng)一接入它再由它上行到局域網(wǎng)或云端。這套邏輯用一句話總結(jié)一顆ESP32吃掉“接入層”和“匯聚層”兩件事。1.2 一站式方案的分層架構(gòu)整個(gè)方案我按三層來拆解每層職責(zé)清晰后續(xù)擴(kuò)展新設(shè)備時(shí)不需要推倒重來。第一層是設(shè)備接入層主要使用BLE低功耗傳感器節(jié)點(diǎn)。比如溫濕度計(jì)、門窗磁、人體存在傳感器它們干完活就睡功耗降到微安級(jí)一顆紐扣電池?fù)伟肽晟踔粮谩５诙邮蔷W(wǎng)關(guān)控制層由ESP32承擔(dān)。它同時(shí)開啟WiFi站模式和藍(lán)牙掃描/連接功能一方面通過BLE GATT收集傳感器數(shù)據(jù)另一方面通過WiFi與路由器、MQTT Broker或手機(jī)App通信。第三層是應(yīng)用交互層包括手機(jī)端App、Web儀表盤或Home Assistant這類開源平臺(tái)。這套架構(gòu)避免了“每個(gè)設(shè)備都要連路由器”的困境。很多廉價(jià)BLE傳感器不支持WiFi或者連接WiFi協(xié)議棧開銷太大它們只要找到ESP32即可。反過來ESP32把多路BLE數(shù)據(jù)匯聚成統(tǒng)一的JSON格式后通過WiFi統(tǒng)一上云或推送到手機(jī)。從實(shí)踐來看分層的核心好處是傳感器端改動(dòng)極小網(wǎng)關(guān)端的代碼穩(wěn)定性高上層應(yīng)用只對(duì)接網(wǎng)關(guān)API接口就夠了。2. 硬件選型與開發(fā)環(huán)境搭建2.1 主控選型ESP32、ESP32-S3、ESP32-C3怎么挑很多人拿到ESP32這個(gè)總稱就以為只有一個(gè)型號(hào)實(shí)際上樂鑫的芯片線已經(jīng)分岔得很細(xì)了。我在這套方案里分別用過的3個(gè)系列各自的適用場(chǎng)景差異明顯選錯(cuò)的話后期會(huì)很痛苦。芯片型號(hào)核心架構(gòu)主頻/內(nèi)存無線特性典型開發(fā)板適用場(chǎng)景ESP32經(jīng)典款雙核Xtensa LX6240MHz / 520KB SRAMWiFi 802.11 b/g/n BLE 4.2ESP32 DevKitC、NodeMCU-32S網(wǎng)關(guān)主力外設(shè)豐富資料最多ESP32-S3雙核Xtensa LX7240MHz / 512KB SRAMWiFi BLE 5.0支持向量指令加速ESP32-S3-DevKitC-1AI語音、LCD人機(jī)交互界面、更高算力需求ESP32-C3單核RISC-V160MHz / 400KB SRAMWiFi BLE 5.0ESP32-C3-DevKitM-1、Seeed XIAO ESP32C3低成本傳感器節(jié)點(diǎn)GPIO少但夠用我實(shí)際做網(wǎng)關(guān)用的是經(jīng)典款ESP32因?yàn)樗腉PIO最全、社區(qū)資料最多踩到坑隨時(shí)能搜到答案。做子設(shè)備節(jié)點(diǎn)時(shí)用ESP32-C3更劃算C3雖然只有一個(gè)核心、主頻低但應(yīng)對(duì)BLE傳感器數(shù)據(jù)采集完全夠用PCB尺寸和功耗都更友好。S3那款我在升級(jí)版里用過主要是需要驅(qū)動(dòng)彩色觸摸屏做家庭控制面板時(shí)發(fā)揮算力優(yōu)勢(shì)日常做網(wǎng)關(guān)其實(shí)有點(diǎn)浪費(fèi)。選型還有一個(gè)容易忽略的點(diǎn)外接Flash容量。ESP32經(jīng)典款板載4MB Flash如果你要上Web配網(wǎng)界面、TFT_eSPI字體庫、MQTT證書、OTA雙分區(qū)4MB會(huì)比較吃緊。建議優(yōu)先選8MB或16MB Flash的版本或者干脆用支持PSRAM的WROVER系列模組給動(dòng)態(tài)內(nèi)存留出余量。2.2 開發(fā)環(huán)境與國內(nèi)源配置開發(fā)環(huán)境我推薦直接用Arduino IDE加esp32核心理由很實(shí)在上手門檻低、庫生態(tài)全、排錯(cuò)資源多。另一種常用路線是PlatformIO Visual Studio Code工程管理和依賴庫版本控制更規(guī)范適合寫大項(xiàng)目或多人協(xié)作。我個(gè)人的習(xí)慣是快速原型驗(yàn)證用Arduino正式項(xiàng)目用PlatformIO。安裝ESP32核心時(shí)最大的痛點(diǎn)在國內(nèi)網(wǎng)絡(luò)環(huán)境里尤其明顯默認(rèn)從GitHub下載的JSON索引文件和工具鏈經(jīng)常失敗或龜速。解決方案是換用國內(nèi)鏡像源。在Arduino IDE的“文件—首選項(xiàng)—附加開發(fā)板管理器網(wǎng)址”里填入樂鑫官方在國內(nèi)托管的包索引地址或者直接使用阿里云的鏡像地址。添加后打開開發(fā)板管理器搜索esp32安裝即可。PlatformIO用戶也一樣可以在“PlatformIO Registry”中配置國內(nèi)鏡像加速或者使用社區(qū)打包的離線包。我提到離線包是因?yàn)橛信笥延龅焦驹趦?nèi)網(wǎng)開發(fā)、完全連不上外網(wǎng)的情況這時(shí)候離線包幾乎是唯一解。安裝后記得把“PlatformIO Core”的包管理源指向內(nèi)網(wǎng)鏡像否則依賴庫拉取一樣會(huì)卡死。注意無論用哪種方式安裝完成后先編譯一個(gè)Blink例程驗(yàn)證工具鏈沒問題再開始正式代碼。很多編譯報(bào)錯(cuò)其實(shí)都源于環(huán)境沒裝干凈。2.3 燒錄方式的取舍ESP32的燒錄方式有3種按使用頻率排序是USB串口、JTAG和OTA。USB串口是日常開發(fā)的主力通過板載CP2102或CH340芯片把USB信號(hào)轉(zhuǎn)成UART。接線很簡單只需TXD、RXD、GND三根線部分板子還要短接EN和GND進(jìn)入下載模式。需要留意的是不同板子的串口芯片驅(qū)動(dòng)差異很大老版本CH340在macOS上經(jīng)常要手動(dòng)裝驅(qū)動(dòng)而且安裝后還要在“系統(tǒng)設(shè)置—隱私與安全性”里放行內(nèi)核擴(kuò)展否則上傳時(shí)必卡在“Connecting...”。JTAG調(diào)試功能在ESP32-S3和C3上更完善官方推薦的USB JTAG接口可以做到單線調(diào)試、斷點(diǎn)設(shè)置和實(shí)時(shí)變量查看。這塊調(diào)試能力對(duì)排查HardFault或者棧溢出極有幫助但配置稍微復(fù)雜一些新手不建議作為首選。OTA升級(jí)是產(chǎn)品化之后必需的燒錄方式。ESP32原生支持通過WiFi把固件升級(jí)到當(dāng)前運(yùn)行或者備用分區(qū)配合Arduino的“OTA Update”庫手機(jī)App或Web界面就能推送新固件不用拆機(jī)接串口。我的方案里固件分區(qū)表是必須訂制的默認(rèn)的1MB App分區(qū)不夠放Web資源和OTA的兩個(gè)固件要改成8MB或者更大的布局。3. WiFi與BLE雙模通信核心實(shí)現(xiàn)3.1 SmartConfig配網(wǎng)與Web配網(wǎng)實(shí)戰(zhàn)智能家居設(shè)備最讓人惱火的一環(huán)就是配網(wǎng)。傳統(tǒng)的做法是用串口助手發(fā)送WiFi名稱和密碼或者燒錄時(shí)寫死在代碼里。前者對(duì)用戶不友好后者換一個(gè)WiFi環(huán)境就要重新燒錄維護(hù)成本極高。我總共實(shí)現(xiàn)了兩種配網(wǎng)方式互為備份。SmartConfig是目前用戶體驗(yàn)最順的一種。手機(jī)App先連上家里的2.4GHz WiFi然后把WiFi的SSID和密碼通過UDP協(xié)議廣播出去。ESP32的ESP-Touch庫在混雜模式下抓取空中數(shù)據(jù)包從UDP包長度和順序里解出憑據(jù)然后自動(dòng)連接路由器。這套協(xié)議的巧妙之處在于不需要手機(jī)與ESP32先建立任何連接路由器也不需要有特殊設(shè)置只要手機(jī)和ESP32在同一頻段內(nèi)即可。代碼上大致是調(diào)用WiFi.beginSmartConfig()然后在循環(huán)里檢查WiFi.smartConfigDone()的狀態(tài)等待配網(wǎng)完成。關(guān)鍵參數(shù)里有幾個(gè)坑要提一下ESP32只支持2.4GHz頻段手機(jī)如果連著5GHz WiFi來廣播ESP32根本收不到必須先切到2.4GHz另外ESP-Touch對(duì)路由器組播報(bào)文的一些策略比較敏感某些開啟了AP隔離的路由器兼容性會(huì)變差。Web配網(wǎng)適用于首次部署且手機(jī)不太好裝App的場(chǎng)景。實(shí)現(xiàn)思路是ESP32進(jìn)入SoftAP模式熱點(diǎn)名稱類似“ESP32_Setup”手機(jī)連接該熱點(diǎn)瀏覽器訪問192.168.4.1打開嵌入式Web頁面選擇WiFi并輸入密碼。頁面通過HTTP POST把密碼提交給ESP32ESP32保存參數(shù)后切換為STA模式連接路由器。這套方案核心在于ESP32內(nèi)嵌Web服務(wù)器并生成配置頁面我通常把頁面HTML壓縮成字節(jié)數(shù)組燒錄到Flash里避免占用太多內(nèi)存。兩個(gè)方案我都做過實(shí)測(cè)SmartConfig配網(wǎng)成功率在無干擾環(huán)境下能到90%以上Web配網(wǎng)則因?yàn)榻换ゲ襟E更可控成功率接近99%所以最終產(chǎn)品里我把Web配網(wǎng)作為兜底入口保留。3.2 BLE GATT服務(wù)設(shè)計(jì)與數(shù)據(jù)交互BLE通信的骨架是GATT整個(gè)結(jié)構(gòu)從上到下是Profile、Service服務(wù)、Characteristic特征值。設(shè)計(jì)一個(gè)可擴(kuò)展的數(shù)據(jù)服務(wù)協(xié)議核心是合理規(guī)劃UUID和特征值的讀寫權(quán)限。我對(duì)接傳感器數(shù)據(jù)時(shí)在ESP32上建立了一個(gè)名為Device Data Service的自定義服務(wù)UUID用128位的自定義值避免和標(biāo)準(zhǔn)服務(wù)沖突。服務(wù)下面掛了3個(gè)特征值一個(gè)Notify類型用于ESP32主動(dòng)推送傳感器數(shù)據(jù)給手機(jī)或子設(shè)備一個(gè)Write類型用于接收手機(jī)下發(fā)的控制指令比如開關(guān)燈、調(diào)節(jié)亮度還有一個(gè)Read類型用于手機(jī)主動(dòng)查詢?cè)O(shè)備當(dāng)前狀態(tài)。所有數(shù)據(jù)交互都統(tǒng)一走JSON字符串。比如傳感器上送的數(shù)據(jù)為{type:temp,value:25.6,unit:C}控制指令下行為{cmd:set_light,state:1}。選用JSON的代價(jià)是每幀數(shù)據(jù)長度增加不少但換來的是極強(qiáng)的可維護(hù)性后期增刪字段不需要改動(dòng)GATT結(jié)構(gòu)。需要注意的是BLE的MTU默認(rèn)只有23字節(jié)去掉協(xié)議頭后實(shí)際只能傳20字節(jié)的有效載荷長數(shù)據(jù)必須分包發(fā)送。APPEnd點(diǎn)在于MTU可以協(xié)商手機(jī)端發(fā)起MTU請(qǐng)求把值提升到247字節(jié)這樣就大大緩解了分包壓力。我在Android端把MTU協(xié)商到512字節(jié)后實(shí)測(cè)一次能塞下當(dāng)次所有傳感器數(shù)據(jù)。BLE廣播設(shè)計(jì)也有講究。低功耗傳感器發(fā)布廣播包時(shí)要保持?jǐn)?shù)據(jù)量小最好只放設(shè)備類型和電池電量兩個(gè)字段其余數(shù)據(jù)等主設(shè)備連接后再索取。廣播間隔我設(shè)成100ms兼顧發(fā)現(xiàn)速度與功耗。如果做可連接廣播還要注意廣播類型、廠商自定義數(shù)據(jù)段的最大長度是31字節(jié)超出部分必須用掃描響應(yīng)包補(bǔ)齊。3.3 WiFi與BLE共存調(diào)度策略ESP32雖然是雙核但WiFi和BLE共用一個(gè)射頻前端硬件上不可能同時(shí)收發(fā)。很多人初用時(shí)會(huì)發(fā)現(xiàn)WiFi連著MQTTBLE也在收發(fā)數(shù)據(jù)兩者同時(shí)活躍時(shí)出現(xiàn)丟包和延遲增大。這是正常的物理約束關(guān)鍵在于如何在軟件層面調(diào)度。官方提供的共存機(jī)制包括Coexistence API和基于優(yōu)先級(jí)的仲裁。實(shí)際情況中WiFi低功耗模式Modem Sleep與BLE的掃描窗口、連接事件之間會(huì)互相搶占射頻資源。我采用的策略是給BLE連接事件設(shè)置一個(gè)固定間隔比如30ms然后讓W(xué)iFi在非BLE事件窗口內(nèi)完成數(shù)據(jù)收發(fā)。由于MQTT的數(shù)據(jù)包通常很小利用這些小窗口足夠完成心跳和狀態(tài)上報(bào)。另外雙核的任務(wù)分配也很重要。我在Core 0上跑WiFi協(xié)議棧與MQTT客戶端在Core 1上跑BLE處理和應(yīng)用主邏輯。這樣兩個(gè)協(xié)議棧不會(huì)因?yàn)橥粋€(gè)核心的算術(shù)運(yùn)算阻塞實(shí)測(cè)同WiFi環(huán)境下BLE的掃描響應(yīng)時(shí)間穩(wěn)定了很多。如果你用的是ESP32經(jīng)典款記得在setup()里調(diào)用xTaskCreatePinnedToCore()指定核心否則默認(rèn)調(diào)度會(huì)把所有任務(wù)擠在一個(gè)核上。4. 傳感器接入與數(shù)據(jù)采集實(shí)操4.1 溫濕度傳感器接入與讀數(shù)傳感器是智能家居的感官來源。我方案里最常用的是DHT22和SHT30兩個(gè)型號(hào)它們的讀數(shù)準(zhǔn)確性都足夠日常環(huán)境監(jiān)控用但接線和代碼差異很大。DHT22走單總線協(xié)議一條數(shù)據(jù)線既傳時(shí)鐘又傳數(shù)據(jù)接線最簡單VCC、GND、DATA三根線就夠了。但它的讀取時(shí)序要求很嚴(yán)格標(biāo)準(zhǔn)庫在讀取過程中會(huì)關(guān)閉中斷這段時(shí)間如果恰好有BLE事件到達(dá)就可能造成數(shù)據(jù)丟失或時(shí)序錯(cuò)亂。我的做法是把DHT22讀取放在一個(gè)獨(dú)立的定時(shí)任務(wù)里該任務(wù)以2秒周期運(yùn)行讀取完成后把結(jié)果存進(jìn)全局結(jié)構(gòu)體避免在中斷上下文里操作。SHT30走I2C總線接線多兩根線SCL、SDA但穩(wěn)定性好很多不需要像單總線那樣掐著微妙級(jí)時(shí)序。I2C的地址選擇引腳可以擴(kuò)展到多個(gè)設(shè)備適合在一個(gè)網(wǎng)關(guān)上掛多路溫濕度探頭。代碼里我直接用Adafruit的SHT31庫把Wire.begin()的兩個(gè)引腳換成自定義GPIO然后調(diào)用getEvent()把溫濕度一次性讀回來。采樣周期我也特意做成了可配置項(xiàng)因?yàn)椴煌瑘?chǎng)景對(duì)數(shù)據(jù)實(shí)時(shí)性的需求完全不同。臥室溫度監(jiān)控5秒一次綽綽有余鍋爐房這種溫度變化劇烈的場(chǎng)景可以壓縮到1秒。但采樣越頻繁BLE和WiFi的喚醒越頻繁整體功耗會(huì)明顯上升。我測(cè)過一組數(shù)據(jù)在5秒采樣周期下ESP32的平均工作電流大約為80mAWiFi持續(xù)連接如果改成1秒采樣電流直接翻倍到160mA左右。單純做網(wǎng)關(guān)還好如果是電池供電的子節(jié)點(diǎn)這點(diǎn)功耗差距就是幾周和幾天的區(qū)別。4.2 外部中斷與事件驅(qū)動(dòng)設(shè)計(jì)傳感器數(shù)據(jù)如果全用輪詢獲取一方面CPU空轉(zhuǎn)浪費(fèi)電量另一方面響應(yīng)延遲大。更好的做法是利用ESP32的外部中斷能力把“有沒有變化”的判斷交給硬件軟件只在事件發(fā)生時(shí)處理。ESP32的大部分GPIO都支持外部中斷我常用的是attachInterrupt()和GPIO矩陣觸發(fā)的ESP32專有接口。比如門窗磁傳感器接一個(gè)GPIO門打開時(shí)磁簧開關(guān)斷開電平由低變高觸發(fā)RISING中斷關(guān)閉時(shí)觸發(fā)FALLING中斷。中斷回調(diào)函數(shù)里不要做任何耗時(shí)的操作只做兩件事記錄事件時(shí)間戳、通過隊(duì)列把事件投遞給主循環(huán)處理。按鍵消抖是外部中斷里最容易踩的坑。機(jī)械開關(guān)按下瞬間會(huì)有約10~20ms的抖動(dòng)如果不加處理一次按壓會(huì)觸發(fā)多次中斷。我的做法是在中斷里用millis()與上次觸發(fā)時(shí)間做比較間隔小于50ms的事件直接忽略。這里的50ms是一個(gè)經(jīng)驗(yàn)值如果是容性觸摸按鍵可以縮到10ms機(jī)械行程開關(guān)則建議放到80ms以上。除此之外長按、短按、雙擊這類事件需要在主循環(huán)里用狀態(tài)機(jī)配合定時(shí)器來識(shí)別單純靠中斷很難區(qū)分因?yàn)橹袛嘀桓嬖V你“電平變了”不告訴你“變化持續(xù)了多久”。4.3 MQTT數(shù)據(jù)上報(bào)與云端接入網(wǎng)關(guān)把多路傳感器數(shù)據(jù)收齊后要通過WiFi上行。我在局域網(wǎng)和云端都采用MQTT協(xié)議原因是它對(duì)資源的需求比HTTP小很多連接是長連接不需要每次交互都建連釋放。MQTT的關(guān)鍵概念包括主題、QoS質(zhì)量等級(jí)和遺囑消息。以我的項(xiàng)目為例網(wǎng)關(guān)作為客戶端連接本地Mosquitto或EMQX Broker發(fā)布到home/bedroom/temperature主題QoS設(shè)為1保證至少到達(dá)一次訂閱home/bedroom/light/cmd主題接收控制指令。主題樹的結(jié)構(gòu)需要提前規(guī)劃好我習(xí)慣用“區(qū)域/設(shè)備/屬性”三層這樣的好處是上層應(yīng)用可以通過通配符#和靈活訂閱很多監(jiān)控系統(tǒng)也能直接解析出設(shè)備位置。連上MQTT之后云端接入自然就通了。如果你用的Home Assistant它自帶MQTT Discovery功能ESP32在連接成功時(shí)主動(dòng)發(fā)布homeassistant/sensor/bedroom_temp/config這類發(fā)現(xiàn)消息Home Assistant就能自動(dòng)注冊(cè)傳感器實(shí)體無需在HA側(cè)手寫YAML配置。我實(shí)測(cè)過5個(gè)傳感器節(jié)點(diǎn)接入HA從上電到設(shè)備出現(xiàn)在儀表盤上只需不到10秒大幅縮短了調(diào)試周期。提示MQTT的心跳間隔建議設(shè)在60秒到120秒之間。太短會(huì)導(dǎo)致Broker頻繁處理PINGREQ太長則會(huì)在網(wǎng)絡(luò)不穩(wěn)定時(shí)無法及時(shí)感知掉線。另外務(wù)必在客戶端里設(shè)置last will遺囑消息這樣設(shè)備異常斷電時(shí)Broker能立刻發(fā)送離線信號(hào)上層聯(lián)動(dòng)邏輯可以據(jù)此觸發(fā)告警或自動(dòng)補(bǔ)償策略。5. 手機(jī)端控制與聯(lián)動(dòng)實(shí)現(xiàn)5.1 BLE App直連控制流程手機(jī)App與ESP32的BLE交互是本地控制的兜底方案適合路由器斷網(wǎng)或ESP32尚未連接WiFi的場(chǎng)景。App的整個(gè)操作流程是掃描、連接、發(fā)現(xiàn)服務(wù)、讀寫特征值四步。掃描階段主要過濾設(shè)備名稱或廠商數(shù)據(jù)中的設(shè)備ID連接后立刻發(fā)起MTU協(xié)商Android端調(diào)用BluetoothGatt.requestMtu(247)成功后雙方可以一次傳輸更多數(shù)據(jù)然后遍歷服務(wù)列表找到我們自定義的Service和Characteristic的UUID分別注冊(cè)Notify回調(diào)并執(zhí)行Write操作。iOS的CoreBluetooth流程類似但MTU協(xié)商是系統(tǒng)自動(dòng)處理的開發(fā)者只需設(shè)置maximumWriteValueLength。我在調(diào)試階段發(fā)現(xiàn)的一個(gè)常見錯(cuò)誤是上位機(jī)寫數(shù)據(jù)后沒有確認(rèn)導(dǎo)致ESP32端遲遲沒有收到。BLE的Write操作分Write With Response和Write Without Response兩種前者保證數(shù)據(jù)送達(dá)但一幀一確認(rèn)延遲高后者速度快但有可能丟幀?？刂祁愔噶钗覐?qiáng)烈建議使用Write With Response安全優(yōu)先數(shù)據(jù)采集類的Notify上報(bào)則天然帶ACK機(jī)制不受這個(gè)約束。App在開發(fā)過程中另一個(gè)坑是權(quán)限適配。Android 12以后定位權(quán)限和附近的設(shè)備權(quán)限在BLE掃描時(shí)必須同時(shí)申請(qǐng)否則掃描回調(diào)根本不會(huì)觸發(fā)。iOS則需要在Info.plist里聲明NSBluetoothAlwaysUsageDescription。這些權(quán)限申請(qǐng)如果不提前處理好用戶裝好App后點(diǎn)“掃描”沒反應(yīng)排查半天才發(fā)現(xiàn)是權(quán)限問題非常影響體驗(yàn)。5.2 WiFi局域網(wǎng)控制與狀態(tài)同步BLE直連適合單設(shè)備控制但要實(shí)現(xiàn)多設(shè)備聯(lián)動(dòng)或遠(yuǎn)程控制就必須依賴WiFi通道。我在ESP32上同時(shí)啟用了HTTP REST服務(wù)和TCP Socket服務(wù)前者適合App低頻查詢狀態(tài)后者用于實(shí)時(shí)推送傳感器數(shù)據(jù)。HTTP REST接口很簡單ESP32內(nèi)嵌WebServer監(jiān)聽80端口對(duì)外暴露幾個(gè)路由GET /api/status返回全部設(shè)備狀態(tài)POST /api/control下發(fā)控制命令。手機(jī)App在局域網(wǎng)內(nèi)直接通過ESP32的IP地址訪問這些接口。這里有個(gè)實(shí)操細(xì)節(jié)ESP32的IP不建議使用路由器DHCP動(dòng)態(tài)分配我把它在路由器后臺(tái)設(shè)置成靜態(tài)IP綁定這樣App端不用每次掃描IP直接在配置文件中填固定地址即可。Socket服務(wù)用WebSocket實(shí)現(xiàn)好處是手機(jī)端和網(wǎng)關(guān)能保持一個(gè)長連接網(wǎng)關(guān)收到BLE傳感器的變化后立即通過WebSocket推送到手機(jī)延遲在百毫秒級(jí)體驗(yàn)明顯優(yōu)于手機(jī)端輪詢HTTP接口。實(shí)測(cè)在同一WiFi環(huán)境下從傳感器數(shù)據(jù)變化到手機(jī)界面刷新平均耗時(shí)230ms左右體感基本無延遲。如果你需要遠(yuǎn)程控制那就把ESP32的數(shù)據(jù)通過MQTT上行到云端Broker手機(jī)App在外網(wǎng)也訂閱相同的主題。這樣本地與遠(yuǎn)程共用一個(gè)協(xié)議棧邏輯統(tǒng)一不需要做兩套接口。聯(lián)動(dòng)策略比如“溫濕度超過28度自動(dòng)打開空調(diào)”這類自動(dòng)化最好由Home Assistant或云端規(guī)則引擎來執(zhí)行ESP32只負(fù)責(zé)穩(wěn)定上報(bào)數(shù)據(jù)與可靠接收指令不要把業(yè)務(wù)邏輯寫進(jìn)設(shè)備固件。設(shè)備固件寫多了每次改策略都要OTA升級(jí)非常痛苦。6. 常見問題與調(diào)試實(shí)錄6.1 高頻故障與排查思路頭一個(gè)逃不開的問題是WiFi連接不穩(wěn)定表現(xiàn)為過一段時(shí)間就掉線重連。排查時(shí)最常用的手段是開啟ESP32的WiFi事件日志觀察掉線前的錯(cuò)誤碼是WL_DISCONNECTED還是WL_CONNECTION_LOST。如果是前者通常是路由器側(cè)的DHCP租期過短或WiFi密碼錯(cuò)誤后者則大概率是射頻干擾或距離太遠(yuǎn)。我遇到過一個(gè)典型案例調(diào)試一臺(tái)放在金屬配電柜里的網(wǎng)關(guān)WiFi每20分鐘就掉一次后來發(fā)現(xiàn)是柜體金屬屏蔽了天線信號(hào)把天線外置后才穩(wěn)定。BLE數(shù)據(jù)丟包同樣是個(gè)高頻問題表現(xiàn)是傳感器端的讀數(shù)時(shí)有時(shí)無。我檢查過的幾個(gè)方向包括BLE廣播間隔設(shè)置過短導(dǎo)致同頻碰撞、傳感器電池電壓不足導(dǎo)致廣播功率衰減、以及GATT Notify發(fā)送隊(duì)列溢出。解決方法是提高廣播間隔至150ms以上同時(shí)開啟BLE的流控功能讓發(fā)送速率適配接收端的處理能力。還有一個(gè)很隱蔽的問題ESP32同時(shí)作為BLE掃描者和外設(shè)時(shí)掃描窗口和廣播事件之間的仲裁邏輯遠(yuǎn)比純掃描復(fù)雜建議不要讓一個(gè)ESP32同時(shí)做中心和外圍必要時(shí)拆成兩個(gè)模組分擔(dān)。再一個(gè)常見問題是OTA升級(jí)中斷導(dǎo)致變磚。大多數(shù)情況下是固件鏡像超過分區(qū)大小限制或者升級(jí)過程斷電。我的應(yīng)對(duì)方案是使用雙分區(qū)OTA機(jī)制保留一個(gè)可回滾的factory分區(qū)同時(shí)升級(jí)前校驗(yàn)固件哈希失敗時(shí)自動(dòng)回滾到舊版本。Arduino環(huán)境下Update庫已經(jīng)封裝好了這些功能但要記得在Update.begin()時(shí)明確傳入固件總大小否則容易寫入越界。6.2 問題速查表故障現(xiàn)象可能原因解決思路SmartConfig一直收不到配網(wǎng)信息手機(jī)連接的是5GHz頻段 / 路由器AP隔離開啟手機(jī)切換到2.4GHz關(guān)閉AP隔離Web配網(wǎng)頁面打不開ESP32 SoftAP未啟動(dòng) / 網(wǎng)關(guān)IP被占用檢查瀏覽器訪問192.168.4.1前熱點(diǎn)是否已連接WiFi頻繁掉線DHCP租期過短 / 信號(hào)弱 / 供電不足靜態(tài)IP綁定換5V/2A電源檢查供電紋波BLE連接成功但收不到NotifyMTU協(xié)商失敗 / 特征值UUID不匹配確認(rèn)requestMtu成功比對(duì)UUID大小端MQTT連接被拒絕Broker地址錯(cuò)誤 / 客戶端ID沖突換唯一clientId檢查Broker日志上傳固件卡在“Connecting”串口芯片驅(qū)動(dòng)異常 / 板子未進(jìn)入下載模式重裝CH340驅(qū)動(dòng)按住BOOT鍵再點(diǎn)上傳編譯時(shí)報(bào)Flash溢出App分區(qū)過小 / 代碼庫體積過大使用自定義分區(qū)表增大App分區(qū)或換大Flash板子傳感器讀數(shù)總是不更新單總線時(shí)序被中斷干擾給傳感器任務(wù)綁定核心讀取期間屏蔽BLE任務(wù)調(diào)度6.3 整理幾條調(diào)試心得一是善用日志層級(jí)。我習(xí)慣在Debug模式下把ESP32的日志級(jí)別設(shè)為CORE_DEBUG_LEVEL_VERBOSE這樣WiFi事件、BLE事件、系統(tǒng)任務(wù)調(diào)度全都打印到串口排查問題速度快很多產(chǎn)品發(fā)布前再改成ERROR級(jí)別避免日志輸出影響性能和干擾射頻時(shí)序。二是保留一個(gè)完整可復(fù)現(xiàn)的基線固件。每次大改前先把當(dāng)前可用版本另存一份不要在一根線上反復(fù)改來改去。有一次我在加新傳感器時(shí)把BLE服務(wù)結(jié)構(gòu)改了導(dǎo)致舊App直接連不上花了整個(gè)下午才靠基線和git回滾恢復(fù)。從那以后我所有固件都啟用了Git倉庫管理并且每個(gè)里程碑打tag。三是外圍電路的坑往往比芯片本身的坑更大。ESP32的模組對(duì)電源的紋波很敏感我用示波器量過供電電壓在2.7V以下時(shí)WiFi發(fā)射瞬間會(huì)把電壓拉低到復(fù)位閾值造成模組反復(fù)重啟。解決方法是給電源入口加一顆470μF的電解電容和0.1μF陶瓷電容組合實(shí)測(cè)穩(wěn)壓效果立竿見影。四是善用邏輯分析儀和協(xié)議嗅探工具。BLE空包分析可以用nRF Connect工具WiFi抓包則用路由器管理界面的包捕獲。有一次我排查手機(jī)App收不到設(shè)備狀態(tài)的問題用nRF Connect發(fā)現(xiàn)ESP32的Notify數(shù)據(jù)實(shí)際上已經(jīng)發(fā)出去了問題出在App端的UUID大小端解析反了幾分鐘就定位到了根因。這套基于ESP32的WiFiBLE雙模智能家居方案我在實(shí)際項(xiàng)目里跑了大半年從最初單點(diǎn)控制到后來穩(wěn)定接入十來個(gè)BLE傳感器節(jié)點(diǎn)并聯(lián)動(dòng)HA平臺(tái)中間踩過的坑基本上都寫在這里了。如果你也是自己折騰智能家居建議第一版先別追求功能多把配網(wǎng)、BLE數(shù)據(jù)匯聚、MQTT上云這三條主鏈路跑通外殼和照明控制那些外圍功能后續(xù)再一點(diǎn)點(diǎn)加上去。鏈路通了之后擴(kuò)展新設(shè)備幾乎就是加代碼配置文件的事整體方案的天花板會(huì)高很多。 ESP32雙模網(wǎng)關(guān)實(shí)戰(zhàn)：從硬件選型到App控制完整鏈路
看到不少人在智能家居上折騰最頭疼的就是“協(xié)議不統(tǒng)一”和“平臺(tái)鎖定”這兩個(gè)問題。用樹莓派當(dāng)網(wǎng)關(guān)性能和價(jià)格都過了頭還費(fèi)電用STM32自己做WiFi模塊和藍(lán)牙模塊電路復(fù)雜化調(diào)起來特別折磨人。ESP32幾乎是這個(gè)場(chǎng)景下的最優(yōu)解一顆芯片同時(shí)集成了WiFi和BLE雙核240MHz的處理能力拿來做協(xié)議匯聚綽綽有余價(jià)格卻只要十幾塊錢。這篇文章我用實(shí)際做過的整套方案把從硬件選型、開發(fā)環(huán)境、雙模通信、傳感器接入到App控制端的完整鏈路都拆開給你看應(yīng)該能幫你少走不少彎路。1. 方案定位與整體思路拆解1.1 為什么是ESP32而不是樹莓派或STM32很多人第一次做智能家居網(wǎng)關(guān)都會(huì)在樹莓派、STM32和ESP32之間猶豫。我的判斷標(biāo)準(zhǔn)很簡單看你需要什么級(jí)別的“智力”放在設(shè)備端。樹莓派本質(zhì)是一臺(tái)跑Linux的小電腦它當(dāng)然能裝Home Assistant、Node-RED這些全家桶也能同時(shí)接USB攝像頭和一堆傳感器。但代價(jià)是功耗基本在3W以上開機(jī)要以分鐘計(jì)系統(tǒng)卡了還得去排查SD卡分區(qū)問題。如果你只是想控制幾個(gè)燈、讀取幾個(gè)傳感器、做點(diǎn)自動(dòng)化聯(lián)動(dòng)樹莓派是典型的重型武器殺雞用牛刀還費(fèi)電。STM32是另一種極端。它的實(shí)時(shí)性和生態(tài)在工業(yè)控制領(lǐng)域沒得說但問題是無線通信能力要靠外掛模塊實(shí)現(xiàn)。一片ESP8266搞定WiFi一片nRF52832搞定藍(lán)牙兩套固件、兩套電源、兩套天線布局中途還要處理模塊間的UART通信協(xié)議。電路復(fù)雜度和調(diào)試成本直接翻倍特別是天線阻抗匹配和射頻走線對(duì)新手門檻極高。ESP32卡在兩者之間剛好合適。它集成了2.4GHz WiFi和藍(lán)牙雙模雙核Xtensa處理器跑到240MHz520KB SRAM加4MB Flash跑輕量級(jí)的FreeRTOS任務(wù)調(diào)度毫無壓力。更重要的是它支持SmartConfig一鍵配網(wǎng)、BLE GATT服務(wù)、OTA升級(jí)以及各類外設(shè)接口。這意味著你完全可以把它既當(dāng)傳感器節(jié)點(diǎn)又當(dāng)智能家居網(wǎng)關(guān)——所有設(shè)備統(tǒng)一接入它再由它上行到局域網(wǎng)或云端。這套邏輯用一句話總結(jié)一顆ESP32吃掉“接入層”和“匯聚層”兩件事。1.2 一站式方案的分層架構(gòu)整個(gè)方案我按三層來拆解每層職責(zé)清晰后續(xù)擴(kuò)展新設(shè)備時(shí)不需要推倒重來。第一層是設(shè)備接入層主要使用BLE低功耗傳感器節(jié)點(diǎn)。比如溫濕度計(jì)、門窗磁、人體存在傳感器它們干完活就睡功耗降到微安級(jí)一顆紐扣電池?fù)伟肽晟踔粮谩５诙邮蔷W(wǎng)關(guān)控制層由ESP32承擔(dān)。它同時(shí)開啟WiFi站模式和藍(lán)牙掃描/連接功能一方面通過BLE GATT收集傳感器數(shù)據(jù)另一方面通過WiFi與路由器、MQTT Broker或手機(jī)App通信。第三層是應(yīng)用交互層包括手機(jī)端App、Web儀表盤或Home Assistant這類開源平臺(tái)。這套架構(gòu)避免了“每個(gè)設(shè)備都要連路由器”的困境。很多廉價(jià)BLE傳感器不支持WiFi或者連接WiFi協(xié)議棧開銷太大它們只要找到ESP32即可。反過來ESP32把多路BLE數(shù)據(jù)匯聚成統(tǒng)一的JSON格式后通過WiFi統(tǒng)一上云或推送到手機(jī)。從實(shí)踐來看分層的核心好處是傳感器端改動(dòng)極小網(wǎng)關(guān)端的代碼穩(wěn)定性高上層應(yīng)用只對(duì)接網(wǎng)關(guān)API接口就夠了。2. 硬件選型與開發(fā)環(huán)境搭建2.1 主控選型ESP32、ESP32-S3、ESP32-C3怎么挑很多人拿到ESP32這個(gè)總稱就以為只有一個(gè)型號(hào)實(shí)際上樂鑫的芯片線已經(jīng)分岔得很細(xì)了。我在這套方案里分別用過的3個(gè)系列各自的適用場(chǎng)景差異明顯選錯(cuò)的話后期會(huì)很痛苦。芯片型號(hào)核心架構(gòu)主頻/內(nèi)存無線特性典型開發(fā)板適用場(chǎng)景ESP32經(jīng)典款雙核Xtensa LX6240MHz / 520KB SRAMWiFi 802.11 b/g/n BLE 4.2ESP32 DevKitC、NodeMCU-32S網(wǎng)關(guān)主力外設(shè)豐富資料最多ESP32-S3雙核Xtensa LX7240MHz / 512KB SRAMWiFi BLE 5.0支持向量指令加速ESP32-S3-DevKitC-1AI語音、LCD人機(jī)交互界面、更高算力需求ESP32-C3單核RISC-V160MHz / 400KB SRAMWiFi BLE 5.0ESP32-C3-DevKitM-1、Seeed XIAO ESP32C3低成本傳感器節(jié)點(diǎn)GPIO少但夠用我實(shí)際做網(wǎng)關(guān)用的是經(jīng)典款ESP32因?yàn)樗腉PIO最全、社區(qū)資料最多踩到坑隨時(shí)能搜到答案。做子設(shè)備節(jié)點(diǎn)時(shí)用ESP32-C3更劃算C3雖然只有一個(gè)核心、主頻低但應(yīng)對(duì)BLE傳感器數(shù)據(jù)采集完全夠用PCB尺寸和功耗都更友好。S3那款我在升級(jí)版里用過主要是需要驅(qū)動(dòng)彩色觸摸屏做家庭控制面板時(shí)發(fā)揮算力優(yōu)勢(shì)日常做網(wǎng)關(guān)其實(shí)有點(diǎn)浪費(fèi)。選型還有一個(gè)容易忽略的點(diǎn)外接Flash容量。ESP32經(jīng)典款板載4MB Flash如果你要上Web配網(wǎng)界面、TFT_eSPI字體庫、MQTT證書、OTA雙分區(qū)4MB會(huì)比較吃緊。建議優(yōu)先選8MB或16MB Flash的版本或者干脆用支持PSRAM的WROVER系列模組給動(dòng)態(tài)內(nèi)存留出余量。2.2 開發(fā)環(huán)境與國內(nèi)源配置開發(fā)環(huán)境我推薦直接用Arduino IDE加esp32核心理由很實(shí)在上手門檻低、庫生態(tài)全、排錯(cuò)資源多。另一種常用路線是PlatformIO Visual Studio Code工程管理和依賴庫版本控制更規(guī)范適合寫大項(xiàng)目或多人協(xié)作。我個(gè)人的習(xí)慣是快速原型驗(yàn)證用Arduino正式項(xiàng)目用PlatformIO。安裝ESP32核心時(shí)最大的痛點(diǎn)在國內(nèi)網(wǎng)絡(luò)環(huán)境里尤其明顯默認(rèn)從GitHub下載的JSON索引文件和工具鏈經(jīng)常失敗或龜速。解決方案是換用國內(nèi)鏡像源。在Arduino IDE的“文件—首選項(xiàng)—附加開發(fā)板管理器網(wǎng)址”里填入樂鑫官方在國內(nèi)托管的包索引地址或者直接使用阿里云的鏡像地址。添加后打開開發(fā)板管理器搜索esp32安裝即可。PlatformIO用戶也一樣可以在“PlatformIO Registry”中配置國內(nèi)鏡像加速或者使用社區(qū)打包的離線包。我提到離線包是因?yàn)橛信笥延龅焦驹趦?nèi)網(wǎng)開發(fā)、完全連不上外網(wǎng)的情況這時(shí)候離線包幾乎是唯一解。安裝后記得把“PlatformIO Core”的包管理源指向內(nèi)網(wǎng)鏡像否則依賴庫拉取一樣會(huì)卡死。注意無論用哪種方式安裝完成后先編譯一個(gè)Blink例程驗(yàn)證工具鏈沒問題再開始正式代碼。很多編譯報(bào)錯(cuò)其實(shí)都源于環(huán)境沒裝干凈。2.3 燒錄方式的取舍ESP32的燒錄方式有3種按使用頻率排序是USB串口、JTAG和OTA。USB串口是日常開發(fā)的主力通過板載CP2102或CH340芯片把USB信號(hào)轉(zhuǎn)成UART。接線很簡單只需TXD、RXD、GND三根線部分板子還要短接EN和GND進(jìn)入下載模式。需要留意的是不同板子的串口芯片驅(qū)動(dòng)差異很大老版本CH340在macOS上經(jīng)常要手動(dòng)裝驅(qū)動(dòng)而且安裝后還要在“系統(tǒng)設(shè)置—隱私與安全性”里放行內(nèi)核擴(kuò)展否則上傳時(shí)必卡在“Connecting...”。JTAG調(diào)試功能在ESP32-S3和C3上更完善官方推薦的USB JTAG接口可以做到單線調(diào)試、斷點(diǎn)設(shè)置和實(shí)時(shí)變量查看。這塊調(diào)試能力對(duì)排查HardFault或者棧溢出極有幫助但配置稍微復(fù)雜一些新手不建議作為首選。OTA升級(jí)是產(chǎn)品化之后必需的燒錄方式。ESP32原生支持通過WiFi把固件升級(jí)到當(dāng)前運(yùn)行或者備用分區(qū)配合Arduino的“OTA Update”庫手機(jī)App或Web界面就能推送新固件不用拆機(jī)接串口。我的方案里固件分區(qū)表是必須訂制的默認(rèn)的1MB App分區(qū)不夠放Web資源和OTA的兩個(gè)固件要改成8MB或者更大的布局。3. WiFi與BLE雙模通信核心實(shí)現(xiàn)3.1 SmartConfig配網(wǎng)與Web配網(wǎng)實(shí)戰(zhàn)智能家居設(shè)備最讓人惱火的一環(huán)就是配網(wǎng)。傳統(tǒng)的做法是用串口助手發(fā)送WiFi名稱和密碼或者燒錄時(shí)寫死在代碼里。前者對(duì)用戶不友好后者換一個(gè)WiFi環(huán)境就要重新燒錄維護(hù)成本極高。我總共實(shí)現(xiàn)了兩種配網(wǎng)方式互為備份。SmartConfig是目前用戶體驗(yàn)最順的一種。手機(jī)App先連上家里的2.4GHz WiFi然后把WiFi的SSID和密碼通過UDP協(xié)議廣播出去。ESP32的ESP-Touch庫在混雜模式下抓取空中數(shù)據(jù)包從UDP包長度和順序里解出憑據(jù)然后自動(dòng)連接路由器。這套協(xié)議的巧妙之處在于不需要手機(jī)與ESP32先建立任何連接路由器也不需要有特殊設(shè)置只要手機(jī)和ESP32在同一頻段內(nèi)即可。代碼上大致是調(diào)用WiFi.beginSmartConfig()然后在循環(huán)里檢查WiFi.smartConfigDone()的狀態(tài)等待配網(wǎng)完成。關(guān)鍵參數(shù)里有幾個(gè)坑要提一下ESP32只支持2.4GHz頻段手機(jī)如果連著5GHz WiFi來廣播ESP32根本收不到必須先切到2.4GHz另外ESP-Touch對(duì)路由器組播報(bào)文的一些策略比較敏感某些開啟了AP隔離的路由器兼容性會(huì)變差。Web配網(wǎng)適用于首次部署且手機(jī)不太好裝App的場(chǎng)景。實(shí)現(xiàn)思路是ESP32進(jìn)入SoftAP模式熱點(diǎn)名稱類似“ESP32_Setup”手機(jī)連接該熱點(diǎn)瀏覽器訪問192.168.4.1打開嵌入式Web頁面選擇WiFi并輸入密碼。頁面通過HTTP POST把密碼提交給ESP32ESP32保存參數(shù)后切換為STA模式連接路由器。這套方案核心在于ESP32內(nèi)嵌Web服務(wù)器并生成配置頁面我通常把頁面HTML壓縮成字節(jié)數(shù)組燒錄到Flash里避免占用太多內(nèi)存。兩個(gè)方案我都做過實(shí)測(cè)SmartConfig配網(wǎng)成功率在無干擾環(huán)境下能到90%以上Web配網(wǎng)則因?yàn)榻换ゲ襟E更可控成功率接近99%所以最終產(chǎn)品里我把Web配網(wǎng)作為兜底入口保留。3.2 BLE GATT服務(wù)設(shè)計(jì)與數(shù)據(jù)交互BLE通信的骨架是GATT整個(gè)結(jié)構(gòu)從上到下是Profile、Service服務(wù)、Characteristic特征值。設(shè)計(jì)一個(gè)可擴(kuò)展的數(shù)據(jù)服務(wù)協(xié)議核心是合理規(guī)劃UUID和特征值的讀寫權(quán)限。我對(duì)接傳感器數(shù)據(jù)時(shí)在ESP32上建立了一個(gè)名為Device Data Service的自定義服務(wù)UUID用128位的自定義值避免和標(biāo)準(zhǔn)服務(wù)沖突。服務(wù)下面掛了3個(gè)特征值一個(gè)Notify類型用于ESP32主動(dòng)推送傳感器數(shù)據(jù)給手機(jī)或子設(shè)備一個(gè)Write類型用于接收手機(jī)下發(fā)的控制指令比如開關(guān)燈、調(diào)節(jié)亮度還有一個(gè)Read類型用于手機(jī)主動(dòng)查詢?cè)O(shè)備當(dāng)前狀態(tài)。所有數(shù)據(jù)交互都統(tǒng)一走JSON字符串。比如傳感器上送的數(shù)據(jù)為{type:temp,value:25.6,unit:C}控制指令下行為{cmd:set_light,state:1}。選用JSON的代價(jià)是每幀數(shù)據(jù)長度增加不少但換來的是極強(qiáng)的可維護(hù)性后期增刪字段不需要改動(dòng)GATT結(jié)構(gòu)。需要注意的是BLE的MTU默認(rèn)只有23字節(jié)去掉協(xié)議頭后實(shí)際只能傳20字節(jié)的有效載荷長數(shù)據(jù)必須分包發(fā)送。APPEnd點(diǎn)在于MTU可以協(xié)商手機(jī)端發(fā)起MTU請(qǐng)求把值提升到247字節(jié)這樣就大大緩解了分包壓力。我在Android端把MTU協(xié)商到512字節(jié)后實(shí)測(cè)一次能塞下當(dāng)次所有傳感器數(shù)據(jù)。BLE廣播設(shè)計(jì)也有講究。低功耗傳感器發(fā)布廣播包時(shí)要保持?jǐn)?shù)據(jù)量小最好只放設(shè)備類型和電池電量兩個(gè)字段其余數(shù)據(jù)等主設(shè)備連接后再索取。廣播間隔我設(shè)成100ms兼顧發(fā)現(xiàn)速度與功耗。如果做可連接廣播還要注意廣播類型、廠商自定義數(shù)據(jù)段的最大長度是31字節(jié)超出部分必須用掃描響應(yīng)包補(bǔ)齊。3.3 WiFi與BLE共存調(diào)度策略ESP32雖然是雙核但WiFi和BLE共用一個(gè)射頻前端硬件上不可能同時(shí)收發(fā)。很多人初用時(shí)會(huì)發(fā)現(xiàn)WiFi連著MQTTBLE也在收發(fā)數(shù)據(jù)兩者同時(shí)活躍時(shí)出現(xiàn)丟包和延遲增大。這是正常的物理約束關(guān)鍵在于如何在軟件層面調(diào)度。官方提供的共存機(jī)制包括Coexistence API和基于優(yōu)先級(jí)的仲裁。實(shí)際情況中WiFi低功耗模式Modem Sleep與BLE的掃描窗口、連接事件之間會(huì)互相搶占射頻資源。我采用的策略是給BLE連接事件設(shè)置一個(gè)固定間隔比如30ms然后讓W(xué)iFi在非BLE事件窗口內(nèi)完成數(shù)據(jù)收發(fā)。由于MQTT的數(shù)據(jù)包通常很小利用這些小窗口足夠完成心跳和狀態(tài)上報(bào)。另外雙核的任務(wù)分配也很重要。我在Core 0上跑WiFi協(xié)議棧與MQTT客戶端在Core 1上跑BLE處理和應(yīng)用主邏輯。這樣兩個(gè)協(xié)議棧不會(huì)因?yàn)橥粋€(gè)核心的算術(shù)運(yùn)算阻塞實(shí)測(cè)同WiFi環(huán)境下BLE的掃描響應(yīng)時(shí)間穩(wěn)定了很多。如果你用的是ESP32經(jīng)典款記得在setup()里調(diào)用xTaskCreatePinnedToCore()指定核心否則默認(rèn)調(diào)度會(huì)把所有任務(wù)擠在一個(gè)核上。4. 傳感器接入與數(shù)據(jù)采集實(shí)操4.1 溫濕度傳感器接入與讀數(shù)傳感器是智能家居的感官來源。我方案里最常用的是DHT22和SHT30兩個(gè)型號(hào)它們的讀數(shù)準(zhǔn)確性都足夠日常環(huán)境監(jiān)控用但接線和代碼差異很大。DHT22走單總線協(xié)議一條數(shù)據(jù)線既傳時(shí)鐘又傳數(shù)據(jù)接線最簡單VCC、GND、DATA三根線就夠了。但它的讀取時(shí)序要求很嚴(yán)格標(biāo)準(zhǔn)庫在讀取過程中會(huì)關(guān)閉中斷這段時(shí)間如果恰好有BLE事件到達(dá)就可能造成數(shù)據(jù)丟失或時(shí)序錯(cuò)亂。我的做法是把DHT22讀取放在一個(gè)獨(dú)立的定時(shí)任務(wù)里該任務(wù)以2秒周期運(yùn)行讀取完成后把結(jié)果存進(jìn)全局結(jié)構(gòu)體避免在中斷上下文里操作。SHT30走I2C總線接線多兩根線SCL、SDA但穩(wěn)定性好很多不需要像單總線那樣掐著微妙級(jí)時(shí)序。I2C的地址選擇引腳可以擴(kuò)展到多個(gè)設(shè)備適合在一個(gè)網(wǎng)關(guān)上掛多路溫濕度探頭。代碼里我直接用Adafruit的SHT31庫把Wire.begin()的兩個(gè)引腳換成自定義GPIO然后調(diào)用getEvent()把溫濕度一次性讀回來。采樣周期我也特意做成了可配置項(xiàng)因?yàn)椴煌瑘?chǎng)景對(duì)數(shù)據(jù)實(shí)時(shí)性的需求完全不同。臥室溫度監(jiān)控5秒一次綽綽有余鍋爐房這種溫度變化劇烈的場(chǎng)景可以壓縮到1秒。但采樣越頻繁BLE和WiFi的喚醒越頻繁整體功耗會(huì)明顯上升。我測(cè)過一組數(shù)據(jù)在5秒采樣周期下ESP32的平均工作電流大約為80mAWiFi持續(xù)連接如果改成1秒采樣電流直接翻倍到160mA左右。單純做網(wǎng)關(guān)還好如果是電池供電的子節(jié)點(diǎn)這點(diǎn)功耗差距就是幾周和幾天的區(qū)別。4.2 外部中斷與事件驅(qū)動(dòng)設(shè)計(jì)傳感器數(shù)據(jù)如果全用輪詢獲取一方面CPU空轉(zhuǎn)浪費(fèi)電量另一方面響應(yīng)延遲大。更好的做法是利用ESP32的外部中斷能力把“有沒有變化”的判斷交給硬件軟件只在事件發(fā)生時(shí)處理。ESP32的大部分GPIO都支持外部中斷我常用的是attachInterrupt()和GPIO矩陣觸發(fā)的ESP32專有接口。比如門窗磁傳感器接一個(gè)GPIO門打開時(shí)磁簧開關(guān)斷開電平由低變高觸發(fā)RISING中斷關(guān)閉時(shí)觸發(fā)FALLING中斷。中斷回調(diào)函數(shù)里不要做任何耗時(shí)的操作只做兩件事記錄事件時(shí)間戳、通過隊(duì)列把事件投遞給主循環(huán)處理。按鍵消抖是外部中斷里最容易踩的坑。機(jī)械開關(guān)按下瞬間會(huì)有約10~20ms的抖動(dòng)如果不加處理一次按壓會(huì)觸發(fā)多次中斷。我的做法是在中斷里用millis()與上次觸發(fā)時(shí)間做比較間隔小于50ms的事件直接忽略。這里的50ms是一個(gè)經(jīng)驗(yàn)值如果是容性觸摸按鍵可以縮到10ms機(jī)械行程開關(guān)則建議放到80ms以上。除此之外長按、短按、雙擊這類事件需要在主循環(huán)里用狀態(tài)機(jī)配合定時(shí)器來識(shí)別單純靠中斷很難區(qū)分因?yàn)橹袛嘀桓嬖V你“電平變了”不告訴你“變化持續(xù)了多久”。4.3 MQTT數(shù)據(jù)上報(bào)與云端接入網(wǎng)關(guān)把多路傳感器數(shù)據(jù)收齊后要通過WiFi上行。我在局域網(wǎng)和云端都采用MQTT協(xié)議原因是它對(duì)資源的需求比HTTP小很多連接是長連接不需要每次交互都建連釋放。MQTT的關(guān)鍵概念包括主題、QoS質(zhì)量等級(jí)和遺囑消息。以我的項(xiàng)目為例網(wǎng)關(guān)作為客戶端連接本地Mosquitto或EMQX Broker發(fā)布到home/bedroom/temperature主題QoS設(shè)為1保證至少到達(dá)一次訂閱home/bedroom/light/cmd主題接收控制指令。主題樹的結(jié)構(gòu)需要提前規(guī)劃好我習(xí)慣用“區(qū)域/設(shè)備/屬性”三層這樣的好處是上層應(yīng)用可以通過通配符#和靈活訂閱很多監(jiān)控系統(tǒng)也能直接解析出設(shè)備位置。連上MQTT之后云端接入自然就通了。如果你用的Home Assistant它自帶MQTT Discovery功能ESP32在連接成功時(shí)主動(dòng)發(fā)布homeassistant/sensor/bedroom_temp/config這類發(fā)現(xiàn)消息Home Assistant就能自動(dòng)注冊(cè)傳感器實(shí)體無需在HA側(cè)手寫YAML配置。我實(shí)測(cè)過5個(gè)傳感器節(jié)點(diǎn)接入HA從上電到設(shè)備出現(xiàn)在儀表盤上只需不到10秒大幅縮短了調(diào)試周期。提示MQTT的心跳間隔建議設(shè)在60秒到120秒之間。太短會(huì)導(dǎo)致Broker頻繁處理PINGREQ太長則會(huì)在網(wǎng)絡(luò)不穩(wěn)定時(shí)無法及時(shí)感知掉線。另外務(wù)必在客戶端里設(shè)置last will遺囑消息這樣設(shè)備異常斷電時(shí)Broker能立刻發(fā)送離線信號(hào)上層聯(lián)動(dòng)邏輯可以據(jù)此觸發(fā)告警或自動(dòng)補(bǔ)償策略。5. 手機(jī)端控制與聯(lián)動(dòng)實(shí)現(xiàn)5.1 BLE App直連控制流程手機(jī)App與ESP32的BLE交互是本地控制的兜底方案適合路由器斷網(wǎng)或ESP32尚未連接WiFi的場(chǎng)景。App的整個(gè)操作流程是掃描、連接、發(fā)現(xiàn)服務(wù)、讀寫特征值四步。掃描階段主要過濾設(shè)備名稱或廠商數(shù)據(jù)中的設(shè)備ID連接后立刻發(fā)起MTU協(xié)商Android端調(diào)用BluetoothGatt.requestMtu(247)成功后雙方可以一次傳輸更多數(shù)據(jù)然后遍歷服務(wù)列表找到我們自定義的Service和Characteristic的UUID分別注冊(cè)Notify回調(diào)并執(zhí)行Write操作。iOS的CoreBluetooth流程類似但MTU協(xié)商是系統(tǒng)自動(dòng)處理的開發(fā)者只需設(shè)置maximumWriteValueLength。我在調(diào)試階段發(fā)現(xiàn)的一個(gè)常見錯(cuò)誤是上位機(jī)寫數(shù)據(jù)后沒有確認(rèn)導(dǎo)致ESP32端遲遲沒有收到。BLE的Write操作分Write With Response和Write Without Response兩種前者保證數(shù)據(jù)送達(dá)但一幀一確認(rèn)延遲高后者速度快但有可能丟幀?？刂祁愔噶钗覐?qiáng)烈建議使用Write With Response安全優(yōu)先數(shù)據(jù)采集類的Notify上報(bào)則天然帶ACK機(jī)制不受這個(gè)約束。App在開發(fā)過程中另一個(gè)坑是權(quán)限適配。Android 12以后定位權(quán)限和附近的設(shè)備權(quán)限在BLE掃描時(shí)必須同時(shí)申請(qǐng)否則掃描回調(diào)根本不會(huì)觸發(fā)。iOS則需要在Info.plist里聲明NSBluetoothAlwaysUsageDescription。這些權(quán)限申請(qǐng)如果不提前處理好用戶裝好App后點(diǎn)“掃描”沒反應(yīng)排查半天才發(fā)現(xiàn)是權(quán)限問題非常影響體驗(yàn)。5.2 WiFi局域網(wǎng)控制與狀態(tài)同步BLE直連適合單設(shè)備控制但要實(shí)現(xiàn)多設(shè)備聯(lián)動(dòng)或遠(yuǎn)程控制就必須依賴WiFi通道。我在ESP32上同時(shí)啟用了HTTP REST服務(wù)和TCP Socket服務(wù)前者適合App低頻查詢狀態(tài)后者用于實(shí)時(shí)推送傳感器數(shù)據(jù)。HTTP REST接口很簡單ESP32內(nèi)嵌WebServer監(jiān)聽80端口對(duì)外暴露幾個(gè)路由GET /api/status返回全部設(shè)備狀態(tài)POST /api/control下發(fā)控制命令。手機(jī)App在局域網(wǎng)內(nèi)直接通過ESP32的IP地址訪問這些接口。這里有個(gè)實(shí)操細(xì)節(jié)ESP32的IP不建議使用路由器DHCP動(dòng)態(tài)分配我把它在路由器后臺(tái)設(shè)置成靜態(tài)IP綁定這樣App端不用每次掃描IP直接在配置文件中填固定地址即可。Socket服務(wù)用WebSocket實(shí)現(xiàn)好處是手機(jī)端和網(wǎng)關(guān)能保持一個(gè)長連接網(wǎng)關(guān)收到BLE傳感器的變化后立即通過WebSocket推送到手機(jī)延遲在百毫秒級(jí)體驗(yàn)明顯優(yōu)于手機(jī)端輪詢HTTP接口。實(shí)測(cè)在同一WiFi環(huán)境下從傳感器數(shù)據(jù)變化到手機(jī)界面刷新平均耗時(shí)230ms左右體感基本無延遲。如果你需要遠(yuǎn)程控制那就把ESP32的數(shù)據(jù)通過MQTT上行到云端Broker手機(jī)App在外網(wǎng)也訂閱相同的主題。這樣本地與遠(yuǎn)程共用一個(gè)協(xié)議棧邏輯統(tǒng)一不需要做兩套接口。聯(lián)動(dòng)策略比如“溫濕度超過28度自動(dòng)打開空調(diào)”這類自動(dòng)化最好由Home Assistant或云端規(guī)則引擎來執(zhí)行ESP32只負(fù)責(zé)穩(wěn)定上報(bào)數(shù)據(jù)與可靠接收指令不要把業(yè)務(wù)邏輯寫進(jìn)設(shè)備固件。設(shè)備固件寫多了每次改策略都要OTA升級(jí)非常痛苦。6. 常見問題與調(diào)試實(shí)錄6.1 高頻故障與排查思路頭一個(gè)逃不開的問題是WiFi連接不穩(wěn)定表現(xiàn)為過一段時(shí)間就掉線重連。排查時(shí)最常用的手段是開啟ESP32的WiFi事件日志觀察掉線前的錯(cuò)誤碼是WL_DISCONNECTED還是WL_CONNECTION_LOST。如果是前者通常是路由器側(cè)的DHCP租期過短或WiFi密碼錯(cuò)誤后者則大概率是射頻干擾或距離太遠(yuǎn)。我遇到過一個(gè)典型案例調(diào)試一臺(tái)放在金屬配電柜里的網(wǎng)關(guān)WiFi每20分鐘就掉一次后來發(fā)現(xiàn)是柜體金屬屏蔽了天線信號(hào)把天線外置后才穩(wěn)定。BLE數(shù)據(jù)丟包同樣是個(gè)高頻問題表現(xiàn)是傳感器端的讀數(shù)時(shí)有時(shí)無。我檢查過的幾個(gè)方向包括BLE廣播間隔設(shè)置過短導(dǎo)致同頻碰撞、傳感器電池電壓不足導(dǎo)致廣播功率衰減、以及GATT Notify發(fā)送隊(duì)列溢出。解決方法是提高廣播間隔至150ms以上同時(shí)開啟BLE的流控功能讓發(fā)送速率適配接收端的處理能力。還有一個(gè)很隱蔽的問題ESP32同時(shí)作為BLE掃描者和外設(shè)時(shí)掃描窗口和廣播事件之間的仲裁邏輯遠(yuǎn)比純掃描復(fù)雜建議不要讓一個(gè)ESP32同時(shí)做中心和外圍必要時(shí)拆成兩個(gè)模組分擔(dān)。再一個(gè)常見問題是OTA升級(jí)中斷導(dǎo)致變磚。大多數(shù)情況下是固件鏡像超過分區(qū)大小限制或者升級(jí)過程斷電。我的應(yīng)對(duì)方案是使用雙分區(qū)OTA機(jī)制保留一個(gè)可回滾的factory分區(qū)同時(shí)升級(jí)前校驗(yàn)固件哈希失敗時(shí)自動(dòng)回滾到舊版本。Arduino環(huán)境下Update庫已經(jīng)封裝好了這些功能但要記得在Update.begin()時(shí)明確傳入固件總大小否則容易寫入越界。6.2 問題速查表故障現(xiàn)象可能原因解決思路SmartConfig一直收不到配網(wǎng)信息手機(jī)連接的是5GHz頻段 / 路由器AP隔離開啟手機(jī)切換到2.4GHz關(guān)閉AP隔離Web配網(wǎng)頁面打不開ESP32 SoftAP未啟動(dòng) / 網(wǎng)關(guān)IP被占用檢查瀏覽器訪問192.168.4.1前熱點(diǎn)是否已連接WiFi頻繁掉線DHCP租期過短 / 信號(hào)弱 / 供電不足靜態(tài)IP綁定換5V/2A電源檢查供電紋波BLE連接成功但收不到NotifyMTU協(xié)商失敗 / 特征值UUID不匹配確認(rèn)requestMtu成功比對(duì)UUID大小端MQTT連接被拒絕Broker地址錯(cuò)誤 / 客戶端ID沖突換唯一clientId檢查Broker日志上傳固件卡在“Connecting”串口芯片驅(qū)動(dòng)異常 / 板子未進(jìn)入下載模式重裝CH340驅(qū)動(dòng)按住BOOT鍵再點(diǎn)上傳編譯時(shí)報(bào)Flash溢出App分區(qū)過小 / 代碼庫體積過大使用自定義分區(qū)表增大App分區(qū)或換大Flash板子傳感器讀數(shù)總是不更新單總線時(shí)序被中斷干擾給傳感器任務(wù)綁定核心讀取期間屏蔽BLE任務(wù)調(diào)度6.3 整理幾條調(diào)試心得一是善用日志層級(jí)。我習(xí)慣在Debug模式下把ESP32的日志級(jí)別設(shè)為CORE_DEBUG_LEVEL_VERBOSE這樣WiFi事件、BLE事件、系統(tǒng)任務(wù)調(diào)度全都打印到串口排查問題速度快很多產(chǎn)品發(fā)布前再改成ERROR級(jí)別避免日志輸出影響性能和干擾射頻時(shí)序。二是保留一個(gè)完整可復(fù)現(xiàn)的基線固件。每次大改前先把當(dāng)前可用版本另存一份不要在一根線上反復(fù)改來改去。有一次我在加新傳感器時(shí)把BLE服務(wù)結(jié)構(gòu)改了導(dǎo)致舊App直接連不上花了整個(gè)下午才靠基線和git回滾恢復(fù)。從那以后我所有固件都啟用了Git倉庫管理并且每個(gè)里程碑打tag。三是外圍電路的坑往往比芯片本身的坑更大。ESP32的模組對(duì)電源的紋波很敏感我用示波器量過供電電壓在2.7V以下時(shí)WiFi發(fā)射瞬間會(huì)把電壓拉低到復(fù)位閾值造成模組反復(fù)重啟。解決方法是給電源入口加一顆470μF的電解電容和0.1μF陶瓷電容組合實(shí)測(cè)穩(wěn)壓效果立竿見影。四是善用邏輯分析儀和協(xié)議嗅探工具。BLE空包分析可以用nRF Connect工具WiFi抓包則用路由器管理界面的包捕獲。有一次我排查手機(jī)App收不到設(shè)備狀態(tài)的問題用nRF Connect發(fā)現(xiàn)ESP32的Notify數(shù)據(jù)實(shí)際上已經(jīng)發(fā)出去了問題出在App端的UUID大小端解析反了幾分鐘就定位到了根因。這套基于ESP32的WiFiBLE雙模智能家居方案我在實(shí)際項(xiàng)目里跑了大半年從最初單點(diǎn)控制到后來穩(wěn)定接入十來個(gè)BLE傳感器節(jié)點(diǎn)并聯(lián)動(dòng)HA平臺(tái)中間踩過的坑基本上都寫在這里了。如果你也是自己折騰智能家居建議第一版先別追求功能多把配網(wǎng)、BLE數(shù)據(jù)匯聚、MQTT上云這三條主鏈路跑通外殼和照明控制那些外圍功能后續(xù)再一點(diǎn)點(diǎn)加上去。鏈路通了之后擴(kuò)展新設(shè)備幾乎就是加代碼配置文件的事整體方案的天花板會(huì)高很多。