做智能家居項(xiàng)目有一段時(shí)間了從最開始用手機(jī)藍(lán)牙控制一盞燈到后面把設(shè)備真正接入云平臺(tái)中間踩了不少坑。這次分享的是一個(gè)我最近完整跑通的實(shí)戰(zhàn)項(xiàng)目基于STM32做設(shè)備端主控通過(guò)華為云IoT平臺(tái)做設(shè)備接入和消息轉(zhuǎn)發(fā)再用Qt寫一個(gè)跨平臺(tái)桌面客戶端最終實(shí)現(xiàn)一套能查看溫濕度、遠(yuǎn)程控制開關(guān)的智能家居控制系統(tǒng)。這套方案最大的價(jià)值在于把嵌入式、云平臺(tái)和桌面應(yīng)用三段鏈路串起來(lái)適合正在學(xué)習(xí)STM32、準(zhǔn)備接觸云平臺(tái)或者是想從單片機(jī)跳到物聯(lián)網(wǎng)方向的朋友。文章里不會(huì)只講概念而是把整條鏈路的架構(gòu)、關(guān)鍵代碼、參數(shù)計(jì)算和常見問(wèn)題都攤開來(lái)講照著步驟走基本能復(fù)現(xiàn)一個(gè)可以用的原型。1. 系統(tǒng)架構(gòu)與方案選型1.1 三層架構(gòu)劃分整個(gè)智能家居控制系統(tǒng)可以拆成三個(gè)部分設(shè)備采集與控制端、云端接入層、客戶端展示與控制端。設(shè)備端選的是STM32F103C8T6定位是現(xiàn)場(chǎng)控制器負(fù)責(zé)讀取DHT11溫濕度傳感器控制繼電器開關(guān)處理本地按鍵邏輯還要把數(shù)據(jù)組裝成MQTT報(bào)文發(fā)送到云端同時(shí)接收云端下發(fā)的控制指令。STM32本身沒(méi)有聯(lián)網(wǎng)能力所以加了一片ESP8266 WiFi模塊STM32通過(guò)串口和它通信ESP8266負(fù)責(zé)把TCP數(shù)據(jù)連接到華為云IoT的MQTT端口。這樣分工之后STM32只關(guān)心業(yè)務(wù)邏輯網(wǎng)絡(luò)鏈路交給模組調(diào)試時(shí)哪個(gè)環(huán)節(jié)出了問(wèn)題一眼就能定位到模塊。云端選用華為云IoT平臺(tái)設(shè)備接入側(cè)兼容標(biāo)準(zhǔn)MQTT協(xié)議支持產(chǎn)品模型、設(shè)備影子、命令下發(fā)和完整運(yùn)維界面。相比自建MQTT服務(wù)器它的優(yōu)勢(shì)是開箱即用注冊(cè)設(shè)備后平臺(tái)會(huì)自動(dòng)分配鑒權(quán)規(guī)則你只需要按照文檔計(jì)算連接參數(shù)。設(shè)備上報(bào)的數(shù)據(jù)進(jìn)入平臺(tái)后會(huì)更新設(shè)備影子應(yīng)用側(cè)可以通過(guò)API查詢也可以配置規(guī)則轉(zhuǎn)發(fā)到其他服務(wù)。對(duì)個(gè)人開發(fā)者來(lái)說(shuō)學(xué)習(xí)成本比從零搭建broker低很多而且免費(fèi)額度足以支撐這種教學(xué)項(xiàng)目。Qt端是用戶面對(duì)的部分。我用Qt寫了一個(gè)桌面程序運(yùn)行在Windows和Linux上能顯示溫濕度、開關(guān)狀態(tài)點(diǎn)擊按鈕下發(fā)控制命令。為什么選Qt因?yàn)樗木W(wǎng)絡(luò)模塊、JSON解析和跨平臺(tái)UI都非常成熟一套代碼編譯到多個(gè)平臺(tái)比維護(hù)兩套原生應(yīng)用省力得多。三層各司其職設(shè)備端管硬件云端管連接和狀態(tài)客戶端管人機(jī)交互整條鏈路非常清晰。1.2 關(guān)鍵選型的理由與替代方案有人會(huì)問(wèn)為什么不用ESP32這種自帶WiFi的單片機(jī)當(dāng)然可以。ESP32直接把MQTT庫(kù)跑在片上硬件成本更低也少一個(gè)串口模塊和獨(dú)立WiFi芯片。我保留STM32加ESP8266是為了讓模塊邊界更清晰。MCU、網(wǎng)絡(luò)模組、云平臺(tái)、客戶端各自獨(dú)立如果是初學(xué)哪個(gè)環(huán)節(jié)出問(wèn)題更容易定位。等你理解了這條鏈路想切到ESP32只是把MQTT部分從串口報(bào)文改成SDK調(diào)用工作量并不大。也有人會(huì)直接用公共智能家居平臺(tái)好處是App現(xiàn)成、設(shè)備接入快壞處是協(xié)議封閉、界面定制受限更學(xué)不到底層數(shù)據(jù)鏈路的原理。自己搭這套系統(tǒng)雖然初期要多寫代碼但主動(dòng)權(quán)在手里。以后想加攝像頭、語(yǔ)音控制、多房間管理都可以在自己架構(gòu)上擴(kuò)展。方案選型沒(méi)有絕對(duì)的對(duì)錯(cuò)關(guān)鍵是你手里的目標(biāo)如果目標(biāo)是快速出產(chǎn)品用私有云方案可能更合適如果目標(biāo)是學(xué)習(xí)物聯(lián)網(wǎng)全棧這套組合更值得投入。1.3 數(shù)據(jù)鏈路與消息主題設(shè)計(jì)核心數(shù)據(jù)鏈路是DHT11到STM32再經(jīng)ESP8266到華為云IoT最后到Qt客戶端反向還有一條命令下發(fā)鏈路。設(shè)備上報(bào)使用標(biāo)準(zhǔn)MQTT主題華為云IoT的主題格式是$oc/devices/{device_id}/sys/properties/report上報(bào)內(nèi)容為JSON包含服務(wù)ID和屬性集合。平臺(tái)收到后會(huì)更新影子應(yīng)用側(cè)API可以讀到最新狀態(tài)。這個(gè)topic的開頭是固定的{device_id}要替換成控制臺(tái)注冊(cè)的設(shè)備ID不要用別名或自定義字符串否則平臺(tái)路由不到?？刂浦噶钕掳l(fā)路徑是由Qt調(diào)用云端API云端把命令推給設(shè)備。設(shè)備需要訂閱下行命令主題格式為$oc/devices/{device_id}/sys/commands/request_id{request_id}其中request_id是平臺(tái)生成的命令標(biāo)識(shí)。設(shè)備處理完以后再向響應(yīng)主題發(fā)布結(jié)果。這套主題規(guī)則是華為云IoT內(nèi)部約定的字段必須對(duì)得上否則命令會(huì)丟。建議先到官方文檔把主題和request_id的邏輯理清楚后面聯(lián)調(diào)會(huì)節(jié)省很多時(shí)間。我在第一次聯(lián)調(diào)時(shí)把request_id寫成了固定值結(jié)果第一條命令能收到后續(xù)命令全部超時(shí)后來(lái)才發(fā)現(xiàn)它是動(dòng)態(tài)生成的。2. STM32硬件端設(shè)計(jì)與實(shí)現(xiàn)2.1 硬件清單與接線先列一下我用的硬件清單基本都是入門開發(fā)板常見的零件STM32F103C8T6最小系統(tǒng)板、ESP8266-01S WiFi模塊、DHT11溫濕度傳感器、一路繼電器模塊外加5V電源和杜邦線。如果你要控制多路設(shè)備一路繼電器不夠可以換成雙路或四路模塊接線思路是一樣的。DHT11的DATA引腳接PA0繼電器控制腳接PA1ESP8266的TX接STM32的PA10RX接PA9兩個(gè)模塊一定要把地線接在一起否則串口電平?jīng)]有參考點(diǎn)通信會(huì)出現(xiàn)亂碼。這里特別提醒ESP8266啟動(dòng)瞬間電流很大實(shí)測(cè)可以把STM32板上的電壓拉低造成單片機(jī)復(fù)位或WiFi連不上。不要圖省事讓兩個(gè)模塊共用一個(gè)穩(wěn)壓芯片我給ESP8266單獨(dú)供電并且在它的電源引腳并聯(lián)了一個(gè)100uF電解電容和0.1uF瓷片電容啟動(dòng)后穩(wěn)定很多。這個(gè)細(xì)節(jié)在教程里經(jīng)常被忽略實(shí)際做項(xiàng)目時(shí)卻是最常見的隱形坑。2.2 DHT11讀取與數(shù)據(jù)處理DHT11是單總線傳感器讀取時(shí)序比較講究。主機(jī)先把總線拉低至少18ms發(fā)送啟動(dòng)信號(hào)然后釋放總線等待從機(jī)響應(yīng)。從機(jī)回應(yīng)一個(gè)80us的低電平后會(huì)連續(xù)發(fā)出40bit數(shù)據(jù)濕度高低字節(jié)、溫度高低字節(jié)和校驗(yàn)字節(jié)各占8位。讀取時(shí)對(duì)微秒級(jí)延時(shí)要求高我直接用定時(shí)器做延時(shí)函數(shù)而不是for空循環(huán)否則編譯器優(yōu)化級(jí)別一變時(shí)序就亂。校驗(yàn)方式很簡(jiǎn)單前四個(gè)字節(jié)相加的低8位等于第五個(gè)字節(jié)不相等就丟棄本次數(shù)據(jù)。下面是一段最核心的校驗(yàn)邏輯。uint8_t dht_read(uint8_t *out) { uint8_t data[5]; // 啟動(dòng)信號(hào)和讀取40bit過(guò)程省略 if (((data[0] data[1] data[2] data[3]) 0xff) data[4]) { out[0] data[2]; // 整數(shù)溫度 out[1] data[0]; // 整數(shù)濕度 return 1; } return 0; }注意DHT11采樣間隔至少要1秒頻繁讀取會(huì)讀到舊值甚至通信失敗。我的控制邏輯里開了一個(gè)2秒的定時(shí)器去讀一次數(shù)據(jù)變化量雖然不大但對(duì)上報(bào)頻率和模塊壽命都比較友好。還要注意數(shù)據(jù)位順序濕度是高字節(jié)在前溫度也是高字節(jié)在前我第一次讀反了顯示溫濕度顛倒了。2.3 ESP8266聯(lián)網(wǎng)與透?jìng)髂Ｊ脚渲米孲TM32聯(lián)網(wǎng)我選擇讓ESP8266工作在透?jìng)髂Ｊ?。先用AT指令配置WiFi和TCP連接然后STM32把MQTT字節(jié)流直接發(fā)給串口ESP8266原樣發(fā)到華為云IoT的MQTT端口。這個(gè)方案意味著STM32端要自己實(shí)現(xiàn)MQTT協(xié)議但換來(lái)的是對(duì)協(xié)議有完全控制調(diào)試時(shí)可以打印每一個(gè)字節(jié)。如果你想讓ESP8266直接跑MQTT AT固件指令是簡(jiǎn)單但固件版本很雜出問(wèn)題時(shí)黑盒排查非常痛苦所以我更推薦透?jìng)髟糡CP。常用AT指令流程是這樣先用USB轉(zhuǎn)串口把ESP8266接電腦發(fā)送ATCWMODE1設(shè)置Station模式再ATCWJAP你的WiFi名,你的WiFi密碼連接路由器。WiFi連上后用ATCIPSTARTTCP,你的區(qū)域IoT接入地址,1883建立TCP連接接著ATCIPMODE1進(jìn)入透?jìng)髂Ｊ阶詈驛TCIPSEND啟動(dòng)發(fā)送。執(zhí)行完返回OK后后續(xù)寫入串口的內(nèi)容都會(huì)通過(guò)TCP發(fā)送出去。需要退出發(fā)送時(shí)發(fā)但不是每次都能成功所以在程序里要做超時(shí)和重試。使用官方AT固件的TCP透?jìng)鬟€有一個(gè)好處是網(wǎng)絡(luò)連接狀態(tài)可預(yù)期。單片機(jī)上電后我可以等到AT指令返回CONNECT再加栽MQTT連接邏輯。如果WiFi密碼錯(cuò)誤AT指令會(huì)直接返回ERROR這時(shí)候不需要去查代碼問(wèn)題在網(wǎng)絡(luò)配置。很多人用ESP8266模塊會(huì)遇到AT無(wú)響應(yīng)查看一下串口波特率是不是115200以及模塊供電是否穩(wěn)定這兩個(gè)因素占了八成問(wèn)題。2.4 在STM32上實(shí)現(xiàn)MQTT報(bào)文生成MQTT報(bào)文并不復(fù)雜但如果你從來(lái)沒(méi)在裸機(jī)上拼過(guò)第一次遇到會(huì)有點(diǎn)懵。固定頭第一個(gè)字節(jié)表示報(bào)文類型和標(biāo)志位第二個(gè)字節(jié)是剩余長(zhǎng)度。CONNECT報(bào)文需要在有效載荷里按順序填協(xié)議名、協(xié)議版本、連接標(biāo)記、心跳時(shí)間、clientId、username、password。華為云IoT要求這三個(gè)鑒權(quán)字段必須和平臺(tái)計(jì)算值一致一個(gè)字符不對(duì)都會(huì)連接失敗。STM32端代碼里我封裝了一個(gè)拼接函數(shù)方便后續(xù)復(fù)用。uint16_t mqtt_build_connect(uint8_t *buf, const char *cid, const char *user, const char *pass) { uint16_t pos 0; buf[pos] 0x10; uint8_t len_pos pos; pos; buf[pos] 0; buf[pos] 4; buf[pos] M; buf[pos] Q; buf[pos] T; buf[pos] T; buf[pos] 0x04; buf[pos] 0xC2; buf[pos] 0; buf[pos] 60; pos push_str(buf pos, cid); pos push_str(buf pos, user); pos push_str(buf pos, pass); uint16_t len pos - len_pos - 1; buf[len_pos] len; return pos; }這里push_str負(fù)責(zé)寫入U(xiǎn)TF-8字符串長(zhǎng)度和內(nèi)容所有多字節(jié)數(shù)字都按網(wǎng)絡(luò)序大端排列。CONNECT發(fā)送之后必須等待CONNACK響應(yīng)如果沒(méi)收到優(yōu)先檢查clientId、username、password是否一致。上報(bào)數(shù)據(jù)用PUBLISH報(bào)文固定頭是0x30后面接主題長(zhǎng)度、主題內(nèi)容再跟上JSON body。QoS建議用0環(huán)境數(shù)據(jù)重復(fù)上報(bào)丟一幀下幀會(huì)補(bǔ)上。最容易錯(cuò)的是剩余長(zhǎng)度字段它不僅要包含主題還要包含整個(gè)body我調(diào)試時(shí)打印報(bào)文發(fā)現(xiàn)比標(biāo)準(zhǔn)格式多了一個(gè)字節(jié)最后查出來(lái)是字符串結(jié)尾符被當(dāng)成數(shù)據(jù)發(fā)出去加個(gè)長(zhǎng)度接口就解決了。2.5 云端命令接收與本地控制執(zhí)行設(shè)備接收云端命令必須先在連接后發(fā)送SUBSCRIBE報(bào)文。主題用通配符#訂閱命令下行目錄也就是$oc/devices/{device_id}/sys/commands/#這樣平臺(tái)推下來(lái)的帶不同request_id的命令都能收到。收到PUBLISH后先提取主題里的request_id再?gòu)腏SON payload里解析paras.switch把對(duì)應(yīng)GPIO置高或置低?？刂七壿嬏幚硗暌院蟊仨毾蝽憫?yīng)主題回一條消息否則平臺(tái)會(huì)認(rèn)為命令執(zhí)行超時(shí)。我在代碼里把“收到命令”和“執(zhí)行完成”分成兩個(gè)日志點(diǎn)方便判斷是網(wǎng)絡(luò)沒(méi)到還是執(zhí)行出錯(cuò)。處理命令時(shí)有一個(gè)小坑繼電器模塊觸發(fā)電平可能和你想的相反。我用的模塊是低電平觸發(fā)也就是GPIO輸出0時(shí)繼電器吸合輸出1時(shí)斷開。如果你在測(cè)試時(shí)發(fā)現(xiàn)云端發(fā)‘開’結(jié)果燈關(guān)了檢查一下模塊是高電平還是低電平觸發(fā)把控制邏輯反過(guò)來(lái)就行。另外本地按鍵開關(guān)也要和云端狀態(tài)同步我每次按本地按鍵后會(huì)立即上報(bào)一個(gè)新的switch屬性這樣Qt端拉影子時(shí)看到的始終是實(shí)際狀態(tài)不會(huì)出現(xiàn)“界面顯示關(guān)燈卻亮著”的尷尬。3. 華為云IoT平臺(tái)配置與接入計(jì)算3.1 產(chǎn)品模型與設(shè)備注冊(cè)登錄華為云IoT設(shè)備接入控制臺(tái)后先創(chuàng)建一個(gè)產(chǎn)品。產(chǎn)品模型相當(dāng)于設(shè)備的說(shuō)明書告訴平臺(tái)這個(gè)設(shè)備有哪些屬性、支持哪些命令。我創(chuàng)建的服務(wù)ID叫Env屬性列表如下。屬性名類型說(shuō)明temperatureint當(dāng)前溫度humidityint當(dāng)前濕度switchenum0-關(guān)閉1-開啟溫度濕度用整數(shù)就夠了DHT11本身沒(méi)有小數(shù)精度。枚舉屬性的switch只允許填0或1平臺(tái)會(huì)自動(dòng)校驗(yàn)。屬性名建議統(tǒng)一小寫駝峰后面STM32組裝JSON和Qt解析時(shí)保持一致我見過(guò)有人把temperature寫成Temperature結(jié)果云端一直收不到。產(chǎn)品創(chuàng)建完成后注冊(cè)設(shè)備并記錄設(shè)備ID和密鑰這兩個(gè)值后續(xù)計(jì)算連接參數(shù)都會(huì)用到。設(shè)備ID是一長(zhǎng)串字符串密鑰是設(shè)備鑒權(quán)憑證控制臺(tái)可以一鍵復(fù)制不要手輸。3.2 MQTT連接參數(shù)計(jì)算clientId、username、password華為云IoT的MQTT連接參數(shù)有固定規(guī)則和普通MQTT服務(wù)器填法不同。clientId的格式是設(shè)備ID加下劃線0再加時(shí)間戳username就是設(shè)備IDpassword需要用設(shè)備密鑰對(duì)時(shí)間戳做HMAC-SHA256再轉(zhuǎn)十六進(jìn)制。很多人第一次會(huì)漏了下劃線里的0_0導(dǎo)致平臺(tái)無(wú)法識(shí)別設(shè)備。我在本機(jī)寫了一個(gè)Python腳本一次算出三個(gè)值非常順手。import hmac, hashlib, time device_id 你的設(shè)備ID secret 你的設(shè)備密鑰 timestamp str(int(time.time() * 1000)) client_id {}_0_0_{}.format(device_id, timestamp) password hmac.new(secret.encode(), timestamp.encode(), hashlib.sha256).hexdigest() print(clientId:, client_id) print(username:, device_id) print(password:, password)有個(gè)細(xì)節(jié)需要提醒clientId里的時(shí)間戳和計(jì)算password時(shí)的timestamp必須完全相同否則鑒權(quán)失敗。STM32設(shè)備本身沒(méi)有實(shí)時(shí)鐘系統(tǒng)時(shí)間不準(zhǔn)我一開始直接在板子上取系統(tǒng)啟動(dòng)后的毫秒計(jì)數(shù)算出來(lái)的密碼和clientId不匹配連接一直失敗。后來(lái)我把時(shí)間戳放在PC上算好固定值直接燒進(jìn)去測(cè)通。但固定時(shí)間戳在長(zhǎng)時(shí)間運(yùn)行時(shí)斷線重連會(huì)不太安全最好在ESP8266連上WiFi后用SNTP獲取一次UTC時(shí)間再動(dòng)態(tài)生成連接參數(shù)。如果不想引入NTP最簡(jiǎn)單的辦法是每次重新上電都重新計(jì)算一般教學(xué)項(xiàng)目夠用了。3.3 設(shè)備上報(bào)屬性與云端驗(yàn)證設(shè)備連接成功后上報(bào)屬性的topic和payload必須嚴(yán)格按平臺(tái)文檔來(lái)。上報(bào)topic是$oc/devices/{device_id}/sys/properties/reportpayload格式是services數(shù)組內(nèi)部填服務(wù)ID和屬性集合。注意服務(wù)ID必須和產(chǎn)品模型里創(chuàng)建的一致否則平臺(tái)會(huì)報(bào)“服務(wù)不存在”。我在代碼里用宏定義ENV_SERVICE_ID確保所有地方引用同一個(gè)字符串。{ services: [ { service_id: Env, properties: { temperature: 26, humidity: 55 } } ] }上報(bào)完成后到控制臺(tái)設(shè)備詳情頁(yè)查看如果能看到溫濕度值說(shuō)明鏈路通了。有一次我的數(shù)據(jù)報(bào)了但控制臺(tái)不顯示排查半天發(fā)現(xiàn)是topic里的device_id多打了一個(gè)字母。如果遇到類似情況最快的方法是固定字符串拷貝不要手動(dòng)拼。還有一個(gè)辦法先在控制臺(tái)的產(chǎn)品模型里復(fù)制服務(wù)ID再在代碼里定義成宏這樣至少能排除拼寫錯(cuò)誤。3.4 命令下行Topic與設(shè)備響應(yīng)平臺(tái)命令下發(fā)的流程是應(yīng)用端調(diào)用API觸發(fā)云端生成唯一request_id并把命令推到設(shè)備訂閱的主題。設(shè)備側(cè)訂閱$oc/devices/{device_id}/sys/commands/#就能收到所有命令不用擔(dān)心request_id變化。收到payload之后設(shè)備要處理并回響應(yīng)。payload大致的結(jié)構(gòu)如下。{ command_name: SetSwitch, service_id: Env, paras: { switch: 1 } }響應(yīng)主題格式是$oc/devices/{device_id}/sys/commands/response/request_id{request_id}響應(yīng)內(nèi)容包含result_code0表示成功。平臺(tái)上可以設(shè)置命令超時(shí)時(shí)間如果設(shè)備沒(méi)有及時(shí)響應(yīng)平臺(tái)會(huì)記錄超時(shí)。測(cè)試階段我直接用控制臺(tái)提供的“設(shè)備調(diào)試”功能下發(fā)命令比先寫Qt端再測(cè)要快得多。這一步通了后面Qt調(diào)用API其實(shí)就是從另一個(gè)入口觸發(fā)同一個(gè)命令。4. Qt跨平臺(tái)客戶端實(shí)現(xiàn)4.1 為什么Qt桌面端不走M(jìn)QTT而走HTTP API最開始我也想讓Qt直接以MQTT方式連平臺(tái)但翻了一遍華為云IoT的接口設(shè)計(jì)后決定改用官方應(yīng)用側(cè)API。設(shè)備側(cè)資源受限推薦MQTT應(yīng)用側(cè)需要頻繁查詢狀態(tài)、管理設(shè)備最佳實(shí)踐是走HTTPS請(qǐng)求調(diào)用REST API。Qt的QNetworkAccessManager對(duì)HTTPS支持很好跨平臺(tái)傳JSON、解析響應(yīng)都沒(méi)問(wèn)題。這樣客戶端不需要維護(hù)長(zhǎng)連接每次操作發(fā)一個(gè)HTTP請(qǐng)求拿到結(jié)果刷新界面既穩(wěn)又省心。如果你確實(shí)想讓Qt走M(jìn)QTT一般來(lái)說(shuō)需要云平臺(tái)規(guī)則引擎把設(shè)備數(shù)據(jù)轉(zhuǎn)發(fā)到另一個(gè)主題這對(duì)初學(xué)者來(lái)說(shuō)反而是額外負(fù)擔(dān)。4.2 獲取Access Token的流程調(diào)用華為云IoT應(yīng)用側(cè)API第一步是獲取Token。它用的是IAM認(rèn)證需要先拿賬號(hào)或用戶憑證向IAM服務(wù)請(qǐng)求一個(gè)X-Auth-Token。流程比較繁瑣但邏輯很固定構(gòu)造POST請(qǐng)求帶上賬號(hào)名密碼或用戶憑證從響應(yīng)頭里取出token。我建議先在電腦上用API調(diào)試工具把這個(gè)接口調(diào)通再把同樣的HTTP請(qǐng)求搬到Qt里。令牌一般有效期一小時(shí)過(guò)期后重新獲取。在桌面端我把token放在一個(gè)全局對(duì)象里每次網(wǎng)絡(luò)請(qǐng)求前檢查是否快過(guò)期超過(guò)50分鐘就主動(dòng)刷新這樣長(zhǎng)時(shí)間掛著也不會(huì)突然401。4.3 核心代碼查詢?cè)O(shè)備影子查詢?cè)O(shè)備影子接口用來(lái)獲取設(shè)備最新狀態(tài)。請(qǐng)求路徑類似GET https://{endpoint}/v5/iot/{project_id}/devices/{device_id}/shadow端點(diǎn)和projectId從控制臺(tái)獲取。Header里帶上X-Auth-Token。Qt里用QNetworkAccessManager發(fā)起異步GET請(qǐng)求代碼如下。void MainWindow::fetchShadow() { QNetworkRequest req; req.setUrl(QString(https://%1/v5/iot/%2/devices/%3/shadow) .arg(m_endpoint).arg(m_projectId).arg(m_deviceId)); req.setRawHeader(X-Auth-Token, m_token.toUtf8()); QNetworkReply *reply m_manager-get(req); connect(reply, QNetworkReply::finished, this, [this, reply]() { if (reply-error() QNetworkReply::NoError) { QJsonDocument doc QJsonDocument::fromJson(reply-readAll()); // 解析影子數(shù)據(jù)更新界面 } reply-deleteLater(); }); }影子返回的JSON層級(jí)比較深里面包含shadow數(shù)組、device_shadow和reported字段。我第一次寫解析很樂(lè)觀直接按properties取發(fā)現(xiàn)取不到。建議先用接口調(diào)試工具打印一次完整響應(yīng)再看結(jié)構(gòu)寫QJsonValue避免反復(fù)試錯(cuò)。另外屬性上報(bào)后設(shè)備影子更新有輕微延遲Qt端下發(fā)命令以后不要馬上拉一次可以考慮等1到2秒再刷新否則看到的是舊狀態(tài)。4.4 核心代碼下發(fā)控制命令下發(fā)命令的接口是一個(gè)POST請(qǐng)求body里帶上服務(wù)ID和命令參數(shù)。Qt按鈕事件里調(diào)用sendCommand(1)或sendCommand(0)核心代碼如下。void MainWindow::sendCommand(int switchValue) { QNetworkRequest req; req.setUrl(QString(https://%1/v5/iot/%2/devices/%3/commands) .arg(m_endpoint).arg(m_projectId).arg(m_deviceId)); req.setHeader(QNetworkRequest::ContentTypeHeader, application/json); req.setRawHeader(X-Auth-Token, m_token.toUtf8()); QJsonObject paras; paras.insert(switch, switchValue); QJsonObject body; body.insert(service_id, Env); body.insert(command_name, SetSwitch); body.insert(paras, paras); QNetworkReply *reply m_manager-post(req, QJsonDocument(body).toJson()); // 等響應(yīng)后更新界面 }這里的命令名必須和產(chǎn)品模型定義的命令名完全一致我定義的是SetSwitch命令參數(shù)是switch。如果平臺(tái)返回提示命令格式錯(cuò)誤打開控制臺(tái)產(chǎn)品模型的命令定義頁(yè)逐字檢查。Qt的post會(huì)自動(dòng)處理content-length不用手動(dòng)設(shè)置。收到成功響應(yīng)后建議再調(diào)一次查詢影子接口刷新界面形成一個(gè)完整的“下發(fā)-執(zhí)行-刷新”閉環(huán)。4.5 界面布局與跨平臺(tái)編譯界面我做得比較克制一個(gè)主窗口分三個(gè)區(qū)域頂部連接狀態(tài)、中間溫濕度卡片、底部開關(guān)按鈕。用QSS做了圓角卡片和深色背景看起來(lái)有點(diǎn)智能家居App的意思。Qt跨平臺(tái)的關(guān)鍵是不要寫平臺(tái)相關(guān)的代碼網(wǎng)絡(luò)模塊和JSON解析都是跨平臺(tái)的Window和Linux各自裝好Qt套件后源碼之間基本不需要改動(dòng)。我是在Windows上用MinGW編譯在Ubuntu上再用g編譯一遍兩邊運(yùn)行效果一致。唯一要留神的是HTTPS證書如果Qt報(bào)證書錯(cuò)誤Windows下把OpenSSL動(dòng)態(tài)庫(kù)放到程序目錄Linux下安裝ca-certificates基本就解決了。5. 全鏈路聯(lián)調(diào)與問(wèn)題排查5.1 聯(lián)調(diào)順序聯(lián)調(diào)順序一定不要跳。我的習(xí)慣是先把DHT11讀取和繼電器動(dòng)作在本地調(diào)通再用USB轉(zhuǎn)串口單獨(dú)調(diào)試ESP8266的AT指令然后讓STM32連接云平臺(tái)上報(bào)一條屬性到控制臺(tái)確認(rèn)確認(rèn)上報(bào)沒(méi)問(wèn)題再用平臺(tái)調(diào)試功能下發(fā)命令觀察設(shè)備動(dòng)作后面調(diào)Qt先用API調(diào)試工具把接口調(diào)通確認(rèn)token和接口可用再集成到界面。最后端到端驗(yàn)證一遍Qt點(diǎn)按鈕STM32執(zhí)行界面刷新再給傳感器加熱看Qt溫度是否變化。每一步都有明確的通過(guò)標(biāo)準(zhǔn)才能把問(wèn)題擋在某一層內(nèi)。5.2 常見問(wèn)題速查表現(xiàn)象可能原因解決辦法MQTT建立連接失敗返回錯(cuò)誤碼5clientId或password與server不匹配用腳本重新生成連接參數(shù)核對(duì)時(shí)間戳一致云平臺(tái)看到設(shè)備在線但沒(méi)有屬性數(shù)據(jù)上報(bào)topic錯(cuò)誤或JSON服務(wù)ID不匹配拷貝官方topic格式檢查services數(shù)組結(jié)構(gòu)STM32串口打印正常但ESP8266沒(méi)數(shù)據(jù)ESP8266供電不穩(wěn)或透?jìng)髂Ｊ轿撮_啟獨(dú)立供電檢查ATCIPSEND返回結(jié)果DHT11讀數(shù)一直是0或固定值接線松動(dòng)或采樣間隔太短重新插線采樣間隔至少1秒Qt請(qǐng)求返回401token過(guò)期或鑒權(quán)頭字段不對(duì)刷新token確認(rèn)Header寫的是X-Auth-TokenQt請(qǐng)求能通但界面不刷新JSON解析層級(jí)錯(cuò)誤用接口工具打印原始響應(yīng)對(duì)照解析云端命令已下發(fā)STM32沒(méi)反應(yīng)訂閱topic用了具體request_id改成訂閱$oc/devices/{device_id}/sys/commands/#繼電器動(dòng)作但模塊發(fā)熱嚴(yán)重驅(qū)動(dòng)電流不足或用了低電平觸發(fā)加三極管或光耦按模塊說(shuō)明調(diào)整控制電平這個(gè)速查表是根據(jù)我自己調(diào)試過(guò)程整理的。遇到問(wèn)題時(shí)按表格逐項(xiàng)排除大多數(shù)問(wèn)題不是代碼邏輯而是配置不一致。比如連接失敗多半是clientId的密碼算錯(cuò)命令無(wú)響應(yīng)多半是訂閱topic不對(duì)。把這些常見坑提前避開項(xiàng)目成功率會(huì)高很多。我還會(huì)把速查表放在項(xiàng)目目錄的README里因?yàn)檫^(guò)幾天就會(huì)忘掉再遇到問(wèn)題時(shí)翻一下比自己重新猜快得多。5.3 幾個(gè)值得記錄的避坑細(xì)節(jié)第一個(gè)避坑點(diǎn)是MQTT報(bào)文的剩余長(zhǎng)度字段。PUBLISH報(bào)文的剩余長(zhǎng)度既要包含主題長(zhǎng)度也要包含body長(zhǎng)度我剛開始圖省事少加了一個(gè)字節(jié)導(dǎo)致數(shù)據(jù)一直發(fā)不出去。解決辦法是統(tǒng)一用一個(gè)封裝函數(shù)傳入topic和payload由函數(shù)內(nèi)部計(jì)算總長(zhǎng)度不要在調(diào)用處手動(dòng)拼字符串。第二個(gè)避坑點(diǎn)是華為云IoT的HMAC計(jì)算。網(wǎng)上很多教程會(huì)寫B(tài)ase64編碼結(jié)果但設(shè)備接入文檔要求的是十六進(jìn)制小寫字符串。兩種算法生成的結(jié)果完全不同。只看文字容易忽略建議直接下載官方設(shè)備SDK里的示例照抄里面的簽名方法不要憑印象寫。第三個(gè)避坑點(diǎn)是Qt網(wǎng)絡(luò)請(qǐng)求別用同步阻塞。我最初圖快在按鈕里用waitForFinished()結(jié)果界面直接卡死Windows上尤其明顯。改成信號(hào)槽異步處理后程序流暢很多?，F(xiàn)在我的習(xí)慣是請(qǐng)求發(fā)出后先把按鈕置灰響應(yīng)完成后恢復(fù)這樣用戶也不會(huì)因?yàn)橹貜?fù)點(diǎn)擊造成重復(fù)命令。最后再分享一點(diǎn)個(gè)人體會(huì)。這套系統(tǒng)真正值錢的不是某一段源碼而是把設(shè)備、云端和客戶端三層邊界搞清楚。我前期把大量時(shí)間浪費(fèi)在到處找現(xiàn)成代碼上后來(lái)靜下心按層拆解先把每一段單獨(dú)調(diào)通再串起來(lái)反而很快。這條鏈路聽起來(lái)很長(zhǎng)但每走一步都會(huì)把MQTT、設(shè)備影子、跨平臺(tái)應(yīng)用編程這些概念從抽象變成實(shí)際體會(huì)。建議你從最簡(jiǎn)單的“STM32上報(bào)溫度”開始先別管界面多好看等鏈路通了再慢慢完善。做嵌入式項(xiàng)目信心是依賴一步步驗(yàn)證堆起來(lái)的順利完成一次遠(yuǎn)程開關(guān)燈后面所有擴(kuò)展都會(huì)順手很多。