程控制系統(tǒng)實(shí)戰(zhàn))
做智能家居項(xiàng)目有一段時(shí)間了從最開始用手機(jī)藍(lán)牙控制一盞燈到后面把設(shè)備真正接入云平臺(tái)中間踩了不少坑。這次分享的是一個(gè)我最近完整跑通的實(shí)戰(zhàn)項(xiàng)目基于STM32做設(shè)備端主控通過華為云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)用三段鏈路串起來適合正在學(xué)習(xí)STM32、準(zhǔn)備接觸云平臺(tái)或者是想從單片機(jī)跳到物聯(lián)網(wǎng)方向的朋友。文章里不會(huì)只講概念而是把整條鏈路的架構(gòu)、關(guān)鍵代碼、參數(shù)計(jì)算和常見問題都攤開來講照著步驟走基本能復(fù)現(xiàn)一個(gè)可以用的原型。1. 系統(tǒng)架構(gòu)與方案選型1.1 三層架構(gòu)劃分整個(gè)智能家居控制系統(tǒng)可以拆成三個(gè)部分設(shè)備采集與控制端、云端接入層、客戶端展示與控制端。設(shè)備端選的是STM32F103C8T6定位是現(xiàn)場控制器負(fù)責(zé)讀取DHT11溫濕度傳感器控制繼電器開關(guān)處理本地按鍵邏輯還要把數(shù)據(jù)組裝成MQTT報(bào)文發(fā)送到云端同時(shí)接收云端下發(fā)的控制指令。STM32本身沒有聯(lián)網(wǎng)能力所以加了一片ESP8266 WiFi模塊STM32通過串口和它通信ESP8266負(fù)責(zé)把TCP數(shù)據(jù)連接到華為云IoT的MQTT端口。這樣分工之后STM32只關(guān)心業(yè)務(wù)邏輯網(wǎng)絡(luò)鏈路交給模組調(diào)試時(shí)哪個(gè)環(huán)節(jié)出了問題一眼就能定位到模塊。云端選用華為云IoT平臺(tái)設(shè)備接入側(cè)兼容標(biāo)準(zhǔn)MQTT協(xié)議支持產(chǎn)品模型、設(shè)備影子、命令下發(fā)和完整運(yùn)維界面。相比自建MQTT服務(wù)器它的優(yōu)勢是開箱即用注冊設(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è)可以通過API查詢也可以配置規(guī)則轉(zhuǎn)發(fā)到其他服務(wù)。對個(gè)人開發(fā)者來說學(xué)習(xí)成本比從零搭建broker低很多而且免費(fèi)額度足以支撐這種教學(xué)項(xiàng)目。Qt端是用戶面對的部分。我用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ì)問為什么不用ESP32這種自帶WiFi的單片機(jī)當(dāng)然可以。ESP32直接把MQTT庫跑在片上硬件成本更低也少一個(gè)串口模塊和獨(dú)立WiFi芯片。我保留STM32加ESP8266是為了讓模塊邊界更清晰。MCU、網(wǎng)絡(luò)模組、云平臺(tái)、客戶端各自獨(dú)立如果是初學(xué)哪個(gè)環(huán)節(jié)出問題更容易定位。等你理解了這條鏈路想切到ESP32只是把MQTT部分從串口報(bào)文改成SDK調(diào)用工作量并不大。也有人會(huì)直接用公共智能家居平臺(tái)好處是App現(xiàn)成、設(shè)備接入快壞處是協(xié)議封閉、界面定制受限更學(xué)不到底層數(shù)據(jù)鏈路的原理。自己搭這套系統(tǒng)雖然初期要多寫代碼但主動(dòng)權(quán)在手里。以后想加攝像頭、語音控制、多房間管理都可以在自己架構(gòu)上擴(kuò)展。方案選型沒有絕對的對錯(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)注冊的設(shè)備ID不要用別名或自定義字符串否則平臺(tái)路由不到。控制指令下發(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)部約定的字段必須對得上否則命令會(huì)丟。建議先到官方文檔把主題和request_id的邏輯理清楚后面聯(lián)調(diào)會(huì)節(jié)省很多時(shí)間。我在第一次聯(lián)調(diào)時(shí)把request_id寫成了固定值結(jié)果第一條命令能收到后續(xù)命令全部超時(shí)后來才發(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í)測可以把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í)對微秒級(jí)延時(shí)要求高我直接用定時(shí)器做延時(shí)函數(shù)而不是for空循環(huán)否則編譯器優(yōu)化級(jí)別一變時(shí)序就亂。校驗(yà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過程省略 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ù)變化量雖然不大但對上報(bào)頻率和模塊壽命都比較友好。還要注意數(shù)據(jù)位順序濕度是高字節(jié)在前溫度也是高字節(jié)在前我第一次讀反了顯示溫濕度顛倒了。2.3 ESP8266聯(lián)網(wǎng)與透傳模式配置讓STM32聯(lián)網(wǎng)我選擇讓ESP8266工作在透傳模式。先用AT指令配置WiFi和TCP連接然后STM32把MQTT字節(jié)流直接發(fā)給串口ESP8266原樣發(fā)到華為云IoT的MQTT端口。這個(gè)方案意味著STM32端要自己實(shí)現(xiàn)MQTT協(xié)議但換來的是對協(xié)議有完全控制調(diào)試時(shí)可以打印每一個(gè)字節(jié)。如果你想讓ESP8266直接跑MQTT AT固件指令是簡單但固件版本很雜出問題時(shí)黑盒排查非常痛苦所以我更推薦透傳原始TCP。常用AT指令流程是這樣先用USB轉(zhuǎn)串口把ESP8266接電腦發(fā)送ATCWMODE1設(shè)置Station模式再ATCWJAP你的WiFi名,你的WiFi密碼連接路由器。WiFi連上后用ATCIPSTARTTCP,你的區(qū)域IoT接入地址,1883建立TCP連接接著ATCIPMODE1進(jìn)入透傳模式最后ATCIPSEND啟動(dòng)發(fā)送。執(zhí)行完返回OK后后續(xù)寫入串口的內(nèi)容都會(huì)通過TCP發(fā)送出去。需要退出發(fā)送時(shí)發(fā)但不是每次都能成功所以在程序里要做超時(shí)和重試。使用官方AT固件的TCP透傳還有一個(gè)好處是網(wǎng)絡(luò)連接狀態(tài)可預(yù)期。單片機(jī)上電后我可以等到AT指令返回CONNECT再加栽MQTT連接邏輯。如果WiFi密碼錯(cuò)誤AT指令會(huì)直接返回ERROR這時(shí)候不需要去查代碼問題在網(wǎng)絡(luò)配置。很多人用ESP8266模塊會(huì)遇到AT無響應(yīng)查看一下串口波特率是不是115200以及模塊供電是否穩(wěn)定這兩個(gè)因素占了八成問題。2.4 在STM32上實(shí)現(xiàn)MQTT報(bào)文生成MQTT報(bào)文并不復(fù)雜但如果你從來沒在裸機(jī)上拼過第一次遇到會(huì)有點(diǎn)懵。固定頭第一個(gè)字節(jié)表示報(bào)文類型和標(biāo)志位第二個(gè)字節(jié)是剩余長度。CONNECT報(bào)文需要在有效載荷里按順序填協(xié)議名、協(xié)議版本、連接標(biāo)記、心跳時(shí)間、clientId、username、password。華為云IoT要求這三個(gè)鑒權(quán)字段必須和平臺(tái)計(jì)算值一致一個(gè)字符不對都會(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字符串長度和內(nèi)容所有多字節(jié)數(shù)字都按網(wǎng)絡(luò)序大端排列。CONNECT發(fā)送之后必須等待CONNACK響應(yīng)如果沒收到優(yōu)先檢查clientId、username、password是否一致。上報(bào)數(shù)據(jù)用PUBLISH報(bào)文固定頭是0x30后面接主題長度、主題內(nèi)容再跟上JSON body。QoS建議用0環(huán)境數(shù)據(jù)重復(fù)上報(bào)丟一幀下幀會(huì)補(bǔ)上。最容易錯(cuò)的是剩余長度字段它不僅要包含主題還要包含整個(gè)body我調(diào)試時(shí)打印報(bào)文發(fā)現(xiàn)比標(biāo)準(zhǔn)格式多了一個(gè)字節(jié)最后查出來是字符串結(jié)尾符被當(dāng)成數(shù)據(jù)發(fā)出去加個(gè)長度接口就解決了。2.5 云端命令接收與本地控制執(zhí)行設(shè)備接收云端命令必須先在連接后發(fā)送SUBSCRIBE報(bào)文。主題用通配符#訂閱命令下行目錄也就是$oc/devices/{device_id}/sys/commands/#這樣平臺(tái)推下來的帶不同request_id的命令都能收到。收到PUBLISH后先提取主題里的request_id再從JSON payload里解析paras.switch把對應(yīng)GPIO置高或置低。控制邏輯處理完以后必須向響應(yīng)主題回一條消息否則平臺(tái)會(huì)認(rèn)為命令執(zhí)行超時(shí)。我在代碼里把“收到命令”和“執(zhí)行完成”分成兩個(gè)日志點(diǎn)方便判斷是網(wǎng)絡(luò)沒到還是執(zhí)行出錯(cuò)。處理命令時(shí)有一個(gè)小坑繼電器模塊觸發(fā)電平可能和你想的相反。我用的模塊是低電平觸發(fā)也就是GPIO輸出0時(shí)繼電器吸合輸出1時(shí)斷開。如果你在測試時(shí)發(fā)現(xiàn)云端發(fā)‘開’結(jié)果燈關(guān)了檢查一下模塊是高電平還是低電平觸發(fā)把控制邏輯反過來就行。另外本地按鍵開關(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è)備注冊登錄華為云IoT設(shè)備接入控制臺(tái)后先創(chuàng)建一個(gè)產(chǎn)品。產(chǎn)品模型相當(dāng)于設(shè)備的說明書告訴平臺(tái)這個(gè)設(shè)備有哪些屬性、支持哪些命令。我創(chuàng)建的服務(wù)ID叫Env屬性列表如下。屬性名類型說明temperatureint當(dāng)前溫度humidityint當(dāng)前濕度switchenum0-關(guān)閉1-開啟溫度濕度用整數(shù)就夠了DHT11本身沒有小數(shù)精度。枚舉屬性的switch只允許填0或1平臺(tái)會(huì)自動(dòng)校驗(yàn)。屬性名建議統(tǒng)一小寫駝峰后面STM32組裝JSON和Qt解析時(shí)保持一致我見過有人把temperature寫成Temperature結(jié)果云端一直收不到。產(chǎn)品創(chuàng)建完成后注冊設(shè)備并記錄設(shè)備ID和密鑰這兩個(gè)值后續(xù)計(jì)算連接參數(shù)都會(huì)用到。設(shè)備ID是一長串字符串密鑰是設(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è)備密鑰對時(shí)間戳做HMAC-SHA256再轉(zhuǎn)十六進(jìn)制。很多人第一次會(huì)漏了下劃線里的0_0導(dǎo)致平臺(tái)無法識(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è)備本身沒有實(shí)時(shí)鐘系統(tǒng)時(shí)間不準(zhǔn)我一開始直接在板子上取系統(tǒng)啟動(dòng)后的毫秒計(jì)數(shù)算出來的密碼和clientId不匹配連接一直失敗。后來我把時(shí)間戳放在PC上算好固定值直接燒進(jìn)去測通。但固定時(shí)間戳在長時(shí)間運(yùn)行時(shí)斷線重連會(huì)不太安全最好在ESP8266連上WiFi后用SNTP獲取一次UTC時(shí)間再動(dòng)態(tài)生成連接參數(shù)。如果不想引入NTP最簡單的辦法是每次重新上電都重新計(jì)算一般教學(xué)項(xiàng)目夠用了。3.3 設(shè)備上報(bào)屬性與云端驗(yàn)證設(shè)備連接成功后上報(bào)屬性的topic和payload必須嚴(yán)格按平臺(tá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è)備詳情頁查看如果能看到溫濕度值說明鏈路通了。有一次我的數(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è)備沒有及時(shí)響應(yīng)平臺(tái)會(huì)記錄超時(shí)。測試階段我直接用控制臺(tái)提供的“設(shè)備調(diào)試”功能下發(fā)命令比先寫Qt端再測要快得多。這一步通了后面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請求調(diào)用REST API。Qt的QNetworkAccessManager對HTTPS支持很好跨平臺(tái)傳JSON、解析響應(yīng)都沒問題。這樣客戶端不需要維護(hù)長連接每次操作發(fā)一個(gè)HTTP請求拿到結(jié)果刷新界面既穩(wěn)又省心。如果你確實(shí)想讓Qt走M(jìn)QTT一般來說需要云平臺(tái)規(guī)則引擎把設(shè)備數(shù)據(jù)轉(zhuǎn)發(fā)到另一個(gè)主題這對初學(xué)者來說反而是額外負(fù)擔(dān)。4.2 獲取Access Token的流程調(diào)用華為云IoT應(yīng)用側(cè)API第一步是獲取Token。它用的是IAM認(rèn)證需要先拿賬號(hào)或用戶憑證向IAM服務(wù)請求一個(gè)X-Auth-Token。流程比較繁瑣但邏輯很固定構(gòu)造POST請求帶上賬號(hào)名密碼或用戶憑證從響應(yīng)頭里取出token。我建議先在電腦上用API調(diào)試工具把這個(gè)接口調(diào)通再把同樣的HTTP請求搬到Qt里。令牌一般有效期一小時(shí)過期后重新獲取。在桌面端我把token放在一個(gè)全局對象里每次網(wǎng)絡(luò)請求前檢查是否快過期超過50分鐘就主動(dòng)刷新這樣長時(shí)間掛著也不會(huì)突然401。4.3 核心代碼查詢設(shè)備影子查詢設(shè)備影子接口用來獲取設(shè)備最新狀態(tài)。請求路徑類似GET https://{endpoint}/v5/iot/{project_id}/devices/{device_id}/shadow端點(diǎn)和projectId從控制臺(tái)獲取。Header里帶上X-Auth-Token。Qt里用QNetworkAccessManager發(fā)起異步GET請求代碼如下。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字段。我第一次寫解析很樂觀直接按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請求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)品模型的命令定義頁逐字檢查。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做了圓角卡片和深色背景看起來有點(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)庫放到程序目錄Linux下安裝ca-certificates基本就解決了。5. 全鏈路聯(lián)調(diào)與問題排查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)沒問題再用平臺(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溫度是否變化。每一步都有明確的通過標(biāo)準(zhǔn)才能把問題擋在某一層內(nèi)。5.2 常見問題速查表現(xiàn)象可能原因解決辦法MQTT建立連接失敗返回錯(cuò)誤碼5clientId或password與server不匹配用腳本重新生成連接參數(shù)核對時(shí)間戳一致云平臺(tái)看到設(shè)備在線但沒有屬性數(shù)據(jù)上報(bào)topic錯(cuò)誤或JSON服務(wù)ID不匹配拷貝官方topic格式檢查services數(shù)組結(jié)構(gòu)STM32串口打印正常但ESP8266沒數(shù)據(jù)ESP8266供電不穩(wěn)或透傳模式未開啟獨(dú)立供電檢查ATCIPSEND返回結(jié)果DHT11讀數(shù)一直是0或固定值接線松動(dòng)或采樣間隔太短重新插線采樣間隔至少1秒Qt請求返回401token過期或鑒權(quán)頭字段不對刷新token確認(rèn)Header寫的是X-Auth-TokenQt請求能通但界面不刷新JSON解析層級(jí)錯(cuò)誤用接口工具打印原始響應(yīng)對照解析云端命令已下發(fā)STM32沒反應(yīng)訂閱topic用了具體request_id改成訂閱$oc/devices/{device_id}/sys/commands/#繼電器動(dòng)作但模塊發(fā)熱嚴(yán)重驅(qū)動(dòng)電流不足或用了低電平觸發(fā)加三極管或光耦按模塊說明調(diào)整控制電平這個(gè)速查表是根據(jù)我自己調(diào)試過程整理的。遇到問題時(shí)按表格逐項(xiàng)排除大多數(shù)問題不是代碼邏輯而是配置不一致。比如連接失敗多半是clientId的密碼算錯(cuò)命令無響應(yīng)多半是訂閱topic不對。把這些常見坑提前避開項(xiàng)目成功率會(huì)高很多。我還會(huì)把速查表放在項(xiàng)目目錄的README里因?yàn)檫^幾天就會(huì)忘掉再遇到問題時(shí)翻一下比自己重新猜快得多。5.3 幾個(gè)值得記錄的避坑細(xì)節(jié)第一個(gè)避坑點(diǎn)是MQTT報(bào)文的剩余長度字段。PUBLISH報(bào)文的剩余長度既要包含主題長度也要包含body長度我剛開始圖省事少加了一個(gè)字節(jié)導(dǎo)致數(shù)據(jù)一直發(fā)不出去。解決辦法是統(tǒng)一用一個(gè)封裝函數(shù)傳入topic和payload由函數(shù)內(nèi)部計(jì)算總長度不要在調(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ò)請求別用同步阻塞。我最初圖快在按鈕里用waitForFinished()結(jié)果界面直接卡死Windows上尤其明顯。改成信號(hào)槽異步處理后程序流暢很多。現(xiàn)在我的習(xí)慣是請求發(fā)出后先把按鈕置灰響應(yīng)完成后恢復(fù)這樣用戶也不會(huì)因?yàn)橹貜?fù)點(diǎn)擊造成重復(fù)命令。最后再分享一點(diǎn)個(gè)人體會(huì)。這套系統(tǒng)真正值錢的不是某一段源碼而是把設(shè)備、云端和客戶端三層邊界搞清楚。我前期把大量時(shí)間浪費(fèi)在到處找現(xiàn)成代碼上后來靜下心按層拆解先把每一段單獨(dú)調(diào)通再串起來反而很快。這條鏈路聽起來很長但每走一步都會(huì)把MQTT、設(shè)備影子、跨平臺(tái)應(yīng)用編程這些概念從抽象變成實(shí)際體會(huì)。建議你從最簡單的“STM32上報(bào)溫度”開始先別管界面多好看等鏈路通了再慢慢完善。做嵌入式項(xiàng)目信心是依賴一步步驗(yàn)證堆起來的順利完成一次遠(yuǎn)程開關(guān)燈后面所有擴(kuò)展都會(huì)順手很多。 基于STM32與華為云IoT的智能家居遠(yuǎn)程控制系統(tǒng)實(shí)戰(zhàn)
做智能家居項(xiàng)目有一段時(shí)間了從最開始用手機(jī)藍(lán)牙控制一盞燈到后面把設(shè)備真正接入云平臺(tái)中間踩了不少坑。這次分享的是一個(gè)我最近完整跑通的實(shí)戰(zhàn)項(xiàng)目基于STM32做設(shè)備端主控通過華為云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)用三段鏈路串起來適合正在學(xué)習(xí)STM32、準(zhǔn)備接觸云平臺(tái)或者是想從單片機(jī)跳到物聯(lián)網(wǎng)方向的朋友。文章里不會(huì)只講概念而是把整條鏈路的架構(gòu)、關(guān)鍵代碼、參數(shù)計(jì)算和常見問題都攤開來講照著步驟走基本能復(fù)現(xiàn)一個(gè)可以用的原型。1. 系統(tǒng)架構(gòu)與方案選型1.1 三層架構(gòu)劃分整個(gè)智能家居控制系統(tǒng)可以拆成三個(gè)部分設(shè)備采集與控制端、云端接入層、客戶端展示與控制端。設(shè)備端選的是STM32F103C8T6定位是現(xiàn)場控制器負(fù)責(zé)讀取DHT11溫濕度傳感器控制繼電器開關(guān)處理本地按鍵邏輯還要把數(shù)據(jù)組裝成MQTT報(bào)文發(fā)送到云端同時(shí)接收云端下發(fā)的控制指令。STM32本身沒有聯(lián)網(wǎng)能力所以加了一片ESP8266 WiFi模塊STM32通過串口和它通信ESP8266負(fù)責(zé)把TCP數(shù)據(jù)連接到華為云IoT的MQTT端口。這樣分工之后STM32只關(guān)心業(yè)務(wù)邏輯網(wǎng)絡(luò)鏈路交給模組調(diào)試時(shí)哪個(gè)環(huán)節(jié)出了問題一眼就能定位到模塊。云端選用華為云IoT平臺(tái)設(shè)備接入側(cè)兼容標(biāo)準(zhǔn)MQTT協(xié)議支持產(chǎn)品模型、設(shè)備影子、命令下發(fā)和完整運(yùn)維界面。相比自建MQTT服務(wù)器它的優(yōu)勢是開箱即用注冊設(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è)可以通過API查詢也可以配置規(guī)則轉(zhuǎn)發(fā)到其他服務(wù)。對個(gè)人開發(fā)者來說學(xué)習(xí)成本比從零搭建broker低很多而且免費(fèi)額度足以支撐這種教學(xué)項(xiàng)目。Qt端是用戶面對的部分。我用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ì)問為什么不用ESP32這種自帶WiFi的單片機(jī)當(dāng)然可以。ESP32直接把MQTT庫跑在片上硬件成本更低也少一個(gè)串口模塊和獨(dú)立WiFi芯片。我保留STM32加ESP8266是為了讓模塊邊界更清晰。MCU、網(wǎng)絡(luò)模組、云平臺(tái)、客戶端各自獨(dú)立如果是初學(xué)哪個(gè)環(huán)節(jié)出問題更容易定位。等你理解了這條鏈路想切到ESP32只是把MQTT部分從串口報(bào)文改成SDK調(diào)用工作量并不大。也有人會(huì)直接用公共智能家居平臺(tái)好處是App現(xiàn)成、設(shè)備接入快壞處是協(xié)議封閉、界面定制受限更學(xué)不到底層數(shù)據(jù)鏈路的原理。自己搭這套系統(tǒng)雖然初期要多寫代碼但主動(dòng)權(quán)在手里。以后想加攝像頭、語音控制、多房間管理都可以在自己架構(gòu)上擴(kuò)展。方案選型沒有絕對的對錯(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)注冊的設(shè)備ID不要用別名或自定義字符串否則平臺(tái)路由不到。控制指令下發(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)部約定的字段必須對得上否則命令會(huì)丟。建議先到官方文檔把主題和request_id的邏輯理清楚后面聯(lián)調(diào)會(huì)節(jié)省很多時(shí)間。我在第一次聯(lián)調(diào)時(shí)把request_id寫成了固定值結(jié)果第一條命令能收到后續(xù)命令全部超時(shí)后來才發(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í)測可以把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í)對微秒級(jí)延時(shí)要求高我直接用定時(shí)器做延時(shí)函數(shù)而不是for空循環(huán)否則編譯器優(yōu)化級(jí)別一變時(shí)序就亂。校驗(yà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過程省略 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ù)變化量雖然不大但對上報(bào)頻率和模塊壽命都比較友好。還要注意數(shù)據(jù)位順序濕度是高字節(jié)在前溫度也是高字節(jié)在前我第一次讀反了顯示溫濕度顛倒了。2.3 ESP8266聯(lián)網(wǎng)與透傳模式配置讓STM32聯(lián)網(wǎng)我選擇讓ESP8266工作在透傳模式。先用AT指令配置WiFi和TCP連接然后STM32把MQTT字節(jié)流直接發(fā)給串口ESP8266原樣發(fā)到華為云IoT的MQTT端口。這個(gè)方案意味著STM32端要自己實(shí)現(xiàn)MQTT協(xié)議但換來的是對協(xié)議有完全控制調(diào)試時(shí)可以打印每一個(gè)字節(jié)。如果你想讓ESP8266直接跑MQTT AT固件指令是簡單但固件版本很雜出問題時(shí)黑盒排查非常痛苦所以我更推薦透傳原始TCP。常用AT指令流程是這樣先用USB轉(zhuǎn)串口把ESP8266接電腦發(fā)送ATCWMODE1設(shè)置Station模式再ATCWJAP你的WiFi名,你的WiFi密碼連接路由器。WiFi連上后用ATCIPSTARTTCP,你的區(qū)域IoT接入地址,1883建立TCP連接接著ATCIPMODE1進(jìn)入透傳模式最后ATCIPSEND啟動(dòng)發(fā)送。執(zhí)行完返回OK后后續(xù)寫入串口的內(nèi)容都會(huì)通過TCP發(fā)送出去。需要退出發(fā)送時(shí)發(fā)但不是每次都能成功所以在程序里要做超時(shí)和重試。使用官方AT固件的TCP透傳還有一個(gè)好處是網(wǎng)絡(luò)連接狀態(tài)可預(yù)期。單片機(jī)上電后我可以等到AT指令返回CONNECT再加栽MQTT連接邏輯。如果WiFi密碼錯(cuò)誤AT指令會(huì)直接返回ERROR這時(shí)候不需要去查代碼問題在網(wǎng)絡(luò)配置。很多人用ESP8266模塊會(huì)遇到AT無響應(yīng)查看一下串口波特率是不是115200以及模塊供電是否穩(wěn)定這兩個(gè)因素占了八成問題。2.4 在STM32上實(shí)現(xiàn)MQTT報(bào)文生成MQTT報(bào)文并不復(fù)雜但如果你從來沒在裸機(jī)上拼過第一次遇到會(huì)有點(diǎn)懵。固定頭第一個(gè)字節(jié)表示報(bào)文類型和標(biāo)志位第二個(gè)字節(jié)是剩余長度。CONNECT報(bào)文需要在有效載荷里按順序填協(xié)議名、協(xié)議版本、連接標(biāo)記、心跳時(shí)間、clientId、username、password。華為云IoT要求這三個(gè)鑒權(quán)字段必須和平臺(tái)計(jì)算值一致一個(gè)字符不對都會(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字符串長度和內(nèi)容所有多字節(jié)數(shù)字都按網(wǎng)絡(luò)序大端排列。CONNECT發(fā)送之后必須等待CONNACK響應(yīng)如果沒收到優(yōu)先檢查clientId、username、password是否一致。上報(bào)數(shù)據(jù)用PUBLISH報(bào)文固定頭是0x30后面接主題長度、主題內(nèi)容再跟上JSON body。QoS建議用0環(huán)境數(shù)據(jù)重復(fù)上報(bào)丟一幀下幀會(huì)補(bǔ)上。最容易錯(cuò)的是剩余長度字段它不僅要包含主題還要包含整個(gè)body我調(diào)試時(shí)打印報(bào)文發(fā)現(xiàn)比標(biāo)準(zhǔn)格式多了一個(gè)字節(jié)最后查出來是字符串結(jié)尾符被當(dāng)成數(shù)據(jù)發(fā)出去加個(gè)長度接口就解決了。2.5 云端命令接收與本地控制執(zhí)行設(shè)備接收云端命令必須先在連接后發(fā)送SUBSCRIBE報(bào)文。主題用通配符#訂閱命令下行目錄也就是$oc/devices/{device_id}/sys/commands/#這樣平臺(tái)推下來的帶不同request_id的命令都能收到。收到PUBLISH后先提取主題里的request_id再從JSON payload里解析paras.switch把對應(yīng)GPIO置高或置低。控制邏輯處理完以后必須向響應(yīng)主題回一條消息否則平臺(tái)會(huì)認(rèn)為命令執(zhí)行超時(shí)。我在代碼里把“收到命令”和“執(zhí)行完成”分成兩個(gè)日志點(diǎn)方便判斷是網(wǎng)絡(luò)沒到還是執(zhí)行出錯(cuò)。處理命令時(shí)有一個(gè)小坑繼電器模塊觸發(fā)電平可能和你想的相反。我用的模塊是低電平觸發(fā)也就是GPIO輸出0時(shí)繼電器吸合輸出1時(shí)斷開。如果你在測試時(shí)發(fā)現(xiàn)云端發(fā)‘開’結(jié)果燈關(guān)了檢查一下模塊是高電平還是低電平觸發(fā)把控制邏輯反過來就行。另外本地按鍵開關(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è)備注冊登錄華為云IoT設(shè)備接入控制臺(tái)后先創(chuàng)建一個(gè)產(chǎn)品。產(chǎn)品模型相當(dāng)于設(shè)備的說明書告訴平臺(tái)這個(gè)設(shè)備有哪些屬性、支持哪些命令。我創(chuàng)建的服務(wù)ID叫Env屬性列表如下。屬性名類型說明temperatureint當(dāng)前溫度humidityint當(dāng)前濕度switchenum0-關(guān)閉1-開啟溫度濕度用整數(shù)就夠了DHT11本身沒有小數(shù)精度。枚舉屬性的switch只允許填0或1平臺(tái)會(huì)自動(dòng)校驗(yàn)。屬性名建議統(tǒng)一小寫駝峰后面STM32組裝JSON和Qt解析時(shí)保持一致我見過有人把temperature寫成Temperature結(jié)果云端一直收不到。產(chǎn)品創(chuàng)建完成后注冊設(shè)備并記錄設(shè)備ID和密鑰這兩個(gè)值后續(xù)計(jì)算連接參數(shù)都會(huì)用到。設(shè)備ID是一長串字符串密鑰是設(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è)備密鑰對時(shí)間戳做HMAC-SHA256再轉(zhuǎn)十六進(jìn)制。很多人第一次會(huì)漏了下劃線里的0_0導(dǎo)致平臺(tái)無法識(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è)備本身沒有實(shí)時(shí)鐘系統(tǒng)時(shí)間不準(zhǔn)我一開始直接在板子上取系統(tǒng)啟動(dòng)后的毫秒計(jì)數(shù)算出來的密碼和clientId不匹配連接一直失敗。后來我把時(shí)間戳放在PC上算好固定值直接燒進(jìn)去測通。但固定時(shí)間戳在長時(shí)間運(yùn)行時(shí)斷線重連會(huì)不太安全最好在ESP8266連上WiFi后用SNTP獲取一次UTC時(shí)間再動(dòng)態(tài)生成連接參數(shù)。如果不想引入NTP最簡單的辦法是每次重新上電都重新計(jì)算一般教學(xué)項(xiàng)目夠用了。3.3 設(shè)備上報(bào)屬性與云端驗(yàn)證設(shè)備連接成功后上報(bào)屬性的topic和payload必須嚴(yán)格按平臺(tá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è)備詳情頁查看如果能看到溫濕度值說明鏈路通了。有一次我的數(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è)備沒有及時(shí)響應(yīng)平臺(tái)會(huì)記錄超時(shí)。測試階段我直接用控制臺(tái)提供的“設(shè)備調(diào)試”功能下發(fā)命令比先寫Qt端再測要快得多。這一步通了后面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請求調(diào)用REST API。Qt的QNetworkAccessManager對HTTPS支持很好跨平臺(tái)傳JSON、解析響應(yīng)都沒問題。這樣客戶端不需要維護(hù)長連接每次操作發(fā)一個(gè)HTTP請求拿到結(jié)果刷新界面既穩(wěn)又省心。如果你確實(shí)想讓Qt走M(jìn)QTT一般來說需要云平臺(tái)規(guī)則引擎把設(shè)備數(shù)據(jù)轉(zhuǎn)發(fā)到另一個(gè)主題這對初學(xué)者來說反而是額外負(fù)擔(dān)。4.2 獲取Access Token的流程調(diào)用華為云IoT應(yīng)用側(cè)API第一步是獲取Token。它用的是IAM認(rèn)證需要先拿賬號(hào)或用戶憑證向IAM服務(wù)請求一個(gè)X-Auth-Token。流程比較繁瑣但邏輯很固定構(gòu)造POST請求帶上賬號(hào)名密碼或用戶憑證從響應(yīng)頭里取出token。我建議先在電腦上用API調(diào)試工具把這個(gè)接口調(diào)通再把同樣的HTTP請求搬到Qt里。令牌一般有效期一小時(shí)過期后重新獲取。在桌面端我把token放在一個(gè)全局對象里每次網(wǎng)絡(luò)請求前檢查是否快過期超過50分鐘就主動(dòng)刷新這樣長時(shí)間掛著也不會(huì)突然401。4.3 核心代碼查詢設(shè)備影子查詢設(shè)備影子接口用來獲取設(shè)備最新狀態(tài)。請求路徑類似GET https://{endpoint}/v5/iot/{project_id}/devices/{device_id}/shadow端點(diǎn)和projectId從控制臺(tái)獲取。Header里帶上X-Auth-Token。Qt里用QNetworkAccessManager發(fā)起異步GET請求代碼如下。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字段。我第一次寫解析很樂觀直接按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請求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)品模型的命令定義頁逐字檢查。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做了圓角卡片和深色背景看起來有點(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)庫放到程序目錄Linux下安裝ca-certificates基本就解決了。5. 全鏈路聯(lián)調(diào)與問題排查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)沒問題再用平臺(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溫度是否變化。每一步都有明確的通過標(biāo)準(zhǔn)才能把問題擋在某一層內(nèi)。5.2 常見問題速查表現(xiàn)象可能原因解決辦法MQTT建立連接失敗返回錯(cuò)誤碼5clientId或password與server不匹配用腳本重新生成連接參數(shù)核對時(shí)間戳一致云平臺(tái)看到設(shè)備在線但沒有屬性數(shù)據(jù)上報(bào)topic錯(cuò)誤或JSON服務(wù)ID不匹配拷貝官方topic格式檢查services數(shù)組結(jié)構(gòu)STM32串口打印正常但ESP8266沒數(shù)據(jù)ESP8266供電不穩(wěn)或透傳模式未開啟獨(dú)立供電檢查ATCIPSEND返回結(jié)果DHT11讀數(shù)一直是0或固定值接線松動(dòng)或采樣間隔太短重新插線采樣間隔至少1秒Qt請求返回401token過期或鑒權(quán)頭字段不對刷新token確認(rèn)Header寫的是X-Auth-TokenQt請求能通但界面不刷新JSON解析層級(jí)錯(cuò)誤用接口工具打印原始響應(yīng)對照解析云端命令已下發(fā)STM32沒反應(yīng)訂閱topic用了具體request_id改成訂閱$oc/devices/{device_id}/sys/commands/#繼電器動(dòng)作但模塊發(fā)熱嚴(yán)重驅(qū)動(dòng)電流不足或用了低電平觸發(fā)加三極管或光耦按模塊說明調(diào)整控制電平這個(gè)速查表是根據(jù)我自己調(diào)試過程整理的。遇到問題時(shí)按表格逐項(xiàng)排除大多數(shù)問題不是代碼邏輯而是配置不一致。比如連接失敗多半是clientId的密碼算錯(cuò)命令無響應(yīng)多半是訂閱topic不對。把這些常見坑提前避開項(xiàng)目成功率會(huì)高很多。我還會(huì)把速查表放在項(xiàng)目目錄的README里因?yàn)檫^幾天就會(huì)忘掉再遇到問題時(shí)翻一下比自己重新猜快得多。5.3 幾個(gè)值得記錄的避坑細(xì)節(jié)第一個(gè)避坑點(diǎn)是MQTT報(bào)文的剩余長度字段。PUBLISH報(bào)文的剩余長度既要包含主題長度也要包含body長度我剛開始圖省事少加了一個(gè)字節(jié)導(dǎo)致數(shù)據(jù)一直發(fā)不出去。解決辦法是統(tǒng)一用一個(gè)封裝函數(shù)傳入topic和payload由函數(shù)內(nèi)部計(jì)算總長度不要在調(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ò)請求別用同步阻塞。我最初圖快在按鈕里用waitForFinished()結(jié)果界面直接卡死Windows上尤其明顯。改成信號(hào)槽異步處理后程序流暢很多。現(xiàn)在我的習(xí)慣是請求發(fā)出后先把按鈕置灰響應(yīng)完成后恢復(fù)這樣用戶也不會(huì)因?yàn)橹貜?fù)點(diǎn)擊造成重復(fù)命令。最后再分享一點(diǎn)個(gè)人體會(huì)。這套系統(tǒng)真正值錢的不是某一段源碼而是把設(shè)備、云端和客戶端三層邊界搞清楚。我前期把大量時(shí)間浪費(fèi)在到處找現(xiàn)成代碼上后來靜下心按層拆解先把每一段單獨(dú)調(diào)通再串起來反而很快。這條鏈路聽起來很長但每走一步都會(huì)把MQTT、設(shè)備影子、跨平臺(tái)應(yīng)用編程這些概念從抽象變成實(shí)際體會(huì)。建議你從最簡單的“STM32上報(bào)溫度”開始先別管界面多好看等鏈路通了再慢慢完善。做嵌入式項(xiàng)目信心是依賴一步步驗(yàn)證堆起來的順利完成一次遠(yuǎn)程開關(guān)燈后面所有擴(kuò)展都會(huì)順手很多。