庫(kù)環(huán)境控制系統(tǒng)：STM32+ESP8266實(shí)現(xiàn)溫濕度粉塵監(jiān)測(cè)與控制)
1. 倉(cāng)庫(kù)環(huán)境控制先想清楚要控什么做倉(cāng)庫(kù)環(huán)境控制系統(tǒng)第一反應(yīng)往往是STM32 傳感器 執(zhí)行機(jī)構(gòu)網(wǎng)上類似的畢業(yè)設(shè)計(jì)和工程案例一抓一大把。但真把這套系統(tǒng)做出來(lái)、放到真實(shí)倉(cāng)庫(kù)里跑你會(huì)發(fā)現(xiàn)最難的從來(lái)不是代碼而是你壓根沒(méi)想清楚控制這兩個(gè)字意味著什么。我這邊項(xiàng)目的初始需求是溫濕度監(jiān)測(cè)、粉塵濃度監(jiān)測(cè)、自動(dòng)通風(fēng)除濕數(shù)據(jù)還要通過(guò)ESP8266上傳云端。對(duì)應(yīng)的使用場(chǎng)景是電子元器件倉(cāng)庫(kù)——這類倉(cāng)庫(kù)對(duì)溫濕度和潔凈度都有明確要求尤其是防潮防靜電環(huán)境失控造成的損失遠(yuǎn)比想象中大。系統(tǒng)最終要做到的效果是現(xiàn)場(chǎng)有一套本地閉環(huán)控制邏輯能獨(dú)立工作不依賴網(wǎng)絡(luò)同時(shí)數(shù)據(jù)要上云方便遠(yuǎn)程查看和告警。拆解下來(lái)整個(gè)系統(tǒng)其實(shí)分四個(gè)層次感知層溫濕度傳感器、粉塵傳感器負(fù)責(zé)采集環(huán)境數(shù)據(jù)控制層STM32做主控MCU跑控制邏輯決定要不要通風(fēng)、要不要除濕執(zhí)行層風(fēng)機(jī)、除濕機(jī)、加熱器、繼電器組實(shí)施具體動(dòng)作網(wǎng)絡(luò)層ESP8266做主控的通信外腦把數(shù)據(jù)推到云端很多新手項(xiàng)目做到最后變成傳感器讀數(shù)在OLED上滾動(dòng)播放本質(zhì)上就是只做了感知層和顯示層控制邏輯要么沒(méi)寫要么寫成了定時(shí)開(kāi)關(guān)——那不能叫環(huán)境控制系統(tǒng)那叫電子溫度計(jì)。這個(gè)項(xiàng)目里我做了一個(gè)關(guān)鍵決策M(jìn)CU選STM32F103C8T6通信模塊選ESP8266-01S本地控制邏輯全跑在STM32中ESP8266只負(fù)責(zé)和云端打交道。為什么不直接讓ESP8266干所有事因?yàn)镋SP8266雖然便宜、能聯(lián)網(wǎng)但它的GPIO和實(shí)時(shí)性做這種多傳感器采集控制閉環(huán)并不舒服尤其是風(fēng)扇、除濕機(jī)這類執(zhí)行機(jī)構(gòu)的PWM控制和邏輯調(diào)度還是STM32的強(qiáng)項(xiàng)。兩者各干各擅長(zhǎng)的這是整體架構(gòu)的核心思路。2. 硬件選型與接線這里最容易返工2.1 主控與傳感器的搭配邏輯主控選了STM32F103C8T6也就是俗稱的藍(lán)丸板。它便宜、資料多、引腳夠用做這種環(huán)境控制項(xiàng)目綽綽有余。你也許會(huì)在網(wǎng)上看到有人用STM32F407甚至F429做同樣的功能說(shuō)實(shí)話沒(méi)必要性能嚴(yán)重過(guò)剩功耗還高。溫濕度傳感器是DHT22也叫AM2302測(cè)量范圍-40~80°C、0~100%RH精度±0.5°C和±2%RH比DHT11靠譜太多。DHT11的精度只有±2°C和±5%RH在倉(cāng)庫(kù)環(huán)境控制這種場(chǎng)景下誤差大了直接影響控制邏輯的判定——比如實(shí)際濕度80%RHDHT11測(cè)出來(lái)75%RH除濕機(jī)永遠(yuǎn)啟動(dòng)不了倉(cāng)庫(kù)里的元器件一樣受潮。所以別省那幾塊錢DHT22是底線。粉塵傳感器選了GP2Y1010AU0F夏普那款經(jīng)典的紅外粉塵傳感器。它能測(cè)PM2.5級(jí)別的懸浮顆粒物原理是紅外LED照射空氣中的顆粒物光接收管檢測(cè)散射光強(qiáng)度輸出一個(gè)與粉塵濃度呈正相關(guān)的模擬電壓。輸出是模擬量直接用STM32的ADC采集就行。它的靈敏度用靈敏度系數(shù)換算具體公式后面細(xì)說(shuō)。2.2 執(zhí)行機(jī)構(gòu)與驅(qū)動(dòng)方案執(zhí)行機(jī)構(gòu)里最核心的是通風(fēng)和除濕。通風(fēng)用的是24V軸流風(fēng)機(jī)倉(cāng)庫(kù)面積不大時(shí)這種風(fēng)機(jī)足夠換氣除濕機(jī)是成品獨(dú)立除濕機(jī)但它本身不帶干接點(diǎn)控制接口所以我用了繼電器組來(lái)做開(kāi)關(guān)控制。注意成品除濕機(jī)改裝控制時(shí)一定要看說(shuō)明書(shū)確認(rèn)它支持通過(guò)斷電重啟來(lái)控制啟停——有的除濕機(jī)斷電重啟后需要手動(dòng)再按一次開(kāi)關(guān)那個(gè)沒(méi)法用繼電器直接控制得自己改電路或者選帶遙控器的型號(hào)。繼電器選的是5V供電的2路光耦隔離繼電器模塊低電平觸發(fā)。為什么強(qiáng)調(diào)光耦隔離因?yàn)槔^電器后面接的是24V風(fēng)機(jī)、220V除濕機(jī)如果共地串?dāng)_STM32的3.3V系統(tǒng)很容易被打掛。光耦把控制側(cè)和執(zhí)行側(cè)隔離了安全系數(shù)高很多。這個(gè)細(xì)節(jié)在實(shí)驗(yàn)室玩玩不覺(jué)得真放到倉(cāng)庫(kù)現(xiàn)場(chǎng)就知道有多大價(jià)值了。另外還加了一路PWM控制的排風(fēng)扇調(diào)速——不是簡(jiǎn)單的開(kāi)/關(guān)而是根據(jù)溫濕度偏差大小動(dòng)態(tài)調(diào)速。這需要一個(gè)MOS管驅(qū)動(dòng)電路IRLZ44N這種邏輯電平MOS管正好合適可以用STM32的TIM輸出PWM直接控制。2.3 接線表的詳細(xì)說(shuō)明接線是整個(gè)系統(tǒng)最繁瑣但最不能出錯(cuò)的部分。我按功能模塊整理了接線表你照著接基本不會(huì)亂模塊信號(hào)線STM32引腳備注DHT22DATAPA6需外接4.7kΩ上拉GP2Y1010AU0FV-LED、LED-GND3.3V、GND脈沖驅(qū)動(dòng)由PWM控制GP2Y1010AU0FVOPA1ADC1模擬輸出繼電器模塊 IN1PA0低電平觸發(fā)控制除濕機(jī)繼電器模塊 IN2PA1低電平觸發(fā)控制風(fēng)機(jī)開(kāi)關(guān)MOS管柵極PA2PWM輸出風(fēng)機(jī)調(diào)速ESP8266-01S TXPA9USART1_TX交叉連接3.3V邏輯兼容ESP8266-01S RXPA10USART1_RX交叉連接3.3V邏輯兼容OLEDI2CPB8、PB9SCL、SDA0.96寸12864有一個(gè)細(xì)節(jié)特別容易被忽略GP2Y1010AU0F的LED驅(qū)動(dòng)不是直接給高低電平的而是需要一個(gè)周期10ms、脈沖寬度0.32ms的脈沖信號(hào)采樣點(diǎn)要放在脈沖開(kāi)始后0.28ms處。如果直接用GPIO高低電平驅(qū)動(dòng)LED輸出信號(hào)會(huì)完全不正常。我在這個(gè)項(xiàng)目里用TIM1的PWM輸出來(lái)生成這個(gè)脈沖波形然后ADC采樣時(shí)機(jī)對(duì)齊到脈沖高電平的中段這樣讀到的電壓才穩(wěn)定。關(guān)于ESP8266和STM32的引腳對(duì)接網(wǎng)上有大量自鎖接法的討論。ESP8266-01S的GPIO0和GPIO2必須保持高電平才能正常啟動(dòng)運(yùn)行而它的TX/RX是3.3V邏輯和STM32的3.3V系統(tǒng)電平正好匹配不需要額外的電平轉(zhuǎn)換電路。不過(guò)ESP8266上電瞬間的電流峰值比較大有時(shí)候會(huì)拉低3.3V電壓導(dǎo)致它啟動(dòng)失敗這個(gè)坑我在調(diào)試時(shí)踩過(guò)解決方案是ESP8266的供電獨(dú)立用AMS1117-3.3V不要和STM32共用同一個(gè)LDO輸出——具體做法后面挑重點(diǎn)詳細(xì)說(shuō)。3. 傳感器數(shù)據(jù)采集與處理數(shù)學(xué)比代碼更重要3.1 DHT22的時(shí)序與校驗(yàn)DHT22用的是單總線協(xié)議數(shù)據(jù)線只有一根所有通信靠時(shí)序控制。它的采集過(guò)程需要經(jīng)過(guò)主機(jī)發(fā)送起始信號(hào) → DHT22響應(yīng) → 40位數(shù)據(jù)輸出三個(gè)階段。網(wǎng)上有現(xiàn)成的庫(kù)函數(shù)但我建議你還是理解一下時(shí)序本質(zhì)——因?yàn)楹芏鄠}(cāng)庫(kù)環(huán)境下線路長(zhǎng)了、干擾大了DHT22的時(shí)序會(huì)漂移靠庫(kù)函數(shù)里的死循環(huán)等待經(jīng)常讀到全0或校驗(yàn)失敗。DHT22的40位數(shù)據(jù)由16位濕度、16位溫度、8位校驗(yàn)和組成。其中溫度最高位為1時(shí)表示零下溫度用補(bǔ)碼表示。比如溫度是負(fù)數(shù)直接按無(wú)符號(hào)數(shù)解析會(huì)解析出一個(gè)很大的錯(cuò)誤值這點(diǎn)在冬天北方倉(cāng)庫(kù)特別容易踩坑。校驗(yàn)方式是前32位數(shù)據(jù)之和的低8位等于校驗(yàn)和不相等直接丟棄本次數(shù)據(jù)重新采樣。我在讀取DHT22時(shí)做了三件事連續(xù)讀取失敗3次才報(bào)警避免偶發(fā)錯(cuò)誤觸發(fā)誤告警限幅濾波如果溫度突變超過(guò)5°C或濕度突變超過(guò)10%RH認(rèn)為數(shù)據(jù)異常用上一次有效數(shù)據(jù)定時(shí)采樣而非循環(huán)采樣DHT22兩次讀取間隔必須大于2秒否則傳感器自身會(huì)處于忙狀態(tài)返回?cái)?shù)據(jù)不穩(wěn)定好多人的溫濕度顯示跳動(dòng)得很厲害就是沒(méi)有做限幅濾波本質(zhì)是讀取時(shí)序不穩(wěn)定或者傳感器老化后輸出飄了。DHT22采購(gòu)時(shí)也得留個(gè)心眼市面上很多號(hào)稱DHT22的模塊其實(shí)用的是國(guó)產(chǎn)替代芯片雖然兼容但時(shí)間長(zhǎng)了穩(wěn)定性差一些。有條件的話用SHT30或者AHT20這類I2C數(shù)字傳感器效果會(huì)更好——當(dāng)然這是后話。3.2 GP2Y1010AU0F的電壓-濃度換算粉塵傳感器的數(shù)據(jù)處理是另一個(gè)容易翻車的地方。GP2Y1010AU0F的輸出電壓大約在0~3.6V之間對(duì)應(yīng)粉塵濃度大約0~0.5mg/m3但輸出電壓和粉塵濃度不是線性關(guān)系。官方數(shù)據(jù)手冊(cè)給出的關(guān)系近似如下粉塵濃度(mg/m3) ≈ (Vout - 0.6V) × 0.5V對(duì)應(yīng)的濃度系數(shù)實(shí)際工程中更實(shí)用的做法是用標(biāo)定曲線插值但業(yè)余條件下標(biāo)定條件不夠很多人的處理方式是直接用線性公式估濃度(mg/m3) (Vout_voltage - V_0) / K其中V_0是潔凈環(huán)境下的零點(diǎn)電壓一般0.3~0.6V之間不同批次硬件有差異K是靈敏度系數(shù)大約0.15~0.2 V/(mg/m3)。你手里這塊傳感器的V_0和K是多少需要通過(guò)實(shí)測(cè)得到——在潔凈環(huán)境測(cè)一次零點(diǎn)電壓然后在已知濃度的測(cè)試環(huán)境中測(cè)一次電壓兩個(gè)點(diǎn)就能算出K。這在很多教程里被當(dāng)成公式一抄就行但我建議每個(gè)人拿到傳感器后都做一次零點(diǎn)標(biāo)定把V_0記下來(lái)。不同批次、不同模塊之間V_0差異非常大接上去直接套公式的結(jié)果就是把偏置誤差帶進(jìn)了控制邏輯——本來(lái)0.1mg/m3算成0.25mg/m3風(fēng)機(jī)瞎轉(zhuǎn)。ADC采集的時(shí)候我一般開(kāi)12位分辨率參考電壓用內(nèi)部參考2.9VF103剛好多路ADC都支持內(nèi)部參考然后軟件做多次采樣取平均滑動(dòng)濾波。粉塵信號(hào)本身波動(dòng)很大單次采樣數(shù)值跳來(lái)跳去如果不濾波控制邏輯會(huì)反復(fù)啟停風(fēng)機(jī)——這是很多人做完之后發(fā)現(xiàn)風(fēng)機(jī)一會(huì)兒轉(zhuǎn)一會(huì)兒停的根本原因。3.3 ADC與濾波策略的取舍ADC濾波我用了兩種策略的組合中位值濾波連續(xù)采樣11次排序取中間值濾掉意外尖峰滑動(dòng)平均濾波最近5次中位值做平均平滑輸出為什么不用簡(jiǎn)單平均因?yàn)楹?jiǎn)單平均在遇到強(qiáng)干擾尖峰時(shí)一個(gè)異常值能拉偏平均值很多。中位值濾波能徹底剔除毛刺代價(jià)是采樣速度慢一點(diǎn)但環(huán)境控制系統(tǒng)的采樣周期做幾百毫秒毫無(wú)壓力。注意STM32F103的ADC在連續(xù)采樣模式下如果你開(kāi)了DMA循環(huán)要小心數(shù)據(jù)覆蓋問(wèn)題。我最終采用的是定時(shí)器觸發(fā)單次采樣每次取完一組數(shù)據(jù)后處理完再啟動(dòng)下一組邏輯更清晰不容易踩DMA緩沖區(qū)錯(cuò)位的坑。4. 控制邏輯設(shè)計(jì)從讀數(shù)據(jù)到控環(huán)境的質(zhì)變4.1 溫濕度閉環(huán)控制控制邏輯是整個(gè)系統(tǒng)的靈魂。設(shè)計(jì)原則是優(yōu)先本地閉環(huán)云端只是遠(yuǎn)程監(jiān)控和數(shù)據(jù)備份。溫度控制的目標(biāo)區(qū)間我設(shè)在20~26°C。這個(gè)區(qū)間主要是參考電子元器件倉(cāng)庫(kù)的一般要求兼顧春季和秋季不用空調(diào)的自然溫度。當(dāng)溫度高于26°C時(shí)啟動(dòng)風(fēng)機(jī)通風(fēng)低于20°C時(shí)打開(kāi)加熱器如果配置的話。但通風(fēng)的同時(shí)要考慮濕度——外面如果在下雨室外空氣濕度接近100%RH這時(shí)候把外界潮濕空氣抽進(jìn)來(lái)溫度降了濕度卻上去了得不償失。所以控制邏輯必須做成環(huán)境綜合判斷不能只盯單一參數(shù)。典型規(guī)則如下條件動(dòng)作溫度 26°C 且 濕度 70%RH啟動(dòng)風(fēng)機(jī)通風(fēng)降溫溫度 26°C 且 濕度 ≥ 70%RH啟動(dòng)除濕機(jī)暫不通風(fēng)濕度 65%RH啟動(dòng)除濕機(jī) 關(guān)窗模擬濕度 ≥ 80%RH 且持續(xù)10分鐘強(qiáng)制通風(fēng)除濕除濕機(jī)除濕效率有限時(shí)溫度 18°C 且 濕度 70%RH加熱除濕如有加熱器濕度控制我用的是雙閾值滯回比較。比如濕度上限設(shè)為65%RH下限設(shè)為55%RH當(dāng)濕度超過(guò)65%RH時(shí)啟動(dòng)除濕機(jī)當(dāng)濕度降到55%RH以下時(shí)才關(guān)閉除濕機(jī)。為什么用滯回因?yàn)椴挥脺貢?huì)變成超過(guò)65%就啟動(dòng)降到64.9%就關(guān)閉一天之內(nèi)繼電器能咔嗒咔嗒響上百次繼電器壽命很快就磨完了除濕機(jī)壓縮機(jī)頻繁啟停也容易損壞。這個(gè)道理和家里的空調(diào)溫控是一樣的只不過(guò)很多人剛開(kāi)始做系統(tǒng)控制時(shí)根本沒(méi)往這方面想。滯回量一般設(shè)5~10%RH左右比較合理太小沒(méi)效果太大會(huì)導(dǎo)致環(huán)境波動(dòng)大。4.2 粉塵濃度聯(lián)動(dòng)控制粉塵濃度與通風(fēng)的聯(lián)動(dòng)邏輯和溫濕度類似但更簡(jiǎn)單閾值設(shè)為0.15mg/m3超過(guò)就啟動(dòng)風(fēng)機(jī)降到0.10mg/m3以下再停。同樣給了滯回區(qū)0.05mg/m3。但這里有個(gè)容易忽略的點(diǎn)粉塵濃度傳感器的讀數(shù)受空氣流速影響。如果風(fēng)機(jī)排氣口正好對(duì)著傳感器位置讀數(shù)會(huì)明顯偏低因?yàn)闅饬靼丫植繀^(qū)域的粉塵吹走了如果傳感器裝在墻角落氣流不流通讀數(shù)又會(huì)偏高。所以在實(shí)際安裝中傳感器位置要選在倉(cāng)庫(kù)中部、離地面1.5~1.8米左右的位置盡量避開(kāi)直吹氣流。這是純工程經(jīng)驗(yàn)很多教程里不會(huì)提醒。另外粉塵濃度和濕度也有關(guān)系——高濕度環(huán)境下顆粒物吸濕后會(huì)變得更重沉降加快濃度讀數(shù)會(huì)比干燥環(huán)境下偏低。如果要精細(xì)控制可以在高濕度時(shí)段對(duì)粉塵閾值做點(diǎn)補(bǔ)償不過(guò)大多數(shù)倉(cāng)庫(kù)場(chǎng)景沒(méi)必要做這個(gè)先跑起來(lái)再說(shuō)。4.3 定時(shí)調(diào)度與狀態(tài)機(jī)設(shè)計(jì)判斷要不要開(kāi)風(fēng)機(jī)/除濕機(jī)表面看是一個(gè)比較指令但實(shí)際系統(tǒng)里我建議把它設(shè)計(jì)成有限狀態(tài)機(jī)。每個(gè)外設(shè)處在不同狀態(tài)下行為完全不同風(fēng)機(jī)停止 → 啟動(dòng)中 → 運(yùn)行 → 停止中除濕機(jī)停止 → 啟動(dòng)延時(shí) → 運(yùn)行 → 壓縮機(jī)停機(jī)延時(shí) → 停止之所以給除濕機(jī)設(shè)啟動(dòng)延時(shí)和停機(jī)延時(shí)是因?yàn)槌凉駲C(jī)的壓縮機(jī)不能頻繁啟停。從運(yùn)行到停止壓縮機(jī)不能立刻斷電否則制冷劑回流會(huì)產(chǎn)生液擊損壞壓縮機(jī)。標(biāo)準(zhǔn)做法是切斷除濕機(jī)繼電器后至少等待3分鐘再允許重新啟動(dòng)。這一條很多教程都一筆帶過(guò)了實(shí)際是除濕機(jī)控制系統(tǒng)可靠性的關(guān)鍵。你直接用繼電器去控制一臺(tái)壓縮機(jī)類設(shè)備不做停機(jī)延時(shí)可能一個(gè)星期內(nèi)壓縮機(jī)就報(bào)廢了。狀態(tài)機(jī)的實(shí)現(xiàn)用switch-case就夠了不需要引入RTOS。整個(gè)系統(tǒng)的運(yùn)行節(jié)奏大概是每2秒讀一次DHT22每1秒讀一次粉塵傳感器每5秒做一次狀態(tài)判斷和閾值比較任何狀態(tài)切換在OLED上同步顯示這節(jié)奏下來(lái)整個(gè)控制邏輯流暢不卡頓同時(shí)避免了傳感器數(shù)據(jù)的瘋狂抖動(dòng)。5. ESP8266上云本地控制之外的遠(yuǎn)程大腦5.1 為什么要讓ESP8266單獨(dú)跑先說(shuō)說(shuō)我在讓STM32自己帶網(wǎng)絡(luò)和ESP8266獨(dú)立上網(wǎng)之間做的選擇。STM32F103C8T6本身不帶以太網(wǎng)MAC要聯(lián)網(wǎng)就得外掛ENC28J60之類的以太網(wǎng)模塊或者SPI接口的W5500但這些都是有線網(wǎng)絡(luò)方案——在倉(cāng)庫(kù)現(xiàn)場(chǎng)布線麻煩而且W5500的電路復(fù)雜度明顯高于ESP8266。ESP8266自帶WiFi協(xié)議棧一個(gè)串口就能通信從開(kāi)發(fā)效率到功耗都是更好的選擇。更關(guān)鍵的考慮是控制邏輯的獨(dú)立性。如果網(wǎng)絡(luò)功能和控制功能擠在同一個(gè)MCU上一旦WiFi協(xié)議棧出問(wèn)題連接卡死、緩沖區(qū)溢出整個(gè)控制系統(tǒng)就癱瘓了。分開(kāi)之后ESP8266最多是連不上網(wǎng)本地溫濕度監(jiān)控和風(fēng)機(jī)控制不受影響——這個(gè)思路在工業(yè)控制領(lǐng)域叫自治控制簡(jiǎn)單說(shuō)就是本地系統(tǒng)不要依賴外部資源才能保命。5.2 ESP8266的AT指令配置ESP8266-01S出廠默認(rèn)就是AT固件可以直接用串口和STM32通信。8266在項(xiàng)目里當(dāng)一個(gè)串口轉(zhuǎn)WiFi的透明通道來(lái)用。我配置ESP8266的核心指令序列如下AT ATCWMODE1 // 設(shè)置為Station模式連接路由器 ATCWJAPSSID,密碼 // 連接WiFi ATMQTTUSERCFG0,1,客戶端ID,用戶名,密碼,0,0, // MQTT用戶配置 ATMQTTCONN0,IP地址,1883,1 // 連接MQTT服務(wù)器 ATMQTTSUB0,主題/runtime/device/xxx/msg/property/post,1 // 訂閱云端指令關(guān)于AT指令細(xì)節(jié)有一個(gè)特別容易踩的坑ATCWSAP和ATCWJAP的WiFi名稱若包含中文或特殊字符8266會(huì)返回ERROR。很多倉(cāng)庫(kù)現(xiàn)場(chǎng)的WiFi是中文SSID這個(gè)坑會(huì)讓新手卡很久。解決辦法是路由器開(kāi)一個(gè)2.4GHz的英文SSID專門給設(shè)備用注意不要帶空格和$這類特殊符號(hào)。然后是MQTT連接的穩(wěn)定性問(wèn)題。ESP8266的AT固件和MQTT服務(wù)器之間如果長(zhǎng)時(shí)間沒(méi)數(shù)據(jù)交互服務(wù)器會(huì)斷開(kāi)連接8266還渾然不知。解決方法是每30秒發(fā)一個(gè)心跳包ATMQTTPUB0,主題,1,{\status\:\online\},0,0如果連接異常斷開(kāi)STM32檢測(cè)到TCP連接已關(guān)閉之類的返回后要把ESP8266重新初始化順序是ATRST → ATCWMODE → ATCWJAP → ATMQTTCONN。整個(gè)重連過(guò)程要控制好節(jié)奏不要一失敗就瘋狂重試。5.3 數(shù)據(jù)上云協(xié)議的設(shè)計(jì)數(shù)據(jù)上云的格式我用的是JSON字段如下{ deviceId: WH01, temp: 23.5, hum: 58.2, pm25: 0.12, fanStatus: 1, dehumidifierStatus: 0, timestamp: 1699833600 }esp8266 AT指令里發(fā)JSON最大的坑是AT指令本身的長(zhǎng)度限制。經(jīng)典的ESP8266-01S AT固件單條指令長(zhǎng)度默認(rèn)限制為256字節(jié)。我這個(gè)JSON串大概120字節(jié)剛好夠。如果你的數(shù)據(jù)量大比如要傳歷史數(shù)據(jù)或者帶中文備注超過(guò)了長(zhǎng)度限制就必須把數(shù)據(jù)分塊或者改用固件允許的更長(zhǎng)指令比如ATMQTTPUBRAW。關(guān)于云平臺(tái)的選擇我最終用了常見(jiàn)的物聯(lián)網(wǎng)云平臺(tái)MQTT接入方式將數(shù)據(jù)實(shí)時(shí)推送到云端dashboard。有些平臺(tái)還支持在網(wǎng)頁(yè)端直接下發(fā)指令控制風(fēng)機(jī)/除濕機(jī)這個(gè)功能其實(shí)就是向MQTT主題發(fā)布下行控制指令ESP8266訂閱相關(guān)主題后解析JSON把控制指令通過(guò)串口轉(zhuǎn)發(fā)給STM32。5.4 斷線重連與異常恢復(fù)WiFi斷線重連算是我這個(gè)項(xiàng)目里耗時(shí)最長(zhǎng)的一個(gè)調(diào)試點(diǎn)?，F(xiàn)象是ESP8266偶爾斷開(kāi)連接而且不會(huì)自動(dòng)恢復(fù)整個(gè)系統(tǒng)失聯(lián)。排查后發(fā)現(xiàn)是和路由器之間長(zhǎng)時(shí)間空閑連接被踢下線TCP/MQTT的那個(gè)底層鏈路靜默時(shí)間超過(guò)了路由器老化時(shí)間。加心跳后問(wèn)題解決但還不夠徹底——ESP8266在處理某些AT指令時(shí)如果返回ERROR控制邏輯可能陷入死循環(huán)。我踩過(guò)一個(gè)具體例子循環(huán)里執(zhí)行ATCIPSTATUS檢測(cè)連接狀態(tài)如果返回ERROR而不是CIPSTATUS...解析函數(shù)會(huì)一直等待而卡死。最終方案是把ESP8266狀態(tài)檢測(cè)改成超時(shí)機(jī)制任何一條指令發(fā)送后如果沒(méi)有在2秒內(nèi)收到正常的OK或\r\n就認(rèn)為通信異常重新初始化整個(gè)WiFi模塊。剛開(kāi)始以為這會(huì)讓系統(tǒng)頻繁重啟實(shí)際上線后運(yùn)行穩(wěn)定很少觸發(fā)。關(guān)于STM32 巴法云esp8266 接OneNet這類搜索熱詞其實(shí)都是同一件事的不同云平臺(tái)實(shí)現(xiàn)方式——核心就是MQTT協(xié)議換成哪個(gè)平臺(tái)都是改broker地址和主題而已。6. 完整代碼框架與關(guān)鍵實(shí)現(xiàn)片段6.1 主函數(shù)與系統(tǒng)運(yùn)行框架主函數(shù)采用無(wú)RTOS的前后臺(tái)結(jié)構(gòu)。主循環(huán)輪詢各模塊狀態(tài)定時(shí)器中斷處理時(shí)間基準(zhǔn)。int main(void) { SystemClock_Config(); MX_GPIO_Init(); MX_ADC1_Init(); MX_TIM1_Init(); MX_USART1_UART_Init(); MX_USART2_UART_Init(); OLED_Init(); DHT22_Init(); ESP8266_Init(); while (1) { // 主循環(huán)非阻塞輪詢 DHT22_Poll(); // 2s采樣周期內(nèi)讀取溫濕度 DustSensor_Poll(); // 1s采樣周期內(nèi)讀取粉塵 ControlLogic_Run(); // 環(huán)境狀態(tài)機(jī) OLED_Update(); // 顯示刷新 ESP8266_Handle(); // 網(wǎng)絡(luò)通信處理 delay_ms(100); } }關(guān)鍵設(shè)計(jì)在于所有操作都不阻塞。DHT22讀取雖然有時(shí)序要求但我在主循環(huán)里用狀態(tài)機(jī)控制它在等待2s→發(fā)起讀取→等待響應(yīng)→讀取數(shù)據(jù)→校驗(yàn)各環(huán)節(jié)切換而不是在while循環(huán)里死等。這樣做的好處是ESP8266串口數(shù)據(jù)到來(lái)時(shí)主控不會(huì)被DHT22卡住而錯(cuò)過(guò)處理。6.2 DHT22讀取與校驗(yàn)DHT22讀取的核心代碼框架如下uint8_t DHT22_ReadData(float* temperature, float* humidity) { uint8_t data[5] {0}; // 主機(jī)拉低總線 1ms 作為起始信號(hào) DHT22_SetPinOutput(); DHT22_WriteLow(); delay_ms(1); DHT22_WriteHigh(); DHT22_SetPinInput(); // 等待DHT22拉低響應(yīng)信號(hào) uint32_t timeout 100; while (DHT22_ReadPin() 1 timeout--) delay_us(1); // 等待DHT22拉高 timeout 200; while (DHT22_ReadPin() 0 timeout--) delay_us(1); // 讀取40位數(shù)據(jù) for (uint8_t bitCount 0; bitCount 40; bitCount) { timeout 100; while (DHT22_ReadPin() 0 timeout--) delay_us(1); // 每bit起始低電平 delay_us(32); // 跳過(guò)前32us if (DHT22_ReadPin() 1) data[bitCount / 8] | (0x80 (bitCount % 8)); timeout 100; while (DHT22_ReadPin() 1 timeout--) delay_us(1); } // 校驗(yàn) uint8_t checkSum data[0] data[1] data[2] data[3]; if (checkSum ! data[4]) return 0; uint16_t humRaw (data[0] 8) | data[1]; uint16_t tempRaw (data[2] 8) | data[3]; // 負(fù)數(shù)判斷最高位為1 if (tempRaw 0x8000) *temperature (int16_t)(tempRaw 0x7FFF) / 10.0 * (-1); else *temperature (int16_t)(tempRaw 0x7FFF) / 10.0; *humidity humRaw / 10.0; return 1; }讀取時(shí)序里有一個(gè)細(xì)節(jié)的等效處理delay_us(32)后判斷數(shù)據(jù)位的電平通常判斷點(diǎn)是脈沖開(kāi)始后的28~40us。因?yàn)镈HT22的0脈沖寬度是26us左右1脈沖寬度是70us左右在32us處判斷可以清晰區(qū)分。當(dāng)然這里用了循環(huán)等待大幅簡(jiǎn)化實(shí)際項(xiàng)目里用SysTick做us級(jí)延時(shí)。6.3 控制邏輯狀態(tài)機(jī)控制邏輯直接看代碼更清楚typedef enum { FAN_STOPPED, FAN_RUNNING } FanState; typedef enum { DEHUM_STANDBY, // 待機(jī)允許啟動(dòng) DEHUM_RUNNING, // 運(yùn)行中 DEHUM_STOPPING // 停機(jī)等待3分鐘 } DehumidifierState; void ControlLogic_Run(void) { static DehumidifierState dehumState DEHUM_STANDBY; static uint32_t lastSwitchTime 0; // 讀取最新數(shù)據(jù) float temp GetLatestTemperature(); float hum GetLatestHumidity(); float dust GetLatestDustConcentration(); // 風(fēng)機(jī)控制溫濕度綜合判斷 if ((temp 26.0f hum 70.0f) || dust 0.15f) { if (GetFanState() FAN_STOPPED) { SetFanState(FAN_RUNNING); } } else if (temp 24.0f hum 60.0f dust 0.10f) { if (GetFanState() FAN_RUNNING) { SetFanState(FAN_STOPPED); } } // 除濕機(jī)控制帶滯回與壓縮機(jī)保護(hù) switch (dehumState) { case DEHUM_STANDBY: if (hum 65.0f) // 滯回上限 { SetDehumidifier(1); dehumState DEHUM_RUNNING; lastSwitchTime GetSysTick(); } break; case DEHUM_RUNNING: if (hum 55.0f) // 滯回下限 { SetDehumidifier(0); dehumState DEHUM_STOPPING; lastSwitchTime GetSysTick(); } break; case DEHUM_STOPPING: // 等待3分鐘保護(hù)壓縮機(jī) if (GetSysTick() - lastSwitchTime 180000) { dehumState DEHUM_STANDBY; } break; } }這套邏輯跑起來(lái)之后系統(tǒng)不會(huì)因?yàn)?%RH的波動(dòng)來(lái)回折騰繼電器除濕機(jī)每次運(yùn)行周期至少會(huì)持續(xù)一段時(shí)間因?yàn)闈穸葟?5%降到55%通常需要一段時(shí)間壓縮機(jī)得到了充分保護(hù)。實(shí)際操作中我還會(huì)在控制邏輯里加一個(gè)最小運(yùn)行時(shí)間限制——風(fēng)機(jī)啟動(dòng)后至少持續(xù)運(yùn)行5分鐘不管溫度濕度降到多少防止空調(diào)或者風(fēng)機(jī)頻繁啟停造成的能耗浪費(fèi)和機(jī)械損耗。這在倉(cāng)庫(kù)這類有大熱容的環(huán)境中尤其重要因?yàn)榄h(huán)境溫度不會(huì)因?yàn)轱L(fēng)機(jī)開(kāi)1分鐘就立刻降下來(lái)。7. 云端平臺(tái)與App接入實(shí)測(cè)7.1 選型與接入流程云端平臺(tái)選型時(shí)我對(duì)比過(guò)幾種常見(jiàn)方案常見(jiàn)物聯(lián)網(wǎng)平臺(tái)的MQTT接入、自建MQTT broker、私有化服務(wù)器。自建broker在公網(wǎng)環(huán)境下需要一臺(tái)有公網(wǎng)IP的服務(wù)器對(duì)個(gè)人項(xiàng)目來(lái)說(shuō)成本高、維護(hù)麻煩。最終選了常見(jiàn)物聯(lián)網(wǎng)平臺(tái)的MQTT接入方式理由是接入流程標(biāo)準(zhǔn)化設(shè)備端只需配置MQTT地址、端口、clientID平臺(tái)自動(dòng)幫你處理數(shù)據(jù)展示和存儲(chǔ)支持自定義報(bào)警規(guī)則連接平臺(tái)的核心參數(shù)如下MQTT服務(wù)器: broker.xxx.com 端口: 1883 ClientID: 設(shè)備唯一標(biāo)識(shí) Username / Password: 產(chǎn)品密鑰 數(shù)據(jù)上報(bào)Topic: /productKey/deviceName/upload 指令下發(fā)Topic: /productKey/deviceName/down填入上面這些參數(shù)后ESP8266的AT指令序列如下ATMQTTUSERCFG0,1,deviceName,productKey,設(shè)備密鑰,0,0, ATMQTTCONN0,broker.xxx.com,1883,1設(shè)備端接入成功后平臺(tái)端就能看到設(shè)備狀態(tài)在線然后就能配置數(shù)據(jù)流轉(zhuǎn)和顯示。7.2 數(shù)據(jù)上報(bào)與App可視化我用平臺(tái)的網(wǎng)頁(yè)端看板配置了溫度、濕度、粉塵濃度三個(gè)儀表盤設(shè)備數(shù)據(jù)上報(bào)后基本能穩(wěn)定顯示。這里提醒一句平臺(tái)免費(fèi)版的數(shù)據(jù)上報(bào)頻率限制是需要注意的有的限制每秒1條有的限制每分鐘10條。我的系統(tǒng)設(shè)計(jì)每30秒上報(bào)一條數(shù)據(jù)完全足夠。如果你原來(lái)按1秒1條上報(bào)來(lái)做實(shí)時(shí)監(jiān)控免費(fèi)額度很快就燒完了。App端展示我用的是平臺(tái)的官方小程序或者App通過(guò)設(shè)備掃碼綁定后手機(jī)上就能看到實(shí)時(shí)數(shù)據(jù)和歷史曲線。平臺(tái)還支持告警推送我設(shè)置了兩條規(guī)則溫度高于30°C持續(xù)5分鐘 → 微信告警濕度高于80%RH持續(xù)10分鐘 → 微信告警實(shí)際跑起來(lái)這個(gè)功能很實(shí)用。有一次周末倉(cāng)庫(kù)斷電空調(diào)停了溫度很快升高我人在外面就接到了告警及時(shí)找人處理。7.3 本地顯示與告警機(jī)制除了云端現(xiàn)場(chǎng)端的OLED屏幕也在持續(xù)顯示關(guān)鍵數(shù)據(jù)。雖然整個(gè)系統(tǒng)有OLED、云平臺(tái)雙路顯示但告警不要做成只有云端一種。我在現(xiàn)場(chǎng)加了一個(gè)蜂鳴器當(dāng)溫濕度超過(guò)緊急閾值時(shí)本地蜂鳴器也會(huì)響。為什么因?yàn)樵贫烁婢蕾嚲W(wǎng)絡(luò)萬(wàn)一WiFi斷了現(xiàn)場(chǎng)人員必須能第一時(shí)間知道環(huán)境異常人工去處理。OLED顯示的內(nèi)容分兩屏第一屏顯示溫度、濕度、粉塵濃度第二屏顯示風(fēng)機(jī)狀態(tài)、除濕機(jī)狀態(tài)、系統(tǒng)運(yùn)行時(shí)間兩屏之間手動(dòng)切換或者每8秒自動(dòng)切換都行。OLED的刷新不要做太快環(huán)境數(shù)據(jù)本身變化慢1秒刷新一次就足夠了。這里注意I2C OLED的顯示緩沖如果刷新過(guò)于頻繁會(huì)和ESP8266串口傳輸搶占USART資源導(dǎo)致數(shù)據(jù)延遲。8. 部署實(shí)測(cè)與問(wèn)題修復(fù)8.1 部署初期遇到的三類典型問(wèn)題真實(shí)倉(cāng)庫(kù)環(huán)境比實(shí)驗(yàn)室嚴(yán)格得多部署后第一周問(wèn)題集中爆發(fā)歸納為三類問(wèn)題一DHT22數(shù)據(jù)校驗(yàn)頻繁失敗倉(cāng)庫(kù)面積較大、空氣流動(dòng)復(fù)雜DHT22的時(shí)序偶爾會(huì)受到干擾導(dǎo)致校驗(yàn)失敗。剛開(kāi)始我采用失敗3次再報(bào)警的策略但現(xiàn)場(chǎng)基本不會(huì)觸發(fā)報(bào)警而在日志里能看到大概每小時(shí)還會(huì)有幾十次校驗(yàn)失敗。后來(lái)排查發(fā)現(xiàn)是DHT22和STM32之間的線纜過(guò)長(zhǎng)接近3米加上數(shù)據(jù)線上有干擾。解決方法是縮短線纜并把數(shù)據(jù)線改成屏蔽雙絞線屏蔽層單端接地之后校驗(yàn)失敗率大幅下降。問(wèn)題二ESP8266經(jīng)常斷線排查過(guò)程前面提過(guò)最后鎖定兩個(gè)關(guān)鍵點(diǎn)一是路由器閑置老化導(dǎo)致自動(dòng)踢線二是ESP8266供電不穩(wěn)。在倉(cāng)庫(kù)現(xiàn)場(chǎng)3.3V LDO的輸入電源來(lái)自24V DC電源降壓但24V風(fēng)機(jī)啟動(dòng)瞬間電流沖擊很大會(huì)造成瞬間壓降進(jìn)而導(dǎo)致ESP8266復(fù)位。最終解決是給ESP8266單獨(dú)加了一路低紋波3.3V電源并從風(fēng)機(jī)供電回路上單獨(dú)分出一路做了電氣隔離。這個(gè)能在設(shè)計(jì)階段規(guī)避但我開(kāi)始時(shí)確實(shí)沒(méi)想到電機(jī)啟動(dòng)的瞬態(tài)會(huì)拉掛WiFi模塊。問(wèn)題三粉塵傳感器讀數(shù)漂移GP2Y1010AU0F放置一周后零點(diǎn)電壓V_0漂移了大概0.1V導(dǎo)致濃度讀數(shù)偏高。解決方法是增加了每周自動(dòng)歸零校準(zhǔn)機(jī)制——周六凌晨2點(diǎn)系統(tǒng)自動(dòng)運(yùn)行一次時(shí)長(zhǎng)30分鐘的校準(zhǔn)流程強(qiáng)制關(guān)閉風(fēng)機(jī)和門窗在相對(duì)靜止的空氣中測(cè)量10分鐘數(shù)據(jù)取平均作為新的零點(diǎn)電壓。這個(gè)歸零校準(zhǔn)在實(shí)驗(yàn)室里完全沒(méi)必要做但現(xiàn)場(chǎng)環(huán)境灰塵累積、傳感器光路老化都是不可避免的一周做一次能把漂移控制在可接受范圍內(nèi)。8.2 用電安全與防護(hù)設(shè)計(jì)倉(cāng)庫(kù)環(huán)境里還有幾個(gè)實(shí)驗(yàn)室不需要考慮但現(xiàn)場(chǎng)必須處理的問(wèn)題傳感器線纜的機(jī)械防護(hù)倉(cāng)庫(kù)通道會(huì)有叉車和貨物搬運(yùn)線纜如果裸露在地面遲早被壓斷。我把所有傳感器走線都改到了墻面上方沿線采用線槽避免拉扯和碾壓。繼電器輸出端的保險(xiǎn)絲除濕機(jī)和風(fēng)機(jī)雖然是成品但繼電器觸點(diǎn)如果發(fā)生短路或者過(guò)載必須有過(guò)流保護(hù)。繼電器到執(zhí)行器之間加了3A的保險(xiǎn)絲至少能保證故障時(shí)導(dǎo)線不會(huì)起火燒毀。雷擊浪涌和靜電粉塵傳感器在干燥環(huán)境下容易積累靜電靜電放電可能損壞MCU端口。我在傳感器信號(hào)線上加了ESD保護(hù)二極管BAV99并在電源入口用TVS管吸收了線纜感應(yīng)的浪涌。這是很便宜的防護(hù)器件但能省去很多麻煩。8.3 系統(tǒng)穩(wěn)定性驗(yàn)證系統(tǒng)連續(xù)運(yùn)行一周后的穩(wěn)定結(jié)果可以參考下面這組數(shù)據(jù)時(shí)段平均溫度平均濕度平均粉塵風(fēng)機(jī)日啟動(dòng)次數(shù)除濕機(jī)日啟動(dòng)次數(shù)白天24.8°C58.3%RH0.09mg/m38次3次夜間23.2°C61.5%RH0.06mg/m34次4次從數(shù)據(jù)看風(fēng)機(jī)日啟動(dòng)次數(shù)明顯偏高分析后認(rèn)為最主要原因是下午時(shí)段溫度經(jīng)常在26°C臨界值附近波動(dòng)造成頻繁切換。我把滯回上限改為27°C、回差改為3°C之后風(fēng)機(jī)啟動(dòng)頻率下降了一半倉(cāng)庫(kù)內(nèi)溫度波動(dòng)基本上還是控制在2°C以內(nèi)。這套參數(shù)目前已經(jīng)穩(wěn)定運(yùn)行了將近兩個(gè)月沒(méi)有再出現(xiàn)明顯的執(zhí)行機(jī)構(gòu)頻繁啟停問(wèn)題。9. 低成本迭代那些可以繼續(xù)優(yōu)化的方向系統(tǒng)雖然已經(jīng)能跑但距離完整的產(chǎn)品級(jí)方案還有不少差距。如果接下來(lái)繼續(xù)做迭代我建議按優(yōu)先級(jí)關(guān)注下面幾個(gè)方向。升級(jí)傳感器方案DHT22雖然能用但長(zhǎng)期穩(wěn)定性一般。SHT30溫濕度傳感器采用I2C接口精度更高、一致性更好而且有內(nèi)置加熱功能防止冷凝粉塵傳感器可以升級(jí)為激光散射式的PMS5003或PMS7003能直接輸出PM2.5和PM10的濃度數(shù)值單位就是μg/m3不用自己做模擬量標(biāo)定換算可靠性高一個(gè)量級(jí)。這兩個(gè)替換會(huì)讓整個(gè)系統(tǒng)的數(shù)據(jù)可信度大幅提升。增加執(zhí)行機(jī)構(gòu)類型目前系統(tǒng)只有風(fēng)機(jī)和除濕機(jī)兩個(gè)執(zhí)行器。真正的倉(cāng)庫(kù)環(huán)境控制系統(tǒng)往往還需要空調(diào)聯(lián)動(dòng)風(fēng)機(jī)盤管、加濕器冬季干燥環(huán)境、新風(fēng)閥、電加熱器等。每增加一種執(zhí)行機(jī)構(gòu)控制邏輯會(huì)更復(fù)雜但也更貼近真實(shí)產(chǎn)品。同時(shí)可以加一個(gè)風(fēng)閥執(zhí)行器控制新風(fēng)和回風(fēng)的混風(fēng)比例讓通風(fēng)除濕更精細(xì)。引入RTOS如果控制邏輯進(jìn)一步復(fù)雜比如加入多任務(wù)調(diào)度傳感器巡檢、控制計(jì)算、網(wǎng)絡(luò)上報(bào)、人機(jī)交互建議把裸機(jī)前后臺(tái)改成FreeRTOS。STM32F103C8T6跑FreeRTOS毫無(wú)壓力任務(wù)劃分會(huì)更清晰。但這個(gè)過(guò)程本身也有成本如果系統(tǒng)規(guī)模不大裸機(jī)反而更簡(jiǎn)單可靠只是別被這個(gè)建議帶著走。增加本地?cái)?shù)據(jù)存儲(chǔ)云端雖然能存儲(chǔ)數(shù)據(jù)但萬(wàn)一網(wǎng)絡(luò)斷了數(shù)據(jù)就丟了。可以在STM32上掛一個(gè)SPI FlashW25Q64或者用SD卡模塊本地緩存7天數(shù)據(jù)等網(wǎng)絡(luò)恢復(fù)后再批量上報(bào)。這個(gè)對(duì)倉(cāng)庫(kù)管理來(lái)說(shuō)很有價(jià)值尤其是需要追溯環(huán)境歷史的時(shí)候。鋰電池備份供電倉(cāng)庫(kù)斷電時(shí)系統(tǒng)至少應(yīng)該維持傳感器采集和本地顯示斷電告警才能發(fā)揮作用。加一塊鋰電池和充電管理電路讓控制系統(tǒng)在斷電后獨(dú)立支撐4~8小時(shí)然后把斷電事件上報(bào)云端。這個(gè)功能看著簡(jiǎn)單實(shí)際效果和安全意義非常大。就我個(gè)人做這個(gè)項(xiàng)目的體會(huì)倉(cāng)庫(kù)環(huán)境控制系統(tǒng)的難點(diǎn)不在單點(diǎn)功能而在多個(gè)子系統(tǒng)如何協(xié)同配合——傳感器要耐得住現(xiàn)場(chǎng)環(huán)境的干擾控制邏輯要保護(hù)執(zhí)行機(jī)構(gòu)不被頻繁啟停折騰網(wǎng)絡(luò)層要能自治恢復(fù)云端只是一個(gè)遙控中心而不該成為系統(tǒng)的心臟。把這些關(guān)系理順了這套東西在倉(cāng)庫(kù)現(xiàn)場(chǎng)跑起來(lái)才能真正讓人省心。最后再分享一個(gè)調(diào)試階段的技巧所有傳感器和執(zhí)行器都先做成獨(dú)立模塊單獨(dú)調(diào)通再接總線聯(lián)調(diào)。DHT22單獨(dú)測(cè)試過(guò)、粉塵傳感器單獨(dú)讀過(guò)電壓值、繼電器單獨(dú)測(cè)過(guò)吸合釋放再接STM32系統(tǒng)聯(lián)調(diào)。否則一旦系統(tǒng)連起來(lái)出問(wèn)題你要在傳感器、接線、代碼、邏輯之間來(lái)回排查效率極低。我當(dāng)年從整體聯(lián)調(diào)切換到模塊級(jí)調(diào)試之后項(xiàng)目推進(jìn)速度快了很多倍這個(gè)習(xí)慣我現(xiàn)在做任何嵌入式項(xiàng)目都還保留著。 倉(cāng)庫(kù)環(huán)境控制系統(tǒng)：STM32+ESP8266實(shí)現(xiàn)溫濕度粉塵監(jiān)測(cè)與控制
1. 倉(cāng)庫(kù)環(huán)境控制先想清楚要控什么做倉(cāng)庫(kù)環(huán)境控制系統(tǒng)第一反應(yīng)往往是STM32 傳感器 執(zhí)行機(jī)構(gòu)網(wǎng)上類似的畢業(yè)設(shè)計(jì)和工程案例一抓一大把。但真把這套系統(tǒng)做出來(lái)、放到真實(shí)倉(cāng)庫(kù)里跑你會(huì)發(fā)現(xiàn)最難的從來(lái)不是代碼而是你壓根沒(méi)想清楚控制這兩個(gè)字意味著什么。我這邊項(xiàng)目的初始需求是溫濕度監(jiān)測(cè)、粉塵濃度監(jiān)測(cè)、自動(dòng)通風(fēng)除濕數(shù)據(jù)還要通過(guò)ESP8266上傳云端。對(duì)應(yīng)的使用場(chǎng)景是電子元器件倉(cāng)庫(kù)——這類倉(cāng)庫(kù)對(duì)溫濕度和潔凈度都有明確要求尤其是防潮防靜電環(huán)境失控造成的損失遠(yuǎn)比想象中大。系統(tǒng)最終要做到的效果是現(xiàn)場(chǎng)有一套本地閉環(huán)控制邏輯能獨(dú)立工作不依賴網(wǎng)絡(luò)同時(shí)數(shù)據(jù)要上云方便遠(yuǎn)程查看和告警。拆解下來(lái)整個(gè)系統(tǒng)其實(shí)分四個(gè)層次感知層溫濕度傳感器、粉塵傳感器負(fù)責(zé)采集環(huán)境數(shù)據(jù)控制層STM32做主控MCU跑控制邏輯決定要不要通風(fēng)、要不要除濕執(zhí)行層風(fēng)機(jī)、除濕機(jī)、加熱器、繼電器組實(shí)施具體動(dòng)作網(wǎng)絡(luò)層ESP8266做主控的通信外腦把數(shù)據(jù)推到云端很多新手項(xiàng)目做到最后變成傳感器讀數(shù)在OLED上滾動(dòng)播放本質(zhì)上就是只做了感知層和顯示層控制邏輯要么沒(méi)寫要么寫成了定時(shí)開(kāi)關(guān)——那不能叫環(huán)境控制系統(tǒng)那叫電子溫度計(jì)。這個(gè)項(xiàng)目里我做了一個(gè)關(guān)鍵決策M(jìn)CU選STM32F103C8T6通信模塊選ESP8266-01S本地控制邏輯全跑在STM32中ESP8266只負(fù)責(zé)和云端打交道。為什么不直接讓ESP8266干所有事因?yàn)镋SP8266雖然便宜、能聯(lián)網(wǎng)但它的GPIO和實(shí)時(shí)性做這種多傳感器采集控制閉環(huán)并不舒服尤其是風(fēng)扇、除濕機(jī)這類執(zhí)行機(jī)構(gòu)的PWM控制和邏輯調(diào)度還是STM32的強(qiáng)項(xiàng)。兩者各干各擅長(zhǎng)的這是整體架構(gòu)的核心思路。2. 硬件選型與接線這里最容易返工2.1 主控與傳感器的搭配邏輯主控選了STM32F103C8T6也就是俗稱的藍(lán)丸板。它便宜、資料多、引腳夠用做這種環(huán)境控制項(xiàng)目綽綽有余。你也許會(huì)在網(wǎng)上看到有人用STM32F407甚至F429做同樣的功能說(shuō)實(shí)話沒(méi)必要性能嚴(yán)重過(guò)剩功耗還高。溫濕度傳感器是DHT22也叫AM2302測(cè)量范圍-40~80°C、0~100%RH精度±0.5°C和±2%RH比DHT11靠譜太多。DHT11的精度只有±2°C和±5%RH在倉(cāng)庫(kù)環(huán)境控制這種場(chǎng)景下誤差大了直接影響控制邏輯的判定——比如實(shí)際濕度80%RHDHT11測(cè)出來(lái)75%RH除濕機(jī)永遠(yuǎn)啟動(dòng)不了倉(cāng)庫(kù)里的元器件一樣受潮。所以別省那幾塊錢DHT22是底線。粉塵傳感器選了GP2Y1010AU0F夏普那款經(jīng)典的紅外粉塵傳感器。它能測(cè)PM2.5級(jí)別的懸浮顆粒物原理是紅外LED照射空氣中的顆粒物光接收管檢測(cè)散射光強(qiáng)度輸出一個(gè)與粉塵濃度呈正相關(guān)的模擬電壓。輸出是模擬量直接用STM32的ADC采集就行。它的靈敏度用靈敏度系數(shù)換算具體公式后面細(xì)說(shuō)。2.2 執(zhí)行機(jī)構(gòu)與驅(qū)動(dòng)方案執(zhí)行機(jī)構(gòu)里最核心的是通風(fēng)和除濕。通風(fēng)用的是24V軸流風(fēng)機(jī)倉(cāng)庫(kù)面積不大時(shí)這種風(fēng)機(jī)足夠換氣除濕機(jī)是成品獨(dú)立除濕機(jī)但它本身不帶干接點(diǎn)控制接口所以我用了繼電器組來(lái)做開(kāi)關(guān)控制。注意成品除濕機(jī)改裝控制時(shí)一定要看說(shuō)明書(shū)確認(rèn)它支持通過(guò)斷電重啟來(lái)控制啟停——有的除濕機(jī)斷電重啟后需要手動(dòng)再按一次開(kāi)關(guān)那個(gè)沒(méi)法用繼電器直接控制得自己改電路或者選帶遙控器的型號(hào)。繼電器選的是5V供電的2路光耦隔離繼電器模塊低電平觸發(fā)。為什么強(qiáng)調(diào)光耦隔離因?yàn)槔^電器后面接的是24V風(fēng)機(jī)、220V除濕機(jī)如果共地串?dāng)_STM32的3.3V系統(tǒng)很容易被打掛。光耦把控制側(cè)和執(zhí)行側(cè)隔離了安全系數(shù)高很多。這個(gè)細(xì)節(jié)在實(shí)驗(yàn)室玩玩不覺(jué)得真放到倉(cāng)庫(kù)現(xiàn)場(chǎng)就知道有多大價(jià)值了。另外還加了一路PWM控制的排風(fēng)扇調(diào)速——不是簡(jiǎn)單的開(kāi)/關(guān)而是根據(jù)溫濕度偏差大小動(dòng)態(tài)調(diào)速。這需要一個(gè)MOS管驅(qū)動(dòng)電路IRLZ44N這種邏輯電平MOS管正好合適可以用STM32的TIM輸出PWM直接控制。2.3 接線表的詳細(xì)說(shuō)明接線是整個(gè)系統(tǒng)最繁瑣但最不能出錯(cuò)的部分。我按功能模塊整理了接線表你照著接基本不會(huì)亂模塊信號(hào)線STM32引腳備注DHT22DATAPA6需外接4.7kΩ上拉GP2Y1010AU0FV-LED、LED-GND3.3V、GND脈沖驅(qū)動(dòng)由PWM控制GP2Y1010AU0FVOPA1ADC1模擬輸出繼電器模塊 IN1PA0低電平觸發(fā)控制除濕機(jī)繼電器模塊 IN2PA1低電平觸發(fā)控制風(fēng)機(jī)開(kāi)關(guān)MOS管柵極PA2PWM輸出風(fēng)機(jī)調(diào)速ESP8266-01S TXPA9USART1_TX交叉連接3.3V邏輯兼容ESP8266-01S RXPA10USART1_RX交叉連接3.3V邏輯兼容OLEDI2CPB8、PB9SCL、SDA0.96寸12864有一個(gè)細(xì)節(jié)特別容易被忽略GP2Y1010AU0F的LED驅(qū)動(dòng)不是直接給高低電平的而是需要一個(gè)周期10ms、脈沖寬度0.32ms的脈沖信號(hào)采樣點(diǎn)要放在脈沖開(kāi)始后0.28ms處。如果直接用GPIO高低電平驅(qū)動(dòng)LED輸出信號(hào)會(huì)完全不正常。我在這個(gè)項(xiàng)目里用TIM1的PWM輸出來(lái)生成這個(gè)脈沖波形然后ADC采樣時(shí)機(jī)對(duì)齊到脈沖高電平的中段這樣讀到的電壓才穩(wěn)定。關(guān)于ESP8266和STM32的引腳對(duì)接網(wǎng)上有大量自鎖接法的討論。ESP8266-01S的GPIO0和GPIO2必須保持高電平才能正常啟動(dòng)運(yùn)行而它的TX/RX是3.3V邏輯和STM32的3.3V系統(tǒng)電平正好匹配不需要額外的電平轉(zhuǎn)換電路。不過(guò)ESP8266上電瞬間的電流峰值比較大有時(shí)候會(huì)拉低3.3V電壓導(dǎo)致它啟動(dòng)失敗這個(gè)坑我在調(diào)試時(shí)踩過(guò)解決方案是ESP8266的供電獨(dú)立用AMS1117-3.3V不要和STM32共用同一個(gè)LDO輸出——具體做法后面挑重點(diǎn)詳細(xì)說(shuō)。3. 傳感器數(shù)據(jù)采集與處理數(shù)學(xué)比代碼更重要3.1 DHT22的時(shí)序與校驗(yàn)DHT22用的是單總線協(xié)議數(shù)據(jù)線只有一根所有通信靠時(shí)序控制。它的采集過(guò)程需要經(jīng)過(guò)主機(jī)發(fā)送起始信號(hào) → DHT22響應(yīng) → 40位數(shù)據(jù)輸出三個(gè)階段。網(wǎng)上有現(xiàn)成的庫(kù)函數(shù)但我建議你還是理解一下時(shí)序本質(zhì)——因?yàn)楹芏鄠}(cāng)庫(kù)環(huán)境下線路長(zhǎng)了、干擾大了DHT22的時(shí)序會(huì)漂移靠庫(kù)函數(shù)里的死循環(huán)等待經(jīng)常讀到全0或校驗(yàn)失敗。DHT22的40位數(shù)據(jù)由16位濕度、16位溫度、8位校驗(yàn)和組成。其中溫度最高位為1時(shí)表示零下溫度用補(bǔ)碼表示。比如溫度是負(fù)數(shù)直接按無(wú)符號(hào)數(shù)解析會(huì)解析出一個(gè)很大的錯(cuò)誤值這點(diǎn)在冬天北方倉(cāng)庫(kù)特別容易踩坑。校驗(yàn)方式是前32位數(shù)據(jù)之和的低8位等于校驗(yàn)和不相等直接丟棄本次數(shù)據(jù)重新采樣。我在讀取DHT22時(shí)做了三件事連續(xù)讀取失敗3次才報(bào)警避免偶發(fā)錯(cuò)誤觸發(fā)誤告警限幅濾波如果溫度突變超過(guò)5°C或濕度突變超過(guò)10%RH認(rèn)為數(shù)據(jù)異常用上一次有效數(shù)據(jù)定時(shí)采樣而非循環(huán)采樣DHT22兩次讀取間隔必須大于2秒否則傳感器自身會(huì)處于忙狀態(tài)返回?cái)?shù)據(jù)不穩(wěn)定好多人的溫濕度顯示跳動(dòng)得很厲害就是沒(méi)有做限幅濾波本質(zhì)是讀取時(shí)序不穩(wěn)定或者傳感器老化后輸出飄了。DHT22采購(gòu)時(shí)也得留個(gè)心眼市面上很多號(hào)稱DHT22的模塊其實(shí)用的是國(guó)產(chǎn)替代芯片雖然兼容但時(shí)間長(zhǎng)了穩(wěn)定性差一些。有條件的話用SHT30或者AHT20這類I2C數(shù)字傳感器效果會(huì)更好——當(dāng)然這是后話。3.2 GP2Y1010AU0F的電壓-濃度換算粉塵傳感器的數(shù)據(jù)處理是另一個(gè)容易翻車的地方。GP2Y1010AU0F的輸出電壓大約在0~3.6V之間對(duì)應(yīng)粉塵濃度大約0~0.5mg/m3但輸出電壓和粉塵濃度不是線性關(guān)系。官方數(shù)據(jù)手冊(cè)給出的關(guān)系近似如下粉塵濃度(mg/m3) ≈ (Vout - 0.6V) × 0.5V對(duì)應(yīng)的濃度系數(shù)實(shí)際工程中更實(shí)用的做法是用標(biāo)定曲線插值但業(yè)余條件下標(biāo)定條件不夠很多人的處理方式是直接用線性公式估濃度(mg/m3) (Vout_voltage - V_0) / K其中V_0是潔凈環(huán)境下的零點(diǎn)電壓一般0.3~0.6V之間不同批次硬件有差異K是靈敏度系數(shù)大約0.15~0.2 V/(mg/m3)。你手里這塊傳感器的V_0和K是多少需要通過(guò)實(shí)測(cè)得到——在潔凈環(huán)境測(cè)一次零點(diǎn)電壓然后在已知濃度的測(cè)試環(huán)境中測(cè)一次電壓兩個(gè)點(diǎn)就能算出K。這在很多教程里被當(dāng)成公式一抄就行但我建議每個(gè)人拿到傳感器后都做一次零點(diǎn)標(biāo)定把V_0記下來(lái)。不同批次、不同模塊之間V_0差異非常大接上去直接套公式的結(jié)果就是把偏置誤差帶進(jìn)了控制邏輯——本來(lái)0.1mg/m3算成0.25mg/m3風(fēng)機(jī)瞎轉(zhuǎn)。ADC采集的時(shí)候我一般開(kāi)12位分辨率參考電壓用內(nèi)部參考2.9VF103剛好多路ADC都支持內(nèi)部參考然后軟件做多次采樣取平均滑動(dòng)濾波。粉塵信號(hào)本身波動(dòng)很大單次采樣數(shù)值跳來(lái)跳去如果不濾波控制邏輯會(huì)反復(fù)啟停風(fēng)機(jī)——這是很多人做完之后發(fā)現(xiàn)風(fēng)機(jī)一會(huì)兒轉(zhuǎn)一會(huì)兒停的根本原因。3.3 ADC與濾波策略的取舍ADC濾波我用了兩種策略的組合中位值濾波連續(xù)采樣11次排序取中間值濾掉意外尖峰滑動(dòng)平均濾波最近5次中位值做平均平滑輸出為什么不用簡(jiǎn)單平均因?yàn)楹?jiǎn)單平均在遇到強(qiáng)干擾尖峰時(shí)一個(gè)異常值能拉偏平均值很多。中位值濾波能徹底剔除毛刺代價(jià)是采樣速度慢一點(diǎn)但環(huán)境控制系統(tǒng)的采樣周期做幾百毫秒毫無(wú)壓力。注意STM32F103的ADC在連續(xù)采樣模式下如果你開(kāi)了DMA循環(huán)要小心數(shù)據(jù)覆蓋問(wèn)題。我最終采用的是定時(shí)器觸發(fā)單次采樣每次取完一組數(shù)據(jù)后處理完再啟動(dòng)下一組邏輯更清晰不容易踩DMA緩沖區(qū)錯(cuò)位的坑。4. 控制邏輯設(shè)計(jì)從讀數(shù)據(jù)到控環(huán)境的質(zhì)變4.1 溫濕度閉環(huán)控制控制邏輯是整個(gè)系統(tǒng)的靈魂。設(shè)計(jì)原則是優(yōu)先本地閉環(huán)云端只是遠(yuǎn)程監(jiān)控和數(shù)據(jù)備份。溫度控制的目標(biāo)區(qū)間我設(shè)在20~26°C。這個(gè)區(qū)間主要是參考電子元器件倉(cāng)庫(kù)的一般要求兼顧春季和秋季不用空調(diào)的自然溫度。當(dāng)溫度高于26°C時(shí)啟動(dòng)風(fēng)機(jī)通風(fēng)低于20°C時(shí)打開(kāi)加熱器如果配置的話。但通風(fēng)的同時(shí)要考慮濕度——外面如果在下雨室外空氣濕度接近100%RH這時(shí)候把外界潮濕空氣抽進(jìn)來(lái)溫度降了濕度卻上去了得不償失。所以控制邏輯必須做成環(huán)境綜合判斷不能只盯單一參數(shù)。典型規(guī)則如下條件動(dòng)作溫度 26°C 且 濕度 70%RH啟動(dòng)風(fēng)機(jī)通風(fēng)降溫溫度 26°C 且 濕度 ≥ 70%RH啟動(dòng)除濕機(jī)暫不通風(fēng)濕度 65%RH啟動(dòng)除濕機(jī) 關(guān)窗模擬濕度 ≥ 80%RH 且持續(xù)10分鐘強(qiáng)制通風(fēng)除濕除濕機(jī)除濕效率有限時(shí)溫度 18°C 且 濕度 70%RH加熱除濕如有加熱器濕度控制我用的是雙閾值滯回比較。比如濕度上限設(shè)為65%RH下限設(shè)為55%RH當(dāng)濕度超過(guò)65%RH時(shí)啟動(dòng)除濕機(jī)當(dāng)濕度降到55%RH以下時(shí)才關(guān)閉除濕機(jī)。為什么用滯回因?yàn)椴挥脺貢?huì)變成超過(guò)65%就啟動(dòng)降到64.9%就關(guān)閉一天之內(nèi)繼電器能咔嗒咔嗒響上百次繼電器壽命很快就磨完了除濕機(jī)壓縮機(jī)頻繁啟停也容易損壞。這個(gè)道理和家里的空調(diào)溫控是一樣的只不過(guò)很多人剛開(kāi)始做系統(tǒng)控制時(shí)根本沒(méi)往這方面想。滯回量一般設(shè)5~10%RH左右比較合理太小沒(méi)效果太大會(huì)導(dǎo)致環(huán)境波動(dòng)大。4.2 粉塵濃度聯(lián)動(dòng)控制粉塵濃度與通風(fēng)的聯(lián)動(dòng)邏輯和溫濕度類似但更簡(jiǎn)單閾值設(shè)為0.15mg/m3超過(guò)就啟動(dòng)風(fēng)機(jī)降到0.10mg/m3以下再停。同樣給了滯回區(qū)0.05mg/m3。但這里有個(gè)容易忽略的點(diǎn)粉塵濃度傳感器的讀數(shù)受空氣流速影響。如果風(fēng)機(jī)排氣口正好對(duì)著傳感器位置讀數(shù)會(huì)明顯偏低因?yàn)闅饬靼丫植繀^(qū)域的粉塵吹走了如果傳感器裝在墻角落氣流不流通讀數(shù)又會(huì)偏高。所以在實(shí)際安裝中傳感器位置要選在倉(cāng)庫(kù)中部、離地面1.5~1.8米左右的位置盡量避開(kāi)直吹氣流。這是純工程經(jīng)驗(yàn)很多教程里不會(huì)提醒。另外粉塵濃度和濕度也有關(guān)系——高濕度環(huán)境下顆粒物吸濕后會(huì)變得更重沉降加快濃度讀數(shù)會(huì)比干燥環(huán)境下偏低。如果要精細(xì)控制可以在高濕度時(shí)段對(duì)粉塵閾值做點(diǎn)補(bǔ)償不過(guò)大多數(shù)倉(cāng)庫(kù)場(chǎng)景沒(méi)必要做這個(gè)先跑起來(lái)再說(shuō)。4.3 定時(shí)調(diào)度與狀態(tài)機(jī)設(shè)計(jì)判斷要不要開(kāi)風(fēng)機(jī)/除濕機(jī)表面看是一個(gè)比較指令但實(shí)際系統(tǒng)里我建議把它設(shè)計(jì)成有限狀態(tài)機(jī)。每個(gè)外設(shè)處在不同狀態(tài)下行為完全不同風(fēng)機(jī)停止 → 啟動(dòng)中 → 運(yùn)行 → 停止中除濕機(jī)停止 → 啟動(dòng)延時(shí) → 運(yùn)行 → 壓縮機(jī)停機(jī)延時(shí) → 停止之所以給除濕機(jī)設(shè)啟動(dòng)延時(shí)和停機(jī)延時(shí)是因?yàn)槌凉駲C(jī)的壓縮機(jī)不能頻繁啟停。從運(yùn)行到停止壓縮機(jī)不能立刻斷電否則制冷劑回流會(huì)產(chǎn)生液擊損壞壓縮機(jī)。標(biāo)準(zhǔn)做法是切斷除濕機(jī)繼電器后至少等待3分鐘再允許重新啟動(dòng)。這一條很多教程都一筆帶過(guò)了實(shí)際是除濕機(jī)控制系統(tǒng)可靠性的關(guān)鍵。你直接用繼電器去控制一臺(tái)壓縮機(jī)類設(shè)備不做停機(jī)延時(shí)可能一個(gè)星期內(nèi)壓縮機(jī)就報(bào)廢了。狀態(tài)機(jī)的實(shí)現(xiàn)用switch-case就夠了不需要引入RTOS。整個(gè)系統(tǒng)的運(yùn)行節(jié)奏大概是每2秒讀一次DHT22每1秒讀一次粉塵傳感器每5秒做一次狀態(tài)判斷和閾值比較任何狀態(tài)切換在OLED上同步顯示這節(jié)奏下來(lái)整個(gè)控制邏輯流暢不卡頓同時(shí)避免了傳感器數(shù)據(jù)的瘋狂抖動(dòng)。5. ESP8266上云本地控制之外的遠(yuǎn)程大腦5.1 為什么要讓ESP8266單獨(dú)跑先說(shuō)說(shuō)我在讓STM32自己帶網(wǎng)絡(luò)和ESP8266獨(dú)立上網(wǎng)之間做的選擇。STM32F103C8T6本身不帶以太網(wǎng)MAC要聯(lián)網(wǎng)就得外掛ENC28J60之類的以太網(wǎng)模塊或者SPI接口的W5500但這些都是有線網(wǎng)絡(luò)方案——在倉(cāng)庫(kù)現(xiàn)場(chǎng)布線麻煩而且W5500的電路復(fù)雜度明顯高于ESP8266。ESP8266自帶WiFi協(xié)議棧一個(gè)串口就能通信從開(kāi)發(fā)效率到功耗都是更好的選擇。更關(guān)鍵的考慮是控制邏輯的獨(dú)立性。如果網(wǎng)絡(luò)功能和控制功能擠在同一個(gè)MCU上一旦WiFi協(xié)議棧出問(wèn)題連接卡死、緩沖區(qū)溢出整個(gè)控制系統(tǒng)就癱瘓了。分開(kāi)之后ESP8266最多是連不上網(wǎng)本地溫濕度監(jiān)控和風(fēng)機(jī)控制不受影響——這個(gè)思路在工業(yè)控制領(lǐng)域叫自治控制簡(jiǎn)單說(shuō)就是本地系統(tǒng)不要依賴外部資源才能保命。5.2 ESP8266的AT指令配置ESP8266-01S出廠默認(rèn)就是AT固件可以直接用串口和STM32通信。8266在項(xiàng)目里當(dāng)一個(gè)串口轉(zhuǎn)WiFi的透明通道來(lái)用。我配置ESP8266的核心指令序列如下AT ATCWMODE1 // 設(shè)置為Station模式連接路由器 ATCWJAPSSID,密碼 // 連接WiFi ATMQTTUSERCFG0,1,客戶端ID,用戶名,密碼,0,0, // MQTT用戶配置 ATMQTTCONN0,IP地址,1883,1 // 連接MQTT服務(wù)器 ATMQTTSUB0,主題/runtime/device/xxx/msg/property/post,1 // 訂閱云端指令關(guān)于AT指令細(xì)節(jié)有一個(gè)特別容易踩的坑ATCWSAP和ATCWJAP的WiFi名稱若包含中文或特殊字符8266會(huì)返回ERROR。很多倉(cāng)庫(kù)現(xiàn)場(chǎng)的WiFi是中文SSID這個(gè)坑會(huì)讓新手卡很久。解決辦法是路由器開(kāi)一個(gè)2.4GHz的英文SSID專門給設(shè)備用注意不要帶空格和$這類特殊符號(hào)。然后是MQTT連接的穩(wěn)定性問(wèn)題。ESP8266的AT固件和MQTT服務(wù)器之間如果長(zhǎng)時(shí)間沒(méi)數(shù)據(jù)交互服務(wù)器會(huì)斷開(kāi)連接8266還渾然不知。解決方法是每30秒發(fā)一個(gè)心跳包ATMQTTPUB0,主題,1,{\status\:\online\},0,0如果連接異常斷開(kāi)STM32檢測(cè)到TCP連接已關(guān)閉之類的返回后要把ESP8266重新初始化順序是ATRST → ATCWMODE → ATCWJAP → ATMQTTCONN。整個(gè)重連過(guò)程要控制好節(jié)奏不要一失敗就瘋狂重試。5.3 數(shù)據(jù)上云協(xié)議的設(shè)計(jì)數(shù)據(jù)上云的格式我用的是JSON字段如下{ deviceId: WH01, temp: 23.5, hum: 58.2, pm25: 0.12, fanStatus: 1, dehumidifierStatus: 0, timestamp: 1699833600 }esp8266 AT指令里發(fā)JSON最大的坑是AT指令本身的長(zhǎng)度限制。經(jīng)典的ESP8266-01S AT固件單條指令長(zhǎng)度默認(rèn)限制為256字節(jié)。我這個(gè)JSON串大概120字節(jié)剛好夠。如果你的數(shù)據(jù)量大比如要傳歷史數(shù)據(jù)或者帶中文備注超過(guò)了長(zhǎng)度限制就必須把數(shù)據(jù)分塊或者改用固件允許的更長(zhǎng)指令比如ATMQTTPUBRAW。關(guān)于云平臺(tái)的選擇我最終用了常見(jiàn)的物聯(lián)網(wǎng)云平臺(tái)MQTT接入方式將數(shù)據(jù)實(shí)時(shí)推送到云端dashboard。有些平臺(tái)還支持在網(wǎng)頁(yè)端直接下發(fā)指令控制風(fēng)機(jī)/除濕機(jī)這個(gè)功能其實(shí)就是向MQTT主題發(fā)布下行控制指令ESP8266訂閱相關(guān)主題后解析JSON把控制指令通過(guò)串口轉(zhuǎn)發(fā)給STM32。5.4 斷線重連與異常恢復(fù)WiFi斷線重連算是我這個(gè)項(xiàng)目里耗時(shí)最長(zhǎng)的一個(gè)調(diào)試點(diǎn)?，F(xiàn)象是ESP8266偶爾斷開(kāi)連接而且不會(huì)自動(dòng)恢復(fù)整個(gè)系統(tǒng)失聯(lián)。排查后發(fā)現(xiàn)是和路由器之間長(zhǎng)時(shí)間空閑連接被踢下線TCP/MQTT的那個(gè)底層鏈路靜默時(shí)間超過(guò)了路由器老化時(shí)間。加心跳后問(wèn)題解決但還不夠徹底——ESP8266在處理某些AT指令時(shí)如果返回ERROR控制邏輯可能陷入死循環(huán)。我踩過(guò)一個(gè)具體例子循環(huán)里執(zhí)行ATCIPSTATUS檢測(cè)連接狀態(tài)如果返回ERROR而不是CIPSTATUS...解析函數(shù)會(huì)一直等待而卡死。最終方案是把ESP8266狀態(tài)檢測(cè)改成超時(shí)機(jī)制任何一條指令發(fā)送后如果沒(méi)有在2秒內(nèi)收到正常的OK或\r\n就認(rèn)為通信異常重新初始化整個(gè)WiFi模塊。剛開(kāi)始以為這會(huì)讓系統(tǒng)頻繁重啟實(shí)際上線后運(yùn)行穩(wěn)定很少觸發(fā)。關(guān)于STM32 巴法云esp8266 接OneNet這類搜索熱詞其實(shí)都是同一件事的不同云平臺(tái)實(shí)現(xiàn)方式——核心就是MQTT協(xié)議換成哪個(gè)平臺(tái)都是改broker地址和主題而已。6. 完整代碼框架與關(guān)鍵實(shí)現(xiàn)片段6.1 主函數(shù)與系統(tǒng)運(yùn)行框架主函數(shù)采用無(wú)RTOS的前后臺(tái)結(jié)構(gòu)。主循環(huán)輪詢各模塊狀態(tài)定時(shí)器中斷處理時(shí)間基準(zhǔn)。int main(void) { SystemClock_Config(); MX_GPIO_Init(); MX_ADC1_Init(); MX_TIM1_Init(); MX_USART1_UART_Init(); MX_USART2_UART_Init(); OLED_Init(); DHT22_Init(); ESP8266_Init(); while (1) { // 主循環(huán)非阻塞輪詢 DHT22_Poll(); // 2s采樣周期內(nèi)讀取溫濕度 DustSensor_Poll(); // 1s采樣周期內(nèi)讀取粉塵 ControlLogic_Run(); // 環(huán)境狀態(tài)機(jī) OLED_Update(); // 顯示刷新 ESP8266_Handle(); // 網(wǎng)絡(luò)通信處理 delay_ms(100); } }關(guān)鍵設(shè)計(jì)在于所有操作都不阻塞。DHT22讀取雖然有時(shí)序要求但我在主循環(huán)里用狀態(tài)機(jī)控制它在等待2s→發(fā)起讀取→等待響應(yīng)→讀取數(shù)據(jù)→校驗(yàn)各環(huán)節(jié)切換而不是在while循環(huán)里死等。這樣做的好處是ESP8266串口數(shù)據(jù)到來(lái)時(shí)主控不會(huì)被DHT22卡住而錯(cuò)過(guò)處理。6.2 DHT22讀取與校驗(yàn)DHT22讀取的核心代碼框架如下uint8_t DHT22_ReadData(float* temperature, float* humidity) { uint8_t data[5] {0}; // 主機(jī)拉低總線 1ms 作為起始信號(hào) DHT22_SetPinOutput(); DHT22_WriteLow(); delay_ms(1); DHT22_WriteHigh(); DHT22_SetPinInput(); // 等待DHT22拉低響應(yīng)信號(hào) uint32_t timeout 100; while (DHT22_ReadPin() 1 timeout--) delay_us(1); // 等待DHT22拉高 timeout 200; while (DHT22_ReadPin() 0 timeout--) delay_us(1); // 讀取40位數(shù)據(jù) for (uint8_t bitCount 0; bitCount 40; bitCount) { timeout 100; while (DHT22_ReadPin() 0 timeout--) delay_us(1); // 每bit起始低電平 delay_us(32); // 跳過(guò)前32us if (DHT22_ReadPin() 1) data[bitCount / 8] | (0x80 (bitCount % 8)); timeout 100; while (DHT22_ReadPin() 1 timeout--) delay_us(1); } // 校驗(yàn) uint8_t checkSum data[0] data[1] data[2] data[3]; if (checkSum ! data[4]) return 0; uint16_t humRaw (data[0] 8) | data[1]; uint16_t tempRaw (data[2] 8) | data[3]; // 負(fù)數(shù)判斷最高位為1 if (tempRaw 0x8000) *temperature (int16_t)(tempRaw 0x7FFF) / 10.0 * (-1); else *temperature (int16_t)(tempRaw 0x7FFF) / 10.0; *humidity humRaw / 10.0; return 1; }讀取時(shí)序里有一個(gè)細(xì)節(jié)的等效處理delay_us(32)后判斷數(shù)據(jù)位的電平通常判斷點(diǎn)是脈沖開(kāi)始后的28~40us。因?yàn)镈HT22的0脈沖寬度是26us左右1脈沖寬度是70us左右在32us處判斷可以清晰區(qū)分。當(dāng)然這里用了循環(huán)等待大幅簡(jiǎn)化實(shí)際項(xiàng)目里用SysTick做us級(jí)延時(shí)。6.3 控制邏輯狀態(tài)機(jī)控制邏輯直接看代碼更清楚typedef enum { FAN_STOPPED, FAN_RUNNING } FanState; typedef enum { DEHUM_STANDBY, // 待機(jī)允許啟動(dòng) DEHUM_RUNNING, // 運(yùn)行中 DEHUM_STOPPING // 停機(jī)等待3分鐘 } DehumidifierState; void ControlLogic_Run(void) { static DehumidifierState dehumState DEHUM_STANDBY; static uint32_t lastSwitchTime 0; // 讀取最新數(shù)據(jù) float temp GetLatestTemperature(); float hum GetLatestHumidity(); float dust GetLatestDustConcentration(); // 風(fēng)機(jī)控制溫濕度綜合判斷 if ((temp 26.0f hum 70.0f) || dust 0.15f) { if (GetFanState() FAN_STOPPED) { SetFanState(FAN_RUNNING); } } else if (temp 24.0f hum 60.0f dust 0.10f) { if (GetFanState() FAN_RUNNING) { SetFanState(FAN_STOPPED); } } // 除濕機(jī)控制帶滯回與壓縮機(jī)保護(hù) switch (dehumState) { case DEHUM_STANDBY: if (hum 65.0f) // 滯回上限 { SetDehumidifier(1); dehumState DEHUM_RUNNING; lastSwitchTime GetSysTick(); } break; case DEHUM_RUNNING: if (hum 55.0f) // 滯回下限 { SetDehumidifier(0); dehumState DEHUM_STOPPING; lastSwitchTime GetSysTick(); } break; case DEHUM_STOPPING: // 等待3分鐘保護(hù)壓縮機(jī) if (GetSysTick() - lastSwitchTime 180000) { dehumState DEHUM_STANDBY; } break; } }這套邏輯跑起來(lái)之后系統(tǒng)不會(huì)因?yàn)?%RH的波動(dòng)來(lái)回折騰繼電器除濕機(jī)每次運(yùn)行周期至少會(huì)持續(xù)一段時(shí)間因?yàn)闈穸葟?5%降到55%通常需要一段時(shí)間壓縮機(jī)得到了充分保護(hù)。實(shí)際操作中我還會(huì)在控制邏輯里加一個(gè)最小運(yùn)行時(shí)間限制——風(fēng)機(jī)啟動(dòng)后至少持續(xù)運(yùn)行5分鐘不管溫度濕度降到多少防止空調(diào)或者風(fēng)機(jī)頻繁啟停造成的能耗浪費(fèi)和機(jī)械損耗。這在倉(cāng)庫(kù)這類有大熱容的環(huán)境中尤其重要因?yàn)榄h(huán)境溫度不會(huì)因?yàn)轱L(fēng)機(jī)開(kāi)1分鐘就立刻降下來(lái)。7. 云端平臺(tái)與App接入實(shí)測(cè)7.1 選型與接入流程云端平臺(tái)選型時(shí)我對(duì)比過(guò)幾種常見(jiàn)方案常見(jiàn)物聯(lián)網(wǎng)平臺(tái)的MQTT接入、自建MQTT broker、私有化服務(wù)器。自建broker在公網(wǎng)環(huán)境下需要一臺(tái)有公網(wǎng)IP的服務(wù)器對(duì)個(gè)人項(xiàng)目來(lái)說(shuō)成本高、維護(hù)麻煩。最終選了常見(jiàn)物聯(lián)網(wǎng)平臺(tái)的MQTT接入方式理由是接入流程標(biāo)準(zhǔn)化設(shè)備端只需配置MQTT地址、端口、clientID平臺(tái)自動(dòng)幫你處理數(shù)據(jù)展示和存儲(chǔ)支持自定義報(bào)警規(guī)則連接平臺(tái)的核心參數(shù)如下MQTT服務(wù)器: broker.xxx.com 端口: 1883 ClientID: 設(shè)備唯一標(biāo)識(shí) Username / Password: 產(chǎn)品密鑰 數(shù)據(jù)上報(bào)Topic: /productKey/deviceName/upload 指令下發(fā)Topic: /productKey/deviceName/down填入上面這些參數(shù)后ESP8266的AT指令序列如下ATMQTTUSERCFG0,1,deviceName,productKey,設(shè)備密鑰,0,0, ATMQTTCONN0,broker.xxx.com,1883,1設(shè)備端接入成功后平臺(tái)端就能看到設(shè)備狀態(tài)在線然后就能配置數(shù)據(jù)流轉(zhuǎn)和顯示。7.2 數(shù)據(jù)上報(bào)與App可視化我用平臺(tái)的網(wǎng)頁(yè)端看板配置了溫度、濕度、粉塵濃度三個(gè)儀表盤設(shè)備數(shù)據(jù)上報(bào)后基本能穩(wěn)定顯示。這里提醒一句平臺(tái)免費(fèi)版的數(shù)據(jù)上報(bào)頻率限制是需要注意的有的限制每秒1條有的限制每分鐘10條。我的系統(tǒng)設(shè)計(jì)每30秒上報(bào)一條數(shù)據(jù)完全足夠。如果你原來(lái)按1秒1條上報(bào)來(lái)做實(shí)時(shí)監(jiān)控免費(fèi)額度很快就燒完了。App端展示我用的是平臺(tái)的官方小程序或者App通過(guò)設(shè)備掃碼綁定后手機(jī)上就能看到實(shí)時(shí)數(shù)據(jù)和歷史曲線。平臺(tái)還支持告警推送我設(shè)置了兩條規(guī)則溫度高于30°C持續(xù)5分鐘 → 微信告警濕度高于80%RH持續(xù)10分鐘 → 微信告警實(shí)際跑起來(lái)這個(gè)功能很實(shí)用。有一次周末倉(cāng)庫(kù)斷電空調(diào)停了溫度很快升高我人在外面就接到了告警及時(shí)找人處理。7.3 本地顯示與告警機(jī)制除了云端現(xiàn)場(chǎng)端的OLED屏幕也在持續(xù)顯示關(guān)鍵數(shù)據(jù)。雖然整個(gè)系統(tǒng)有OLED、云平臺(tái)雙路顯示但告警不要做成只有云端一種。我在現(xiàn)場(chǎng)加了一個(gè)蜂鳴器當(dāng)溫濕度超過(guò)緊急閾值時(shí)本地蜂鳴器也會(huì)響。為什么因?yàn)樵贫烁婢蕾嚲W(wǎng)絡(luò)萬(wàn)一WiFi斷了現(xiàn)場(chǎng)人員必須能第一時(shí)間知道環(huán)境異常人工去處理。OLED顯示的內(nèi)容分兩屏第一屏顯示溫度、濕度、粉塵濃度第二屏顯示風(fēng)機(jī)狀態(tài)、除濕機(jī)狀態(tài)、系統(tǒng)運(yùn)行時(shí)間兩屏之間手動(dòng)切換或者每8秒自動(dòng)切換都行。OLED的刷新不要做太快環(huán)境數(shù)據(jù)本身變化慢1秒刷新一次就足夠了。這里注意I2C OLED的顯示緩沖如果刷新過(guò)于頻繁會(huì)和ESP8266串口傳輸搶占USART資源導(dǎo)致數(shù)據(jù)延遲。8. 部署實(shí)測(cè)與問(wèn)題修復(fù)8.1 部署初期遇到的三類典型問(wèn)題真實(shí)倉(cāng)庫(kù)環(huán)境比實(shí)驗(yàn)室嚴(yán)格得多部署后第一周問(wèn)題集中爆發(fā)歸納為三類問(wèn)題一DHT22數(shù)據(jù)校驗(yàn)頻繁失敗倉(cāng)庫(kù)面積較大、空氣流動(dòng)復(fù)雜DHT22的時(shí)序偶爾會(huì)受到干擾導(dǎo)致校驗(yàn)失敗。剛開(kāi)始我采用失敗3次再報(bào)警的策略但現(xiàn)場(chǎng)基本不會(huì)觸發(fā)報(bào)警而在日志里能看到大概每小時(shí)還會(huì)有幾十次校驗(yàn)失敗。后來(lái)排查發(fā)現(xiàn)是DHT22和STM32之間的線纜過(guò)長(zhǎng)接近3米加上數(shù)據(jù)線上有干擾。解決方法是縮短線纜并把數(shù)據(jù)線改成屏蔽雙絞線屏蔽層單端接地之后校驗(yàn)失敗率大幅下降。問(wèn)題二ESP8266經(jīng)常斷線排查過(guò)程前面提過(guò)最后鎖定兩個(gè)關(guān)鍵點(diǎn)一是路由器閑置老化導(dǎo)致自動(dòng)踢線二是ESP8266供電不穩(wěn)。在倉(cāng)庫(kù)現(xiàn)場(chǎng)3.3V LDO的輸入電源來(lái)自24V DC電源降壓但24V風(fēng)機(jī)啟動(dòng)瞬間電流沖擊很大會(huì)造成瞬間壓降進(jìn)而導(dǎo)致ESP8266復(fù)位。最終解決是給ESP8266單獨(dú)加了一路低紋波3.3V電源并從風(fēng)機(jī)供電回路上單獨(dú)分出一路做了電氣隔離。這個(gè)能在設(shè)計(jì)階段規(guī)避但我開(kāi)始時(shí)確實(shí)沒(méi)想到電機(jī)啟動(dòng)的瞬態(tài)會(huì)拉掛WiFi模塊。問(wèn)題三粉塵傳感器讀數(shù)漂移GP2Y1010AU0F放置一周后零點(diǎn)電壓V_0漂移了大概0.1V導(dǎo)致濃度讀數(shù)偏高。解決方法是增加了每周自動(dòng)歸零校準(zhǔn)機(jī)制——周六凌晨2點(diǎn)系統(tǒng)自動(dòng)運(yùn)行一次時(shí)長(zhǎng)30分鐘的校準(zhǔn)流程強(qiáng)制關(guān)閉風(fēng)機(jī)和門窗在相對(duì)靜止的空氣中測(cè)量10分鐘數(shù)據(jù)取平均作為新的零點(diǎn)電壓。這個(gè)歸零校準(zhǔn)在實(shí)驗(yàn)室里完全沒(méi)必要做但現(xiàn)場(chǎng)環(huán)境灰塵累積、傳感器光路老化都是不可避免的一周做一次能把漂移控制在可接受范圍內(nèi)。8.2 用電安全與防護(hù)設(shè)計(jì)倉(cāng)庫(kù)環(huán)境里還有幾個(gè)實(shí)驗(yàn)室不需要考慮但現(xiàn)場(chǎng)必須處理的問(wèn)題傳感器線纜的機(jī)械防護(hù)倉(cāng)庫(kù)通道會(huì)有叉車和貨物搬運(yùn)線纜如果裸露在地面遲早被壓斷。我把所有傳感器走線都改到了墻面上方沿線采用線槽避免拉扯和碾壓。繼電器輸出端的保險(xiǎn)絲除濕機(jī)和風(fēng)機(jī)雖然是成品但繼電器觸點(diǎn)如果發(fā)生短路或者過(guò)載必須有過(guò)流保護(hù)。繼電器到執(zhí)行器之間加了3A的保險(xiǎn)絲至少能保證故障時(shí)導(dǎo)線不會(huì)起火燒毀。雷擊浪涌和靜電粉塵傳感器在干燥環(huán)境下容易積累靜電靜電放電可能損壞MCU端口。我在傳感器信號(hào)線上加了ESD保護(hù)二極管BAV99并在電源入口用TVS管吸收了線纜感應(yīng)的浪涌。這是很便宜的防護(hù)器件但能省去很多麻煩。8.3 系統(tǒng)穩(wěn)定性驗(yàn)證系統(tǒng)連續(xù)運(yùn)行一周后的穩(wěn)定結(jié)果可以參考下面這組數(shù)據(jù)時(shí)段平均溫度平均濕度平均粉塵風(fēng)機(jī)日啟動(dòng)次數(shù)除濕機(jī)日啟動(dòng)次數(shù)白天24.8°C58.3%RH0.09mg/m38次3次夜間23.2°C61.5%RH0.06mg/m34次4次從數(shù)據(jù)看風(fēng)機(jī)日啟動(dòng)次數(shù)明顯偏高分析后認(rèn)為最主要原因是下午時(shí)段溫度經(jīng)常在26°C臨界值附近波動(dòng)造成頻繁切換。我把滯回上限改為27°C、回差改為3°C之后風(fēng)機(jī)啟動(dòng)頻率下降了一半倉(cāng)庫(kù)內(nèi)溫度波動(dòng)基本上還是控制在2°C以內(nèi)。這套參數(shù)目前已經(jīng)穩(wěn)定運(yùn)行了將近兩個(gè)月沒(méi)有再出現(xiàn)明顯的執(zhí)行機(jī)構(gòu)頻繁啟停問(wèn)題。9. 低成本迭代那些可以繼續(xù)優(yōu)化的方向系統(tǒng)雖然已經(jīng)能跑但距離完整的產(chǎn)品級(jí)方案還有不少差距。如果接下來(lái)繼續(xù)做迭代我建議按優(yōu)先級(jí)關(guān)注下面幾個(gè)方向。升級(jí)傳感器方案DHT22雖然能用但長(zhǎng)期穩(wěn)定性一般。SHT30溫濕度傳感器采用I2C接口精度更高、一致性更好而且有內(nèi)置加熱功能防止冷凝粉塵傳感器可以升級(jí)為激光散射式的PMS5003或PMS7003能直接輸出PM2.5和PM10的濃度數(shù)值單位就是μg/m3不用自己做模擬量標(biāo)定換算可靠性高一個(gè)量級(jí)。這兩個(gè)替換會(huì)讓整個(gè)系統(tǒng)的數(shù)據(jù)可信度大幅提升。增加執(zhí)行機(jī)構(gòu)類型目前系統(tǒng)只有風(fēng)機(jī)和除濕機(jī)兩個(gè)執(zhí)行器。真正的倉(cāng)庫(kù)環(huán)境控制系統(tǒng)往往還需要空調(diào)聯(lián)動(dòng)風(fēng)機(jī)盤管、加濕器冬季干燥環(huán)境、新風(fēng)閥、電加熱器等。每增加一種執(zhí)行機(jī)構(gòu)控制邏輯會(huì)更復(fù)雜但也更貼近真實(shí)產(chǎn)品。同時(shí)可以加一個(gè)風(fēng)閥執(zhí)行器控制新風(fēng)和回風(fēng)的混風(fēng)比例讓通風(fēng)除濕更精細(xì)。引入RTOS如果控制邏輯進(jìn)一步復(fù)雜比如加入多任務(wù)調(diào)度傳感器巡檢、控制計(jì)算、網(wǎng)絡(luò)上報(bào)、人機(jī)交互建議把裸機(jī)前后臺(tái)改成FreeRTOS。STM32F103C8T6跑FreeRTOS毫無(wú)壓力任務(wù)劃分會(huì)更清晰。但這個(gè)過(guò)程本身也有成本如果系統(tǒng)規(guī)模不大裸機(jī)反而更簡(jiǎn)單可靠只是別被這個(gè)建議帶著走。增加本地?cái)?shù)據(jù)存儲(chǔ)云端雖然能存儲(chǔ)數(shù)據(jù)但萬(wàn)一網(wǎng)絡(luò)斷了數(shù)據(jù)就丟了。可以在STM32上掛一個(gè)SPI FlashW25Q64或者用SD卡模塊本地緩存7天數(shù)據(jù)等網(wǎng)絡(luò)恢復(fù)后再批量上報(bào)。這個(gè)對(duì)倉(cāng)庫(kù)管理來(lái)說(shuō)很有價(jià)值尤其是需要追溯環(huán)境歷史的時(shí)候。鋰電池備份供電倉(cāng)庫(kù)斷電時(shí)系統(tǒng)至少應(yīng)該維持傳感器采集和本地顯示斷電告警才能發(fā)揮作用。加一塊鋰電池和充電管理電路讓控制系統(tǒng)在斷電后獨(dú)立支撐4~8小時(shí)然后把斷電事件上報(bào)云端。這個(gè)功能看著簡(jiǎn)單實(shí)際效果和安全意義非常大。就我個(gè)人做這個(gè)項(xiàng)目的體會(huì)倉(cāng)庫(kù)環(huán)境控制系統(tǒng)的難點(diǎn)不在單點(diǎn)功能而在多個(gè)子系統(tǒng)如何協(xié)同配合——傳感器要耐得住現(xiàn)場(chǎng)環(huán)境的干擾控制邏輯要保護(hù)執(zhí)行機(jī)構(gòu)不被頻繁啟停折騰網(wǎng)絡(luò)層要能自治恢復(fù)云端只是一個(gè)遙控中心而不該成為系統(tǒng)的心臟。把這些關(guān)系理順了這套東西在倉(cāng)庫(kù)現(xiàn)場(chǎng)跑起來(lái)才能真正讓人省心。最后再分享一個(gè)調(diào)試階段的技巧所有傳感器和執(zhí)行器都先做成獨(dú)立模塊單獨(dú)調(diào)通再接總線聯(lián)調(diào)。DHT22單獨(dú)測(cè)試過(guò)、粉塵傳感器單獨(dú)讀過(guò)電壓值、繼電器單獨(dú)測(cè)過(guò)吸合釋放再接STM32系統(tǒng)聯(lián)調(diào)。否則一旦系統(tǒng)連起來(lái)出問(wèn)題你要在傳感器、接線、代碼、邏輯之間來(lái)回排查效率極低。我當(dāng)年從整體聯(lián)調(diào)切換到模塊級(jí)調(diào)試之后項(xiàng)目推進(jìn)速度快了很多倍這個(gè)習(xí)慣我現(xiàn)在做任何嵌入式項(xiàng)目都還保留著。