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