1. 為什么我勸你別一上來(lái)就搞AI先想清楚這幾個(gè)真實(shí)場(chǎng)景去年年初有個(gè)做冷庫(kù)冷鏈的朋友找上我說(shuō)他們的倉(cāng)庫(kù)溫濕度記錄還得靠人工拿著溫濕度計(jì)每天巡兩趟數(shù)據(jù)記在紙質(zhì)表格上等發(fā)現(xiàn)異常的時(shí)候一批貨早就廢了。他說(shuō)想上物聯(lián)網(wǎng)還要上AI讓系統(tǒng)自己會(huì)報(bào)警。我問(wèn)他“你是想要一個(gè)能看實(shí)時(shí)數(shù)據(jù)的平臺(tái)還是想要一個(gè)能在出事前提醒你的系統(tǒng)”他愣了半天說(shuō)“這不都一樣嗎”這就是絕大多數(shù)人一上來(lái)就踩的坑。把物聯(lián)網(wǎng)和AI混為一談結(jié)果要么做了一個(gè)只有數(shù)據(jù)展示的“大屏駕駛艙”看著很酷但沒(méi)什么決策價(jià)值要么買(mǎi)了一套所謂AI預(yù)警方案閾值寫(xiě)死在代碼里溫度超過(guò)30度就報(bào)警這跟用Excel做個(gè)條件格式有什么區(qū)別后來(lái)我們花了兩周時(shí)間從0到1搭了一套溫濕度異常智能預(yù)警系統(tǒng)硬件成本不到500塊核心鏈路就三個(gè)環(huán)節(jié)用MQTT把傳感器數(shù)據(jù)搬到服務(wù)器用機(jī)器學(xué)習(xí)模型學(xué)習(xí)正常狀態(tài)的范圍再通過(guò)滑動(dòng)窗口機(jī)制判斷異常并推送告警。這篇文章把我完整的落地過(guò)程、踩過(guò)的坑、代碼和參數(shù)選擇邏輯都寫(xiě)出來(lái)。想上手做物聯(lián)網(wǎng)AI方向的同學(xué)或者已經(jīng)在做監(jiān)控系統(tǒng)但覺(jué)得閾值報(bào)警不夠聰明的朋友這篇文章可以直接拿來(lái)抄作業(yè)。先說(shuō)結(jié)論這套系統(tǒng)的本質(zhì)不是“預(yù)測(cè)未來(lái)”而是“識(shí)別偏離正常模式的狀態(tài)”。這個(gè)定位想清楚了后面所有技術(shù)選型都會(huì)順理成章。2. MQTT選型背后的硬邏輯不是因?yàn)樗鸲且驗(yàn)樗傅米?.1 傳感器數(shù)據(jù)上云先搞清楚幾個(gè)方案的分水嶺做物聯(lián)網(wǎng)的數(shù)據(jù)傳輸繞不開(kāi)幾個(gè)候選方案HTTP輪詢、TCP長(zhǎng)連接、MQTT、CoAP。我用一個(gè)實(shí)際場(chǎng)景來(lái)對(duì)比你就知道為什么最終選MQTT。假設(shè)你的倉(cāng)庫(kù)里有30個(gè)傳感器節(jié)點(diǎn)每10秒上報(bào)一次溫濕度數(shù)據(jù)。用HTTP方案每個(gè)節(jié)點(diǎn)主動(dòng)POST數(shù)據(jù)到服務(wù)器服務(wù)器需要處理30個(gè)并發(fā)連接而且HTTP是短連接每次都要重新握手報(bào)文頭動(dòng)不動(dòng)幾百字節(jié)。更麻煩的是如果服務(wù)器重啟或者網(wǎng)絡(luò)抖動(dòng)客戶端怎么重連、重連之后數(shù)據(jù)怎么補(bǔ)這些都得自己寫(xiě)。MQTT的做法完全不一樣。它基于發(fā)布/訂閱模型傳感器是發(fā)布者服務(wù)器是訂閱者中間通過(guò)Broker中轉(zhuǎn)。傳感器只負(fù)責(zé)把數(shù)據(jù)扔給Broker根本不關(guān)心誰(shuí)在訂閱、訂閱了幾個(gè)服務(wù)器也只負(fù)責(zé)從Broker拉取自己關(guān)心的主題。兩者完全解耦。用一個(gè)生活化的類(lèi)比HTTP上傳數(shù)據(jù)就像你每次都要親自把快遞送到對(duì)方手里還得敲門(mén)簽收MQTT更像是把包裹投進(jìn)快遞柜快遞柜Broker幫你存著收件人什么時(shí)候來(lái)取都行。2.2 MQTT的三個(gè)核心機(jī)制理解之后配置不會(huì)出錯(cuò)先看QoS服務(wù)質(zhì)量這是新手最容易忽略的。MQTT提供了三個(gè)等級(jí)QoS等級(jí)含義適用場(chǎng)景0最多一次發(fā)完即忘高頻普通數(shù)據(jù)、丟了不心疼的環(huán)境采集1至少一次有ACK確認(rèn)可能重復(fù)需要確認(rèn)但能容忍重復(fù)的控制指令2恰好一次四步握手性能開(kāi)銷(xiāo)大計(jì)費(fèi)、訂單等絕對(duì)不允許重復(fù)的消息溫濕度采集我建議用QoS 0就夠了。原因很簡(jiǎn)單傳感器每10秒上報(bào)一次丟一兩條數(shù)據(jù)根本不影響整體判斷而QoS 1和2握手確認(rèn)的額外開(kāi)銷(xiāo)在小設(shè)備上會(huì)明顯增加功耗和延遲。那什么時(shí)候需要QoS 1比如你的系統(tǒng)里有個(gè)閥門(mén)控制指令這種命令必須確保送達(dá)重復(fù)一次問(wèn)題也不大。QoS 2在物聯(lián)網(wǎng)數(shù)據(jù)采集場(chǎng)景里說(shuō)實(shí)話用得很少除非涉及資金交易或者法律證據(jù)。然后是遺囑消息Last Will and Testament。我上線的第一周就遇到過(guò)一個(gè)問(wèn)題某個(gè)傳感器節(jié)點(diǎn)因?yàn)殡娏亢谋M突然離線服務(wù)器端完全不知道還以為這個(gè)區(qū)域的溫濕度一直正常。直到巡檢才發(fā)現(xiàn)那間庫(kù)房已經(jīng)失溫兩個(gè)小時(shí)了。用了遺囑消息之后每個(gè)傳感器上線時(shí)先給Broker報(bào)一個(gè)遺囑“如果發(fā)現(xiàn)我掉線了請(qǐng)往alert/offline這個(gè)主題發(fā)一條消息”。Broker檢測(cè)不到心跳時(shí)就會(huì)代為發(fā)布這條消息服務(wù)器收到之后就知道哪個(gè)節(jié)點(diǎn)掉線了就能觸發(fā)運(yùn)維提醒。這個(gè)機(jī)制在同類(lèi)方案比如裸TCP心跳檢測(cè)里實(shí)現(xiàn)起來(lái)要麻煩得多。最后是保留消息Retained Message。新訂閱者上線時(shí)Broker會(huì)把指定主題的最后一條保留消息推送給它。這個(gè)在系統(tǒng)重啟的場(chǎng)景下特別好用——服務(wù)器重啟后不用等傳感器下一次上報(bào)就能立刻知道每個(gè)節(jié)點(diǎn)的最新?tīng)顟B(tài)。2.3 Broker怎么選Mosquitto、EMQX還是云上托管Broker是MQTT架構(gòu)里的中轉(zhuǎn)站選型直接決定系統(tǒng)的穩(wěn)定性和開(kāi)發(fā)效率。我分別試過(guò)三種方案說(shuō)說(shuō)真實(shí)體驗(yàn)。本地開(kāi)發(fā)調(diào)試用Mosquitto就夠它是Eclipse基金會(huì)開(kāi)源的輕量級(jí)Broker安裝簡(jiǎn)單、配置不多單機(jī)扛幾千個(gè)連接沒(méi)什么問(wèn)題。我的開(kāi)發(fā)環(huán)境就是在Ubuntu上裝了一個(gè)Mosquitto命令就一行sudo apt install mosquitto mosquitto-clients生產(chǎn)環(huán)境想省心、要可視化管理界面推薦EMQX它自帶Dashboard可以直觀看到連接數(shù)、消息吞吐、訂閱關(guān)系還支持集群擴(kuò)展而且有中文文檔。我正式環(huán)境的Broker就是EMQX。如果團(tuán)隊(duì)成員不多、不想自己運(yùn)維服務(wù)器資源直接用云廠商提供的MQTT托管服務(wù)也行不過(guò)要做好成本評(píng)估——設(shè)備量越大按連接數(shù)和消息量計(jì)費(fèi)就越貴。2.4 主題設(shè)計(jì)看似隨意實(shí)際決定后端的解析復(fù)雜度MQTT主題采用層級(jí)結(jié)構(gòu)用斜杠分隔這個(gè)設(shè)計(jì)直接影響后端的解析邏輯。我自己第一版的主題設(shè)計(jì)得很亂各個(gè)節(jié)點(diǎn)上報(bào)的主題各寫(xiě)各的后面解析代碼寫(xiě)成了意大利面。后來(lái)重構(gòu)成了統(tǒng)一格式factory/area01/device001/env/temperature factory/area01/device001/env/humidity這種設(shè)計(jì)的好處是服務(wù)器和客戶端都可以用通配符訂閱。比如我想知道1號(hào)區(qū)域所有設(shè)備的溫度數(shù)據(jù)只需要訂閱factory/area01//env/temperature想知道所有設(shè)備的全部數(shù)據(jù)訂閱factory/#就行。主題層級(jí)的設(shè)計(jì)原則是第一層放租戶或項(xiàng)目第二層放區(qū)域第三層放設(shè)備ID后面放數(shù)據(jù)類(lèi)型。千萬(wàn)別把上報(bào)時(shí)間戳塞進(jìn)主題里那應(yīng)該放到消息體里。3. 數(shù)據(jù)采集鏈路搭建從傳感器到服務(wù)器每一步都有坑3.1 硬件端選型與接線ESP32幾乎是新手最優(yōu)解設(shè)備端我選了ESP32開(kāi)發(fā)板加DHT22溫濕度傳感器。選ESP32的原因很簡(jiǎn)單自帶WiFi模塊不用額外買(mǎi)通信板價(jià)格便宜Arduino生態(tài)成熟寫(xiě)代碼像寫(xiě)Python一樣省心。如果只支持2.4G WiFi的環(huán)境里工作ESP32的穩(wěn)定性足夠滿足這類(lèi)場(chǎng)景。DHT22和DHT11的區(qū)別要說(shuō)明一下DHT11精度只有正負(fù)2度和正負(fù)5%濕度DHT22能做到正負(fù)0.5度和正負(fù)2%濕度價(jià)格也就差幾塊錢(qián)。做異常預(yù)警系統(tǒng)數(shù)據(jù)精度直接影響模型判斷直接上DHT22。接線部分沒(méi)什么好說(shuō)的VCC接3.3VGND接GNDDATA接GPIO4。就三個(gè)引腳照著接就行。3.2 代碼里最容易翻車(chē)的三個(gè)地方第一個(gè)坑是DHT庫(kù)讀數(shù)據(jù)太頻繁會(huì)報(bào)錯(cuò)。DHT22官方手冊(cè)建議采樣間隔至少2秒你如果設(shè)置每500毫秒讀一次大概率拿到NaN。我代碼里設(shè)置了10秒上報(bào)一次每次讀取前判斷一下是否成功失敗就跳過(guò)這一輪等下一輪再試。第二個(gè)坑是WiFi重連邏輯?，F(xiàn)實(shí)環(huán)境里路由器隨時(shí)可能重啟或者信號(hào)抖動(dòng)ESP32的WiFi連接一旦斷了不會(huì)自動(dòng)恢復(fù)。必須在loop循環(huán)里增加檢測(cè)if (WiFi.status() ! WL_CONNECTED) { reconnectWiFi(); }第三個(gè)坑是JSON序列化庫(kù)的選擇。ESP32上JSON庫(kù)我用的是ArduinoJson但要注意它的版本API差別很大v5和v6的用法完全不同網(wǎng)上很多老教程用的是v6照著寫(xiě)可能編譯報(bào)錯(cuò)。統(tǒng)一用v7API更簡(jiǎn)潔。3.3 上報(bào)頻率和休眠策略不能既要數(shù)據(jù)密又要續(xù)航長(zhǎng)傳感器上報(bào)頻率是系統(tǒng)設(shè)計(jì)里一個(gè)繞不開(kāi)的權(quán)衡。上報(bào)越頻繁異常發(fā)現(xiàn)越及時(shí)但代價(jià)是設(shè)備功耗上升、Broker和存儲(chǔ)的壓力增大。我實(shí)測(cè)過(guò)一個(gè)場(chǎng)景一個(gè)ESP32節(jié)點(diǎn)用3.7V鋰電池供電如果每5秒上報(bào)一次電流平均在80mA左右一塊1500mAh的電池?fù)尾贿^(guò)20小時(shí)。改成每30秒上報(bào)一次期間進(jìn)入深睡眠模式平均電流降到30mA以下續(xù)航能到3天左右。對(duì)于需要長(zhǎng)期運(yùn)行的溫濕度監(jiān)控場(chǎng)景我的建議是如果設(shè)備插電運(yùn)行10秒上報(bào)一次如果電池供電上報(bào)間隔至少拉到30秒以上并開(kāi)啟深睡眠。你的系統(tǒng)是做預(yù)警不是做實(shí)時(shí)控制30秒的延遲對(duì)倉(cāng)庫(kù)、機(jī)房、農(nóng)業(yè)大棚這些場(chǎng)景來(lái)說(shuō)完全能接受。3.4 服務(wù)端訂閱與數(shù)據(jù)入庫(kù)別用關(guān)系型數(shù)據(jù)庫(kù)硬抗高頻寫(xiě)入服務(wù)端我用Python寫(xiě)了一個(gè)MQTT訂閱進(jìn)程專(zhuān)門(mén)監(jiān)聽(tīng)Broker上的溫濕度主題。核心邏輯很簡(jiǎn)單用paho-mqtt庫(kù)訂閱主題收到消息之后解析JSON寫(xiě)入數(shù)據(jù)庫(kù)。存儲(chǔ)選型要注意如果每10秒一條數(shù)據(jù)30個(gè)節(jié)點(diǎn)一天產(chǎn)生約26萬(wàn)條記錄計(jì)算方式30節(jié)點(diǎn)6條/分鐘60分鐘*24小時(shí)259200條用MySQL直接硬扛高頻寫(xiě)入也能扛住但后期查詢會(huì)變慢而且存儲(chǔ)成本高。對(duì)這種時(shí)序型數(shù)據(jù)我用的是InfluxDB它對(duì)時(shí)間序列有壓縮和自動(dòng)清理策略存儲(chǔ)效率比MySQL高很多。InfluxDB的基本概念是measurement類(lèi)似關(guān)系庫(kù)的表、tag索引字段、field數(shù)值字段寫(xiě)入數(shù)據(jù)用的是行協(xié)議curl -XPOST http://localhost:8086/write?dbenv_monitor -u user:pass --data-binary env_sensor,sensor_idesp32_001,temperature25.6,humidity63.2如果是代碼里寫(xiě)用influxdb-client-python庫(kù)更規(guī)范。4. 機(jī)器學(xué)習(xí)模型選型為什么我放棄了深度學(xué)習(xí)選了孤立森林4.1 先說(shuō)清楚溫濕度異常檢測(cè)到底是個(gè)什么問(wèn)題很多人一聽(tīng)“機(jī)器學(xué)習(xí)預(yù)警”第一反應(yīng)就是LSTM、時(shí)序預(yù)測(cè)模型。但仔細(xì)想一下業(yè)務(wù)需求我需要模型預(yù)測(cè)未來(lái)半小時(shí)的溫度是多少嗎其實(shí)不需要。我需要的是——當(dāng)前這個(gè)溫濕度組合在正常情況下應(yīng)該出現(xiàn)嗎這就是一個(gè)典型的異常檢測(cè)問(wèn)題而且是無(wú)監(jiān)督的場(chǎng)景。正常情況下溫濕度會(huì)在一個(gè)區(qū)間內(nèi)波動(dòng)但異?？赡苁峭话l(fā)的尖刺比如門(mén)沒(méi)關(guān)、空調(diào)壞了也可能是緩慢漂移比如制冷劑泄漏、傳感器老化。深度學(xué)習(xí)時(shí)序模型需要大量標(biāo)注數(shù)據(jù)做訓(xùn)練但異常樣本恰恰是最稀缺的冷庫(kù)可能運(yùn)行半年也不會(huì)出一次故障。用稀疏的異常樣本去訓(xùn)練有監(jiān)督模型效果不可能好。所以我的選型方向確定為無(wú)監(jiān)督或半監(jiān)督異常檢測(cè)算法。4.2 三個(gè)候選算法的對(duì)比只看我實(shí)際跑的結(jié)論第一個(gè)是統(tǒng)計(jì)方法3-Sigma邏輯最簡(jiǎn)單計(jì)算歷史數(shù)據(jù)的均值和標(biāo)準(zhǔn)差超出均值正負(fù)3倍標(biāo)準(zhǔn)差的數(shù)據(jù)點(diǎn)就是異常。這個(gè)方法的優(yōu)點(diǎn)是速度快、可解釋性強(qiáng)但前提是數(shù)據(jù)要符合正態(tài)分布而溫濕度數(shù)據(jù)受晝夜和季節(jié)影響往往有周期性波動(dòng)單靠3-Sigma會(huì)把正常的晝夜溫差誤判成異常。第二個(gè)是隔離森林Isolation Forest核心思路很巧妙它不是描述正常樣本長(zhǎng)什么樣而是直接找那些容易“被孤立”的點(diǎn)。算法隨機(jī)切分樣本空間異常點(diǎn)因?yàn)橹車(chē)芏鹊屯袔椎毒秃蛣e人分開(kāi)正常點(diǎn)則需要很多次切分才能分離。這個(gè)算法對(duì)高維數(shù)據(jù)有效而且不需要假設(shè)數(shù)據(jù)分布形態(tài)實(shí)現(xiàn)也很成熟sklearn里直接能用。第三個(gè)是局部異常因子Local Outlier Factor通過(guò)比較每個(gè)點(diǎn)周?chē)芏群袜従又車(chē)芏鹊牟町悂?lái)判斷異常。它的問(wèn)題是計(jì)算復(fù)雜度偏高對(duì)參數(shù)k鄰居個(gè)數(shù)的選擇很敏感調(diào)參成本高。我最終選了隔離森林原因有三個(gè)對(duì)周期性數(shù)據(jù)的適應(yīng)性強(qiáng)訓(xùn)練不需要大量異常樣本sklearn里可以直接調(diào)用而且實(shí)測(cè)效果和穩(wěn)定性都滿足要求。4.3 特征工程比算法重要十倍一開(kāi)始我直接把溫度數(shù)值丟進(jìn)模型訓(xùn)練效果很差異常檢測(cè)準(zhǔn)確率不到60%。后來(lái)才意識(shí)到單點(diǎn)數(shù)值根本不能反映“異?！钡娜?。溫濕度數(shù)據(jù)是有時(shí)間上下文的同一個(gè)溫度在12點(diǎn)和凌晨2點(diǎn)的含義完全不同。所以我在原始數(shù)值之外增加了幾類(lèi)特征這一步直接決定了模型效果時(shí)間特征小時(shí)編碼成環(huán)形特征、星期幾滑動(dòng)窗口統(tǒng)計(jì)特征過(guò)去10分鐘的平均值、標(biāo)準(zhǔn)差、變化率交互特征溫度與濕度的比值或乘積兩者通常呈負(fù)相關(guān)一旦背離很可能是設(shè)備故障例如同一時(shí)刻溫度很高但濕度很低不像正?？照{(diào)房的模式溫度不變但濕度驟升可能是加濕器故障或者水管滲漏。這些交互關(guān)系是單維數(shù)值無(wú)法表達(dá)的?；瑒?dòng)窗口的計(jì)算我推薦用Pandas的rolling函數(shù)import pandas as pd df[temp_avg_10min] df[temperature].rolling(window10, min_periods1).mean() df[temp_std_10min] df[temperature].rolling(window10, min_periods1).std() df[temp_derivative] df[temperature].diff()4.4 模型訓(xùn)練與閾值選擇異常評(píng)分到底怎么用隔離森林的輸出不是簡(jiǎn)單的0/1標(biāo)簽而是一個(gè)異常分?jǐn)?shù)分?jǐn)?shù)越高代表異常的可能性越大。實(shí)際使用時(shí)需要設(shè)定一個(gè)閾值超過(guò)閾值才觸發(fā)告警。閾值怎么定我的做法是拿至少兩周的正常歷史數(shù)據(jù)訓(xùn)練模型然后看所有正常樣本的得分分布把閾值設(shè)定在95分位數(shù)。這樣正常情況下最多只有5%的點(diǎn)會(huì)被誤報(bào)為異常。調(diào)節(jié)這個(gè)分位數(shù)就可以控制系統(tǒng)的敏感度——告警太頻繁就調(diào)高漏報(bào)太多就調(diào)低。訓(xùn)練代碼很簡(jiǎn)潔from sklearn.ensemble import IsolationForest # X_train是經(jīng)過(guò)特征工程后的歷史正常數(shù)據(jù) model IsolationForest( n_estimators200, # 決策樹(shù)數(shù)量 contamination0.05, # 預(yù)期異常比例和閾值分位數(shù)對(duì)應(yīng) max_samplesauto, bootstrapFalse, random_state42 ) model.fit(X_train) # 新數(shù)據(jù)到來(lái)時(shí)predict為-1表示異常1表示正常 pred model.predict(X_new) score model.score_samples(X_new) # 分?jǐn)?shù)越低越異常contamination參數(shù)的直覺(jué)理解模型假設(shè)這堆數(shù)據(jù)里有5%的異常點(diǎn)。如果你知道實(shí)際正常數(shù)據(jù)里可能有1%的偶發(fā)波動(dòng)就設(shè)0.01防止模型把正常的尖峰也當(dāng)成異常學(xué)習(xí)進(jìn)去。4.5 模型更新的避坑經(jīng)驗(yàn)溫濕度有季節(jié)性漂移上線初期用夏季數(shù)據(jù)訓(xùn)練出來(lái)的模型到了秋天明顯誤報(bào)率上升。原因很簡(jiǎn)單溫濕度的正常范圍隨季節(jié)變化而模型只認(rèn)訓(xùn)練時(shí)的分布。解決方案有兩種一種是定時(shí)重訓(xùn)練比如每周日凌晨自動(dòng)用過(guò)去一個(gè)月的數(shù)據(jù)重新訓(xùn)練一次另一種是滑動(dòng)窗口訓(xùn)練每次只取最近N天的數(shù)據(jù)。我用的是定時(shí)重訓(xùn)練同時(shí)保留一份初始數(shù)據(jù)作為基準(zhǔn)防止某一段時(shí)間的數(shù)據(jù)整體漂移導(dǎo)致模型“忘記”正常范圍。補(bǔ)充一個(gè)重要的判斷邏輯模型輸出的是“異常評(píng)分”但最終是否告警需要結(jié)合業(yè)務(wù)規(guī)則做多級(jí)聯(lián)動(dòng)。比如模型評(píng)分連續(xù)3次30秒內(nèi)都超過(guò)閾值才觸發(fā)告警避免單次網(wǎng)絡(luò)抖動(dòng)或傳感器偶發(fā)噪聲導(dǎo)致誤報(bào)。5. 告警聯(lián)動(dòng)與可視化系統(tǒng)能不能用最終看這一層5.1 別讓告警變成“狼來(lái)了”技術(shù)再好如果告警設(shè)計(jì)得不合理運(yùn)維人員遲早會(huì)把它關(guān)掉。我見(jiàn)過(guò)很多系統(tǒng)上線之后告警被晾在一邊的案例原因幾乎都一樣告警太頻繁全是無(wú)效告警。我的告警分級(jí)策略是這樣的等級(jí)觸發(fā)條件通知方式提示級(jí)模型評(píng)分剛超閾值單次出現(xiàn)記錄日志不推送預(yù)警級(jí)連續(xù)3次30秒內(nèi)超過(guò)閾值推送企業(yè)微信/釘釘消息嚴(yán)重級(jí)連續(xù)10次超過(guò)閾值 或 溫濕度超過(guò)設(shè)備允許上限電話語(yǔ)音通知告警消息里必須包含關(guān)鍵上下文信息不能只說(shuō)一句“溫度異?！?。我看到過(guò)的優(yōu)秀告警推送會(huì)帶上設(shè)備ID、當(dāng)前溫度、濕度、該節(jié)點(diǎn)的歷史均值、建議操作。運(yùn)維人員收到消息之后不用再自己去查后臺(tái)處理效率能提高一倍。5.2 告警去重同一個(gè)故障不能轟炸一個(gè)小時(shí)節(jié)點(diǎn)掉線這個(gè)問(wèn)題前面說(shuō)過(guò)如果沒(méi)有去重機(jī)制一個(gè)節(jié)點(diǎn)掉線服務(wù)器收到遺囑消息后如果繼續(xù)以固定頻率推送告警運(yùn)維人員的手機(jī)一個(gè)小時(shí)內(nèi)能收到幾百條消息。我實(shí)現(xiàn)的去重邏輯是“狀態(tài)機(jī)轉(zhuǎn)換”只有當(dāng)節(jié)點(diǎn)狀態(tài)從正常變?yōu)楫惓r(shí)才推送告警后續(xù)如果同一個(gè)異常持續(xù)存在則每30分鐘只有一次匯總提醒帶上“已持續(xù)時(shí)長(zhǎng)”直到節(jié)點(diǎn)狀態(tài)恢復(fù)為正常才推送一條“恢復(fù)通知”。這個(gè)設(shè)計(jì)在實(shí)際運(yùn)維中非常重要。5.3 可視化儀表盤(pán)不要過(guò)度追求“大屏炫酷”告警之外還需要一個(gè)可視化的頁(yè)面讓運(yùn)維人員看到整體狀態(tài)。我用的是Grafana它可以直接對(duì)接InfluxDB配置起來(lái)很快。儀表盤(pán)上我放了三個(gè)核心視圖溫度、濕度的時(shí)間序列折線圖曲線顏色跟隨異常狀態(tài)自動(dòng)變化各區(qū)域節(jié)點(diǎn)的離線狀態(tài)面板離線節(jié)點(diǎn)高亮標(biāo)紅最近24小時(shí)告警事件時(shí)間線Grafana里最有價(jià)值的配置是告警規(guī)則直接在圖表上設(shè)置閾值可以和機(jī)器學(xué)習(xí)模型的判斷互為補(bǔ)充——模型負(fù)責(zé)判斷模式異常固定閾值負(fù)責(zé)兜底比如溫度物理上限是60度超過(guò)這個(gè)值無(wú)論模型怎樣判斷都必須告警。6. 全鏈路聯(lián)調(diào)實(shí)測(cè)一次真實(shí)故障的完整生命周期理論說(shuō)得再多不如看一次完整事件在系統(tǒng)里的流轉(zhuǎn)過(guò)程。我在測(cè)試環(huán)境里模擬了一次“制冷故障導(dǎo)致溫度異常緩慢上升”的事件把全鏈路的環(huán)節(jié)逐一列出來(lái)。14:00:00正常的庫(kù)房溫度在4到6度之間波動(dòng)。異常從14:00開(kāi)始溫度以每5分鐘0.2度的速度緩慢上升。這種變化幅度緩慢固定閾值報(bào)警根本不會(huì)觸發(fā)因?yàn)闇囟热栽凇俺Ｒ?guī)范圍”內(nèi)這就是為什么選擇機(jī)器學(xué)習(xí)模型的原因。14:23:00溫度上升到6.8度雖然還在空調(diào)可接受范圍但隔離森林模型的異常評(píng)分已經(jīng)連續(xù)3次超過(guò)閾值觸發(fā)了“預(yù)警級(jí)”告警告警消息推送到了運(yùn)維人員的企業(yè)微信。14:23:10系統(tǒng)在Grafana儀表盤(pán)上標(biāo)紅顯示溫度曲線。14:38:00溫度突破8度同時(shí)濕度出現(xiàn)明顯下降制冷故障往往伴隨除濕失效模型評(píng)分持續(xù)走高觸發(fā)了“嚴(yán)重級(jí)”電話語(yǔ)音告警。14:45:00運(yùn)維人員到達(dá)現(xiàn)場(chǎng)發(fā)現(xiàn)冷凍機(jī)皮帶斷裂壓縮機(jī)未停機(jī)但制冷效率大幅下降。15:10:00更換皮帶后溫度開(kāi)始回落系統(tǒng)溫度恢復(fù)至正常范圍模型評(píng)分低于閾值推送恢復(fù)通知。整個(gè)過(guò)程中固定閾值報(bào)警直到14:50左右才會(huì)觸發(fā)因?yàn)榈侥菚r(shí)溫度才超過(guò)8度的硬邊界比機(jī)器學(xué)習(xí)模型晚了將近27分鐘。冷庫(kù)里這個(gè)時(shí)間差可能挽救一整車(chē)貨物。這個(gè)實(shí)測(cè)驗(yàn)證了一個(gè)關(guān)鍵結(jié)論固定閾值適合兜底機(jī)器學(xué)習(xí)模型擅長(zhǎng)捕捉微小緩慢的變化模式兩者結(jié)合才是完整的預(yù)警系統(tǒng)。7. 部署一周后我注意到的幾個(gè)細(xì)節(jié)和優(yōu)化方向系統(tǒng)穩(wěn)定運(yùn)行一周之后我調(diào)整了幾個(gè)細(xì)節(jié)這里一并寫(xiě)出來(lái)。一個(gè)是傳感器時(shí)間同步問(wèn)題。ESP32自身的時(shí)鐘走時(shí)不準(zhǔn)一周可能偏差一兩個(gè)小時(shí)。時(shí)間不準(zhǔn)會(huì)影響小時(shí)特征進(jìn)而影響模型判斷。解決辦法是通過(guò)NTP對(duì)時(shí)ESP32代碼里加上configTime(8 * 3600, 0, ntp.aliyun.com, pool.ntp.org);還有一個(gè)是Broker的認(rèn)證配置。如果Broker不設(shè)賬號(hào)密碼或者密碼使用明文傳輸生產(chǎn)環(huán)境是裸奔的。Mosquitto配置里開(kāi)啟密碼認(rèn)證allow_anonymous false password_file /etc/mosquitto/passwd同時(shí)建議給每個(gè)設(shè)備分配獨(dú)立的用戶名這樣即使某個(gè)設(shè)備的憑據(jù)泄露只能影響那一個(gè)節(jié)點(diǎn)不至于整個(gè)系統(tǒng)被入侵。再就是數(shù)據(jù)的保留周期。InfluxDB里設(shè)置自動(dòng)清理策略超過(guò)30天的原始數(shù)據(jù)自動(dòng)刪除只保留聚合后的統(tǒng)計(jì)摘要。不然數(shù)據(jù)量增長(zhǎng)起來(lái)查詢性能和存儲(chǔ)成本都會(huì)快速惡化。后續(xù)的優(yōu)化方向一個(gè)是把規(guī)則引擎加入告警判斷比如結(jié)合日歷信息節(jié)假日與非節(jié)假日的溫控策略不同、生產(chǎn)排班信息做聯(lián)動(dòng)另一個(gè)是邊緣推理把訓(xùn)練好的模型用輕量化方式部署到ESP32上在端側(cè)直接判斷異常只有異常發(fā)生時(shí)數(shù)據(jù)才上報(bào)能大幅降低云端壓力和通信成本。但要注意ESP32的算力有限隔離森林這種樹(shù)模型前端部署還有一段路要走現(xiàn)階段如果設(shè)備數(shù)量不多云端推理的延遲完全可接受。從我自己的體會(huì)來(lái)說(shuō)這套系統(tǒng)最有價(jià)值的地方不在于用上了什么高深的算法而在于把“數(shù)據(jù)采集-傳輸-存儲(chǔ)-分析-告警”這個(gè)閉環(huán)真正跑通了并且通過(guò)特征工程讓一個(gè)很常見(jiàn)的無(wú)監(jiān)督算法在溫濕度監(jiān)控這件事上發(fā)揮出了超出預(yù)期的效果。如果你也想在這個(gè)方向上手不用追逐什么熱門(mén)框架就先從一條傳感器數(shù)據(jù)流開(kāi)始跑通MQTT到機(jī)器學(xué)習(xí)再到告警的完整鏈路再慢慢迭代模型和業(yè)務(wù)的耦合這條路走起來(lái)會(huì)非常扎實(shí)。