做智能井蓋這個項目最初是被一個很笨逼的場景打動的城市里井蓋數(shù)量巨大丟了、被撬、被水沖開、井下氣體超標全靠人工巡查效率低還容易漏。我們團隊用AIR780E Cat.1 4G模塊加微信小程序配合騰訊云MQTT做了一套輕量級智能井蓋監(jiān)測系統(tǒng)。這個連載想完整記錄這套方案從硬件選型、云平臺配置到小程序開發(fā)把每一步的決策原因、踩坑過程和可用代碼都攤開講。如果你正在做類似的物聯(lián)網(wǎng)項目或者剛接觸Cat.1模塊和MQTT這篇可以當作一份直接能抄作業(yè)的參考。這期連載01先把整個系統(tǒng)的骨架搭起來為什么選Cat.1而不是NB-IoT為什么用騰訊云MQTT傳感器和電源怎么設計小程序端如何展示和告警最后是聯(lián)調(diào)階段最常見的幾個坑。后面幾期會深入AT指令、設備接入的具體代碼、小程序完整工程結構。1. 項目整體架構與技術選型為什么是AIR780E小程序騰訊云MQTT1.1 場景里的真實痛點井蓋管理到底難在哪井蓋管理不是“蓋子蓋好就行”這么簡單。城市里路燈井、排水井、燃氣井、通信井分布在主干道、人行道、綠化帶甚至河道邊數(shù)量動輒幾十萬。傳統(tǒng)巡檢是一組人開著車沿路看井蓋有沒有破損、有沒有被偷、井內(nèi)有沒有積水全靠肉眼。暴雨天水位上漲井下管道倒灌井蓋被頂開現(xiàn)場如果沒人及時發(fā)現(xiàn)就是行人和車輛的安全隱患。另一個痛點是“事后追溯難”。井蓋丟失或被非法開啟往往過了很久才發(fā)現(xiàn)等找到現(xiàn)場重要線纜可能已經(jīng)被破壞。如果有一套系統(tǒng)能在井蓋被掀開、傾斜、水淹、氣體異常時幾秒內(nèi)產(chǎn)生告警再聯(lián)動地圖定位就能把問題從“事后處置”變成“事中干預”。還有一個現(xiàn)實約束井蓋分布極廣不能依賴有線供電和有線網(wǎng)絡絕大多數(shù)位置沒有穩(wěn)定的外部電源也沒有Wi-Fi。設備必須靠電池或低功耗策略運行通信網(wǎng)絡必須覆蓋廣、功耗可控、部署簡單。這些約束條件決定了技術選型的大方向。1.2 Cat.1、AIR780E和騰訊云MQTT各自解決什么問題第一版方案考慮過多種通信方式最終選擇了LTE Cat.1。Cat.1是基于4G LTE網(wǎng)絡的一種低速率物聯(lián)網(wǎng)通信標準理論下行速率10Mbps、上行5Mbps實際跑個幾十Kbps就足夠用。它最大的優(yōu)勢是直接復用現(xiàn)有4G基站不用自建網(wǎng)關也基本不存在“信號死角比NB-IoT多”的尷尬。NB-IoT在很多地下場景信號覆蓋確實好但是速率低、時延偏大有些地區(qū)還受運營商頻段和策略影響LoRa需要自建網(wǎng)關井蓋分布廣網(wǎng)關成本一下子上來了。AIR780E是合宙推出的一款Cat.1模塊支持LTE Cat.1 bis尺寸很小LGA封裝內(nèi)置豐富的AT指令和低功耗PSM模式。選它有三個理由一是模塊本身功耗控制得好待機可以到微安級別配合電池供電能跑很久二是開發(fā)方式靈活既可以用AT指令快速調(diào)通網(wǎng)絡和MQTT也可以用Open方式在模塊內(nèi)部跑自己的邏輯適合不同水平的開發(fā)者三是社區(qū)資料和示例代碼多遇到問題基本能搜到解決方案。小程序作為用戶端解決了“要不要單獨做個App”的問題。井蓋巡檢人員、市政管理人員、應急調(diào)度員分布在多個部門讓他們各自安裝一個App光版本更新就夠折騰。微信小程序點開即用掃碼就能看到井蓋狀態(tài)還能接收告警通知學習和維護成本低很多。騰訊云MQTT承擔了設備與云端、設備與小程序之間的消息樞紐。設備端通過MQTT協(xié)議連上騰訊云IoT Explorer上報狀態(tài)和傳感器數(shù)據(jù)小程序端通過云函數(shù)或者WebSocket訂閱需要的主題拿到數(shù)據(jù)后展示在地圖和列表里。選擇騰訊云而不是自建MQTT服務器最直接的原因是省掉了一套要維護的服務器集群同時騰訊云IoT Explorer本身有設備管理、Topic管理、規(guī)則引擎設備數(shù)量上來之后不用自己寫管理后臺。2. 硬件核心拆解AIR780E與傳感器、電源的低功耗設計2.1 AIR780E模塊到底要接哪些東西AIR780E作為主通信模塊硬件上除了模塊本體還需要外圍電路配合。供電是最容易出問題的一環(huán)。模塊的VBAT工作電壓范圍一般在3.4V到4.2V之間典型值是3.8V最大峰值電流可能到2A級別。這個特性決定了不能用普通LDO直接供電LDO在大壓差下發(fā)熱嚴重且?guī)Р粍铀矔r大電流。我實測下來用支持2A以上輸出的DC-DC降壓電路或者直接鋰電池供電再配合大容量鉭電容和瓷片電容做濾波是最穩(wěn)定的方案。SIM卡電路雖然看起來簡單但接觸不良、ESD防護不到位會導致設備頻繁離線。建議使用推入式Micro SIM卡座或Nano SIM卡座卡座旁邊加ESD防護器件數(shù)據(jù)線走線盡量短。AIR780E還支持eSIM方案量產(chǎn)時可以減少卡座成本但調(diào)試階段還是實體SIM卡方便。天線部分不能省。Cat.1模塊需要LTE主天線如果帶定位功能還需要GNSS天線。天線的位置很講究裝在井蓋內(nèi)部金屬腔體里會嚴重屏蔽信號最好把天線延伸到井蓋側面的非金屬區(qū)域或者使用外置天線引出到井口。實測中天線貼在金屬井蓋內(nèi)部時RSRP能差20dBm以上直接導致聯(lián)網(wǎng)失敗。模塊與MCU之間通過UART串口通信標準做法是AT指令。如果需要直接驅動傳感器也可以用模塊的GPIO和ADC不過為了后續(xù)擴展我習慣在AIR780E外面再接一顆低功耗MCU比如STM32L系列或合宙自家的低功耗方案把傳感器采集、數(shù)據(jù)處理、狀態(tài)判斷放在MCU里AIR780E只負責網(wǎng)絡通信和MQTT上報。2.2 井蓋狀態(tài)監(jiān)測到底需要哪些傳感器智能井蓋不是只有一個“開/關”狀態(tài)。實際場景里我們最關心的幾類事件包括井蓋被非法開啟或移位、井內(nèi)水位過高、井下可燃或有毒氣體超標、井蓋發(fā)生小角度傾斜但未完全掀開。對于“井蓋被打開”這種最核心的事件最簡單可靠的方案是干簧管加磁鐵。把磁鐵裝在井蓋邊緣干簧管裝在井座井蓋閉合時磁鐵吸合干簧管井蓋被掀開時干簧管斷開產(chǎn)生中斷信號喚醒設備上報。這種方案零功耗、抗干擾強成本很低。如果還想檢測“傾斜但沒有完全打開”的中間狀態(tài)可以再加一顆三軸加速度計比如MPU6050或更低功耗的LIS3DH。通過計算重力加速度在三軸上的投影判斷井蓋是否傾斜角度閾值可以按場景標定。水浸檢測用的是電極式傳感器兩根電極暴露在井內(nèi)底部水位上升接觸到電極后電阻變化MCU通過ADC采集到電壓跳變。這里要注意電極的防腐蝕處理長期泡在污水里普通銅電極幾個月就會氧化失效建議使用不銹鋼電極并定期校準。氣體檢測要按井的類型區(qū)分。燃氣井和污水井對甲烷、硫化氫比較敏感可選催化燃燒式或電化學式傳感器。這類傳感器的通病是功耗高不能一直通電我通常用MOS管控制供電只在采樣時刻開啟采樣完立即斷電能省掉大量功耗。還有一個傳感器容易被忽略電池電壓檢測。通過MCU的ADC分壓采集電池電壓每次上報時把電量一起發(fā)到云端這樣后臺能看到哪些設備快沒電了安排人員集中更換電池而不是等設備離線才被動響應。2.3 電池壽命怎么估算低功耗策略怎么落地井蓋埋在路邊不能三天兩頭換電池所以功耗是硬指標。AIR780E有PSMPower Saving Mode模式進入PSM后模塊幾乎不耗電但代價是網(wǎng)絡連接會斷開需要喚醒后重新附著。我用的是“事件喚醒周期心跳”雙策略平時MCU和模塊都睡死干簧管或者加速度計發(fā)生中斷時立刻喚醒上報一條告警同時每24小時或者12小時主動喚醒一次上報心跳和電池電量讓云端知道設備還活著。傳感器供電用MOS管控制采樣前才打開。以水浸傳感器為例每次采樣通電500ms采樣完斷電靜態(tài)功耗可以忽略不計。MCU選用低功耗型號休眠時電流控制在10uA以內(nèi)。整機實測下來靜態(tài)電流大約在20uA左右一次完整上報包含入網(wǎng)、建鏈、發(fā)數(shù)據(jù)平均消耗約30mAh如果按一天一次心跳加偶爾告警來算一塊4000mAh的鋰電池理論上可以支撐數(shù)月到一年以上具體要看告警頻率。不過這里有個坑要提醒入網(wǎng)和建立MQTT連接是耗電大戶一次入網(wǎng)可能消耗幾十毫安時的電量。如果設備頻繁掉線重連電池壽命會急劇縮短。所以不要盲目縮短心跳間隔也不要讓設備在信號差的地方反復重試。我后來給代碼加了一個“失敗退避”邏輯連續(xù)N次入網(wǎng)失敗后延長下次嘗試間隔到10分鐘、30分鐘、1小時避免在弱信號區(qū)死循環(huán)耗電。3. 云端鏈路設計騰訊云MQTT與數(shù)據(jù)協(xié)議的完整方案3.1 為什么直接選騰訊云IoT Explorer而不是自建MQTT物聯(lián)網(wǎng)項目一旦設備量超過幾十臺自建MQTT的成本和維護壓力會突然變大。要處理的不僅有服務器本身還有證書管理、設備鑒權、Topic權限控制、離線消息存儲、規(guī)則引擎等。騰訊云IoT Explorer把這些能力以產(chǎn)品化方式提供設備端只要拿到三元組ProductID、DeviceName、DeviceSecret用MQTT協(xié)議接入就能完成認證和通信。另一個加分項是它的騰訊生態(tài)。小程序云開發(fā)、云函數(shù)和移動端SDK都有現(xiàn)成對接省去了“云平臺只提供原始MQTT上層要自己寫一堆膠水代碼”的麻煩。而且騰訊云IoT Explorer有免費額度對于原型驗證和中小規(guī)模項目非常友好具體免費策略以官網(wǎng)最新說明為準。3.2 Topic怎么劃分數(shù)據(jù)格式怎么定Topic設計直接決定后續(xù)的擴展性。我的做法是分三類上行數(shù)據(jù)、下行命令、系統(tǒng)事件。設備上報狀態(tài)數(shù)據(jù)用一個專門的主題所有傳感器數(shù)據(jù)打包成JSON一次上報而不是一個傳感器一個主題。這樣減少網(wǎng)絡交互次數(shù)也方便云端規(guī)則引擎用一條規(guī)則處理。數(shù)據(jù)格式大概是這樣的{ deviceId: cover_001, timestamp: 1717390800, type: report, position: { lng: 116.397, lat: 39.908 }, status: { lidOpen: false, tiltAngle: 3.2, waterLevel: 0, gasPpm: 12 }, battery: 86, signal: 22 }deviceId是業(yè)務編號便于后臺顯示position字段由設備端或云端根據(jù)井蓋編號補充status里每個字段對應一組傳感器的狀態(tài)。這里有一個細節(jié)字段命名盡量統(tǒng)一用駝峰小程序端拿到之后不用做太多轉換。如果是告警事件比如井蓋被打開type字段改成alert同時云端規(guī)則引擎會觸發(fā)告警推送。下行控制用另一個主題比如遠程控制設備重啟、校準傳感器閾值?？刂浦噶钕掳l(fā)后設備端返回執(zhí)行結果格式類似{ deviceId: cover_001, type: response, cmd: restart, result: ok }系統(tǒng)事件主要指設備上下線通知。騰訊云IoT Explorer本身就支持上下線Topic后臺可以訂閱這些事件當設備離線超過閾值時自動生成工單。這部分我建議不要自己造輪子直接使用平臺提供的系統(tǒng)Topic。3.3 設備認證、心跳?；詈碗x線判斷設備認證使用騰訊云IoT Explorer的密鑰認證。設備端需要計算的MQTT三要素是ClientId、Username、Password其中Password是用DeviceSecret對特定字符串做HMAC-SHA256后得到的。直接用官方SDK或者合宙的AT指令固件它會自動計算不需要自己手動實現(xiàn)加密算法。但如果你用的是AT指令手動連接MQTT就需要在代碼或服務端實現(xiàn)一遍簽名算法注意密鑰不要硬編碼明文盡量放在安全存儲區(qū)域。心跳保活對井蓋這種低功耗設備尤其重要。MQTT本身的KeepAlive機制是在連接層發(fā)PINGREQ騰訊云一般要求KeepAlive的間隔在30到120秒之間。但井蓋設備平時處于PSM省電狀態(tài)不可能每30秒發(fā)一次心跳。所以我的方案是設備在線時用MQTT KeepAlive進入PSM前主動發(fā)送一條offline準備消息同時讓平臺基于“最后一次心跳”時間判斷離線。簡單說不要只依賴協(xié)議層心跳要在業(yè)務層設計“狀態(tài)過期時間”。后臺如果超過15分鐘沒有收到某設備任何消息就判定離線。離線判斷的閾值要結合上報策略調(diào)整。如果設備設計成30分鐘上報一次心跳后端15分鐘判定就會誤報。我最終用的是“上報周期乘2加5分鐘”的動態(tài)閾值既不會漏報也不會頻繁誤報。4. 小程序端開發(fā)從地圖展示到告警中心的完整實現(xiàn)4.1 小程序直連MQTT還是通過API轉發(fā)很多人一上來就想著小程序直接通過MQTT over WebSocket連騰訊云這樣消息可以實時到手機。想法沒錯但實際會碰到幾個麻煩一是設備密鑰不應該下發(fā)到小程序端會泄露二是小程序在弱網(wǎng)環(huán)境下長連接不穩(wěn)定一旦斷線重連邏輯沒寫好用戶會一直看到“連接中”三是微信小程序對網(wǎng)絡連接有并發(fā)限制長連接數(shù)量太多會影響其他請求。所以我的架構是“設備上報到云端云端存庫小程序通過云函數(shù)/API讀取同時監(jiān)聽告警事件”。具體路徑是AIR780E通過MQTT上報數(shù)據(jù)騰訊云IoT Explorer規(guī)則引擎把數(shù)據(jù)寫入云開發(fā)數(shù)據(jù)庫小程序通過云函數(shù)查詢數(shù)據(jù)。需要實時告警時小程序端訂閱云開發(fā)數(shù)據(jù)庫的watch事件或者用定時器輪詢最近的告警記錄。這個方案犧牲了一點點實時性但換來的是穩(wěn)定、安全、易維護。4.2 用uni-app開發(fā)小程序導航欄和頁面結構怎么設計開發(fā)小程序我選了uni-app用HBuilderX創(chuàng)建項目。選uni-app的好處是以后如果想出App端代碼可以復用很大一部分不必從頭再來。整個小程序的頁面分成四塊首頁地圖總覽、井蓋列表、告警中心、我的。首頁地圖是核心。用騰訊地圖小程序SDK把井蓋位置渲染成自定義Marker正常狀態(tài)用綠色告警狀態(tài)用紅色。點擊Marker跳轉到井蓋詳情頁。列表頁則按區(qū)域、狀態(tài)篩選項展示井蓋支持搜索井蓋編號。告警中心按時間倒序展示所有告警未讀的加紅點提示。頁面標題這里有個小程序開發(fā)的常見細節(jié)不同井蓋的詳情頁標題如果都叫“井蓋詳情”用戶根本分不清。我在井蓋詳情頁onLoad里拿到設備編號后用uni.setNavigationBarTitle動態(tài)修改標題比如“井蓋詳情市政路12號井”這樣分享到微信群里時別人一眼就能看出是哪個井蓋。如果你用的是微信原生小程序對應的接口是wx.setNavigationBarTitle效果一樣。頂部導航欄高度的問題也值得一提。不同機型狀態(tài)欄高度不一樣有些還帶靈動島如果自定義導航欄需要獲取系統(tǒng)信息里的safe area再把膠囊按鈕的位置考慮進去否則自定義按鈕會被劉海遮擋。我的做法是直接保留微信原生導航欄不再自定義省掉大量適配工作。只有在需要頂部放自定義金額條或掃描入口的頁面才自定義并且用uni.getSystemInfoSync()拿狀態(tài)欄高度去做占位。4.3 告警推送和通知邏輯怎么做告警通知設計了兩個渠道。第一是微信“訂閱消息”用戶主動訂閱一次平臺就能推送一次消息。這個接口的限制是一次訂閱只能推送一條所以我在用戶點擊訂閱時默認讓他訂閱“告警通知”模板每次有新告警通過云函數(shù)調(diào)用subscribeMessage.send發(fā)送。對于市政管理人員這個通知夠用了如果需要多次通知就得引導用戶每次收到后再次訂閱。第二是企業(yè)微信群機器人。井蓋告警很多情況下需要在工作群里同步我在云函數(shù)里加上webhook推送告警產(chǎn)生時往指定的企業(yè)微信群發(fā)一條帶地圖鏈接的消息。這個對現(xiàn)場調(diào)度特別管用因為值班人員通常都盯著工作群。小程序端還需要處理“告警風暴”的問題。如果某個井蓋因為傳感器誤報一分鐘發(fā)10條告警用戶會被打擾瘋掉。我在云端加了一層合并邏輯同一個設備在5分鐘內(nèi)只產(chǎn)生一條告警后續(xù)同類告警只累加次數(shù)不重復推送。設備恢復后再發(fā)送“已恢復”狀態(tài)通知。這需要在規(guī)則引擎或云函數(shù)里做狀態(tài)機判斷不要指望設備端來解決。5. 聯(lián)調(diào)過程中踩過的坑與排查方法實錄5.1 AIR780E注網(wǎng)和數(shù)據(jù)上報失敗先查這4個位置聯(lián)調(diào)第一步是讓模塊能正常入網(wǎng)。用串口把AIR780E連接到電腦發(fā)送AT指令最常用的是ATCGATT? // 查詢是否附著4G網(wǎng)絡 ATCOPS? // 查詢當前運營商 ATCEREG? // 查詢注冊狀態(tài)0或1表示未注冊5表示已注冊 ATCSQ // 查詢信號強度值越大越好如果ATCGATT返回0先看SIM卡是否插好、是否有欠費停機。我遇到過一個很隱蔽的問題SIM卡沒有開通物聯(lián)網(wǎng)卡的專用APN導致附著失敗。合宙模塊一般默認自動選APN但如果失敗可以手動配置ATCGDCONT1,IP,CMNBIOT // 以聯(lián)通物聯(lián)網(wǎng)卡為例接入騰訊云MQTT失敗時首先要檢查MQTT三元組簽名是否和后臺一致。一種常見情況是設備端用了Wi-Fi網(wǎng)絡的時鐘和當前時間不匹配導致HMAC簽名的有效期校驗失敗。AIR780E內(nèi)部沒有RTC電池斷電后時間復位必須在每次上報前通過NTP或基站時間校準。這個問題排查了整整一晚上最后發(fā)現(xiàn)模塊時間停在1970年簽名當然驗不過。如果模塊頻繁重啟多半是供電不夠。你可以在VBAT引腳示波器抓波形正常供電應該在掉電時有平滑下降曲線而瞬時跌落會有明顯毛刺。換大容量電容或調(diào)整DC-DC輸出電壓能解決。還有一點SIM卡座和數(shù)據(jù)線盡量不要飛線連接我用杜邦線連SIM卡時信號稍弱就掉線改成PCB直焊后穩(wěn)定很多。5.2 小程序連接后端和MQTT的典型異常小程序端最常見的坑出現(xiàn)在“不校驗合法域名”和“實際真機請求”之間的差異。開發(fā)工具里勾選“不校驗合法域名”能請求到接口但真機一點就報“request:fail url not in domain list”。解決辦法是在微信公眾平臺后臺配置request合法域名必須是HTTPS且域名備案過。如果你的小程序只是體驗版也要在后臺臨時配置不然真機照樣訪問不了。第二個高頻問題是訂閱消息授權失敗。在開發(fā)者工具里點擊訂閱能彈窗但真機上如果用戶之前拒絕過授權再次調(diào)用subscribeMessage會直接走fail回調(diào)不會彈窗。接口文檔沒有明確說這個邏輯我是踩了坑才發(fā)現(xiàn)的。解決辦法是在頁面里放一個引導按鈕如果用戶拒絕過就跳轉到“設置”頁讓他手動打開訂閱消息權限。如果你堅持在小程序端直連騰訊云MQTT over WebSocket要注意不能用http明文必須用wss并且“socket合法域名”也需要配置。小程序從基礎庫2.x開始WebSocket連接數(shù)量也有限制多個頁面同時連接會被斷開。這再次驗證了我之前說的能走后端API就走后端API長連接這個口子盡量少開。5.3 調(diào)試工具怎么配合用才能快速定位問題我調(diào)試AIR780E用的是合宙的串口調(diào)試軟件輸出AT指令和模塊日志。只要開了Modem日志模塊內(nèi)部的注冊流程、網(wǎng)絡附著狀態(tài)、TCP連接情況都會打出來定位問題非常快。云端的排查用騰訊云IoT Explorer控制臺左側在線調(diào)試里有設備日志能查到設備每一次上行消息如果設備上報了但控制臺沒記錄那問題一定在設備端發(fā)送環(huán)節(jié)。小程序端我用Charles做代理抓包查看云函數(shù)的請求和返回。只要裝上Charles的HTTPS證書就能看到小程序的網(wǎng)絡請求體。注意真機調(diào)試時需要在手機上配置代理并且確保手機和電腦在同一局域網(wǎng)。抓包不是用來做違規(guī)事情而是看接口返回和請求參數(shù)是否正常這個方法在正式開發(fā)調(diào)試里非常常見。聯(lián)調(diào)階段最容易出現(xiàn)“設備上行成功小程序看不到數(shù)據(jù)”的割裂情況。我的排查順序是設備日志確認MQTT發(fā)送成功云端控制臺確認數(shù)據(jù)進入規(guī)則引擎數(shù)據(jù)庫確認數(shù)據(jù)已經(jīng)寫入云函數(shù)確認返回結果最后小程序確認渲染邏輯正確。逐層排查比在一堆日志里瞎猜高效得多。6. 連載01收尾目前跑通的效果和下一期預告6.1 當前原型系統(tǒng)跑通了什么到這期結束我們已經(jīng)有一個能跑的原型井蓋設備通過AIR780E上報狀態(tài)到騰訊云IoT Explorer規(guī)則引擎把數(shù)據(jù)寫入云開發(fā)數(shù)據(jù)庫小程序展示井蓋列表、地圖和告警中心。測試環(huán)境下設備模擬開蓋事件從傳感器動作到小程序告警中心出現(xiàn)記錄實測耗時為1到2秒。調(diào)度群收到企業(yè)微信推送也在同一時間范圍。電池方面用4000mAh鋰電池供電的實驗板在一天3次心跳、偶爾模擬告警的情況下運行兩周電壓下降約6毫伏按這個趨勢估算使用大半年問題不大。當然這還只是原型數(shù)據(jù)真正量產(chǎn)還要做高低溫、振動、防水等可靠性測試。6.2 下一期連載準備深入什么下一期連載02會直接把AIR780E的AT指令流程和騰訊云MQTT的完整接入代碼貼出來包括設備端狀態(tài)機的設計思路、PSM喚醒和心跳上報的具體代碼寫法。如果你正在卡在“模塊能上網(wǎng)但MQTT連不上”或“上報了幾條數(shù)據(jù)就再也連不上”這兩類問題上下一期應該能幫你直接解決。另外我打算在后續(xù)連載里補充一個真實部署案例市區(qū)一條主干道裝了30個井蓋設備的試運行數(shù)據(jù)包括信號覆蓋統(tǒng)計、報警準確率、電池消耗趨勢以及那些在大雨天被水淹沒后依然能上報的設備表現(xiàn)。物聯(lián)網(wǎng)項目只有經(jīng)過真實環(huán)境反復捶打才算真正“能用”。最后分享一個我在實際項目里最深的體會不要一開始就追求把所有功能做完先把“一個井蓋異常打開后從設備到小程序到通知群整條鏈路能不能跑通”跑出來再逐步加智能化。鏈路通了后面所有優(yōu)化才有意義。這個項目當前版本最大的功臣反而是那些不起眼的地方干簧管加磁鐵的開關檢測、失敗退避聯(lián)網(wǎng)策略、告警合并邏輯。這些細節(jié)看著簡單但對系統(tǒng)的穩(wěn)定性影響最大也最值得花時間去打磨。