上個月有個朋友拿著一塊開發(fā)板來找我說他要在倉庫里放十幾個溫濕度傳感器把所有數(shù)據(jù)統(tǒng)一匯到一張報表上問我到底該用哪種聯(lián)網(wǎng)方式。這個問題我自己早幾年就糾結(jié)過一輪那時候我面前同時擺著有線、WiFi、蜂窩、LoRa四套資料越看越覺得每一套都有道理結(jié)果方案反復(fù)推翻好幾版最后才明白一個道理不存在最好的聯(lián)網(wǎng)方式只存在最適合現(xiàn)場條件的聯(lián)網(wǎng)方式。這篇內(nèi)容不是給你抄答案而是幫你把選型這件事的底層邏輯理清楚。我會把四種方案放在同一張底層上做橫向?qū)Ρ葍?nèi)容包括硬件成本、功耗賬本、協(xié)議鏈路、部署踩坑最后再用幾個我實際做過的項目復(fù)盤收尾。無論你是用DHT11做宿舍小項目還是用SHT30組一套工業(yè)級監(jiān)測網(wǎng)這篇都能給你一個可直接套用的判斷框架。1. 先回答三個問題再做方案對比很多人一上來就問我有線WiFi蜂窩LoRa哪個好這種問法根本沒法答。因為我連你的現(xiàn)場長什么樣都不知道。同樣是溫濕度傳感器放在機(jī)柜里、大棚里、冷鏈車上答案完全不同。所以做對比之前先逼自己回答三個前置問題。1.1 你打算多久去一次現(xiàn)場這是供電與維護(hù)的邊界這個問題的本質(zhì)是你愿不愿意為這個節(jié)點(diǎn)伺候它。如果你能每周去一次現(xiàn)場那一切都好說——電池沒電了就換網(wǎng)線松了就重新插甚至可以扛著充電寶去續(xù)命。但你如果打算把節(jié)點(diǎn)裝在某個夠不著的地方比如糧倉頂上、橋墩下面、深山里的氣象桿上那維護(hù)半徑就直接決定了方案上限。我的判斷標(biāo)準(zhǔn)很簡單維護(hù)周期超過三個月就盡量避免用電池供電的方案超過一年就必須走有源供電或者超低功耗鏈路。WiFi和蜂窩模塊的待機(jī)功耗普遍在毫安級甚至更高靠電池?fù)我荒觌y度不小有線供電不存在這個問題LoRa因為能做到極低占空比電池跑兩三年反而是常事。所以別先看通訊距離多遠(yuǎn)先問自己下次去現(xiàn)場是什么時候。1.2 數(shù)據(jù)最終要到哪里去平臺接入方式?jīng)Q定了傳輸鏈路我見過不少項目死在了最后一公里——傳感器把數(shù)據(jù)傳上來了但服務(wù)器那邊接不住。比如你選了MQTT協(xié)議平臺卻只提供HTTP接口又比如你選LoRa周邊卻沒有現(xiàn)成網(wǎng)關(guān)自己又不想搭最后只能把串口線直接插到電腦上讀數(shù)據(jù)。所以第二個問題是你的數(shù)據(jù)是要進(jìn)自建平臺、某朵云、還是某個現(xiàn)成的組態(tài)軟件如果要進(jìn)云平臺那你大概率逃不開MQTT/HTTP這幾種通用協(xié)議WiFi和蜂窩最省事有線只要接個小網(wǎng)關(guān)也能轉(zhuǎn)發(fā)如果你打算完全私有化部署LoRa加一個本地網(wǎng)關(guān)反而是最干凈的閉環(huán)。先把數(shù)據(jù)出口定了再回頭看物理鏈路比先選鏈路再遷就平臺要省很多折騰。1.3 部署環(huán)境到底有多不友善溫濕度極限、遮擋與電磁干擾這里說的環(huán)境主要指物理條件。常規(guī)做室內(nèi)監(jiān)測溫度范圍0到40攝氏度濕度正常范圍四套方案都能干但你一放到高溫高濕的養(yǎng)殖棚里或者電磁環(huán)境復(fù)雜的機(jī)房里問題就來了。先說傳感器本身DHT11這種入門級器件在高溫高濕下誤差會明顯變大長期暴露在60%以上濕度環(huán)境里漂移也快真做長期項目建議直接上SHT30或者SHT40這類帶I2C接口且出廠校準(zhǔn)更好的芯片。再說通訊鏈路溫濕度本身數(shù)據(jù)量極小不太怕帶寬但怕穩(wěn)定性和穿透力。倉庫里貨架一多2.4G頻段的WiFi信號衰減非常明顯LoRa在同樣場景下的穿透能力要強(qiáng)得多。最后提一句電磁干擾大電流電纜、變頻器附近有線方案如果沒有做屏蔽反而比無線更容易收到干擾。2. 四種聯(lián)網(wǎng)通道的身份檔案與橫向?qū)Ρ冗@四個方案本質(zhì)上解決的是四個不同的問題硬往一起比其實不太公平但選型的時候又必須放在一起比。我按身份標(biāo)簽來給它們畫像你看哪個更貼近你的現(xiàn)場。2.1 有線穩(wěn)定但長尾巴有線的最大優(yōu)點(diǎn)是結(jié)果可預(yù)期。帶寬充足、延遲低、不受頻段干擾插上就能通跑個幾年都不會因為信號不好失效。Modbus RTU/RS485是溫濕度采集領(lǐng)域最常見的老牌協(xié)議一條雙絞線上可以掛32個節(jié)點(diǎn)成本低且抗干擾能力強(qiáng)用屏蔽雙絞線更好。但代價也很直接布線的工期和人工成本常常比設(shè)備本身還貴。有個項目需要在廠區(qū)里放20個點(diǎn)光從配電間拉線就花了整整兩天線管、橋架、穿線、壓端子最后算下來每個點(diǎn)位的綜合成本遠(yuǎn)超無線方案。而且線纜終歸會老化接頭在潮濕環(huán)境里氧化是常有的事我一朋友的冷鏈倉庫就是因接線端子氧化導(dǎo)致三個點(diǎn)同時失聯(lián)排查了半天才找到病灶。2.2 WiFi家/廠內(nèi)網(wǎng)最方便WiFi方案在四套里是上手成本最低的。ESP8266、ESP32這類模組便宜到幾塊錢開發(fā)資料多到你根本看不完配個路由器就能把數(shù)據(jù)傳內(nèi)網(wǎng)或者走M(jìn)QTT上云也很順。如果你是在辦公室、實驗室、家里的陽臺做監(jiān)測WiFi幾乎是無腦選。問題出在規(guī)模和穩(wěn)定性上。大一點(diǎn)的項目十幾個WiFi節(jié)點(diǎn)同時在內(nèi)網(wǎng)跑路由器壓力倒不大但節(jié)點(diǎn)多了以后總有那么一兩臺會莫名掉線重啟又好了。WiFi的重連機(jī)制、路由器頻段設(shè)置、DHCP租約設(shè)計這些都得花心思處理。再者WiFi模塊的功耗也是四套里偏高的正常工作電流幾十到一百多毫安指望電池長期供電不太現(xiàn)實。2.3 蜂窩哪里都有信號但要算流量賬蜂窩4G/5G/NB-IoT最大的價值是獨(dú)立于你的場地網(wǎng)絡(luò)。現(xiàn)場沒有WiFi、布線又嫌麻煩、位置還偏得很只要有運(yùn)營商信號蜂窩方案就能工作。目前市面上的4G溫濕度傳感器已經(jīng)很成熟插一張物聯(lián)卡就能用遠(yuǎn)程APN、MQTT透傳這類功能基本是標(biāo)配。代價是使用成本結(jié)構(gòu)性偏高。硬件上一個4G模組比LoRa/WiFi模組貴不少而且每個月都有流量費(fèi)哪怕用的是幾塊錢包年的小流量套餐積少成多也是一筆長期開銷。另外蜂窩模塊的電量消耗不低喚醒、搜網(wǎng)、注冊、撥號這一串流程走下來功耗相當(dāng)可觀。2.4 LoRa低功耗遠(yuǎn)距離但速率與中心化部署有門檻LoRa是四套里唯一既遠(yuǎn)又省的。它利用擴(kuò)頻調(diào)制在Sub-GHz頻段傳輸幾百毫瓦的發(fā)射功率就能在城區(qū)跑到幾公里開闊地更遠(yuǎn)。單點(diǎn)速率不高幾kbps到幾十kbps但傳溫濕度這種小包綽綽有余。最重要的是LoRa的休眠電流能做到微安級工作占空比低一節(jié)電池跑兩年的場景非常常見。不過LoRa有個隱藏門檻:它是中心化組網(wǎng)架構(gòu)。節(jié)點(diǎn)本身不能像WiFi那樣直連云平臺必須有一個網(wǎng)關(guān)先把LoRa的數(shù)據(jù)收上來再通過網(wǎng)絡(luò)轉(zhuǎn)發(fā)到服務(wù)器。網(wǎng)關(guān)不是人人都有如果你只有一兩個節(jié)點(diǎn)一個網(wǎng)關(guān)的成本分?jǐn)傁聛頃苄奶?。LoRaWAN的配置也比WiFi麻煩涉及節(jié)點(diǎn)入網(wǎng)激活OTAA/ABP、頻段、信道、占空比限制這些問題不像WiFi輸個密碼就能連上。2.5 一張表看懂核心參數(shù)我把我經(jīng)常用來給客戶講方案的一張對比表放在這里方便你直接拷走參考。維度有線RS485/網(wǎng)線WiFi蜂窩4G/NB-IoTLoRa典型傳輸距離幾十米到幾百米室內(nèi)20-50米不限有基站即可城區(qū)1-3公里開闊地更遠(yuǎn)抗遮擋能力好屏蔽線纜差2.4G穿透弱好基站決定較好Sub-G低頻穿透強(qiáng)工作功耗較低較高高搜網(wǎng)、注冊極低休眠微安級硬件成本低傳感器線纜低ESP32等中高4G模組卡費(fèi)中節(jié)點(diǎn)網(wǎng)關(guān)分?jǐn)偛渴饛?fù)雜度高布線低中配置APN中高網(wǎng)關(guān)入網(wǎng)長期成本線纜維護(hù)路由維護(hù)流量費(fèi)用網(wǎng)關(guān)維護(hù)數(shù)據(jù)直連平臺需網(wǎng)關(guān)/串口服務(wù)器可直接上云可直接上云必須經(jīng)網(wǎng)關(guān)這張表只做方向參考具體數(shù)值會因設(shè)備和環(huán)境有波動但大致邏輯是準(zhǔn)的。3. 供電與功耗續(xù)航時間的真實賬本這是最容易被低估的環(huán)節(jié)。很多新手把傳感器和樂高積木一樣拼起來插上USB電源能跑就以為完事了。但只要你打算長期在線供電和功耗就必須精打細(xì)算。3.1 傳感器本體功耗DHT11與SHT30的差別傳感器本身的功耗先算清楚。DHT11是經(jīng)典的低成本溫濕度傳感器測量時電流大約0.5-1mA空閑時可以忽略不計但它用的是單總線協(xié)議精度也一般長期項目里我其實不太推薦。SHT30這類I2C接口的芯片在讀數(shù)時電流可以做到幾百微安甚至支持周期性測量模式比如每秒鐘測一次平均電流只有幾微安。雖然這些數(shù)字聽上去都不大但在電池供電的系統(tǒng)里小賬不可細(xì)算會直接影響節(jié)點(diǎn)壽命。3.2 無線模塊的功耗大頭差異真正吃掉電量的不是傳感器而是通信模塊。以常用的ESP8266為例WiFi連上并穩(wěn)定傳輸時電流往往在70-100mA這個區(qū)間即便進(jìn)入Modem Sleep也不可能低于十幾毫安。4G模塊更夸張因為要保持與基站的連接經(jīng)常性搜網(wǎng)時瞬時電流能沖到幾百毫安日常平均功耗遠(yuǎn)高于LoRa。LoRa模塊比如SX1268這類主流方案發(fā)射電流在100mA左右但一個溫濕度數(shù)據(jù)包在空中傳輸時間只有幾十到幾百毫秒傳完馬上睡休眠電流降到幾微安。這就是LoRa能一節(jié)電池用兩年的根本原因——不是它發(fā)射時有多省電而是它醒來干活的時間極短。3.3 電池容量估算公式與示例我習(xí)慣用一個簡單的能量賬本來估算續(xù)航每天總功耗 待機(jī)電流 × 待機(jī)時間 傳輸電流 × 工作時間。然后用電池容量除以日耗得到續(xù)航天數(shù)。舉個具體例子假設(shè)一個LoRa節(jié)點(diǎn)每10分鐘上報一次溫濕度。待機(jī)電流3uA每天待機(jī)占絕大多數(shù)時間每次上報工作電流120mA、耗時0.5s每天288次合計約144秒的傳輸時間。一天的耗電量大概等于0.003mA × 86400s 120mA × 144s約等于17.3mAh。用一節(jié)2000mAh的鋰亞電池供電理論續(xù)航達(dá)到115天以上——當(dāng)然這只是理想估算還要折算電池自放電、低溫容量衰減、數(shù)據(jù)重傳帶來的損耗打八折后也能跑到90天以上。同樣頻率用WiFi模塊來跑光是保持連接的平均電流就超過了10mA一天的耗電量至少240mAh起步一節(jié)2000mAh電池?fù)尾贿^8天。3.4 有線供電的隱藏成本有線方案在功耗賬本上是降維打擊但也別高興太早。弱電供電線纜的壓降、集中供電電源的規(guī)格、每個節(jié)點(diǎn)的保險絲這些都是隱藏成本。尤其在一根RS485總線上串十幾個節(jié)點(diǎn)時要考慮總線供電還是分散供電集中供電時線徑不夠容易導(dǎo)致遠(yuǎn)端電壓不足。另外PoE供電網(wǎng)線供電是個好辦法一根線同時搞定通訊和供電但需要交換機(jī)、供電模塊等基礎(chǔ)設(shè)備的支持前期投入更高。4. 數(shù)據(jù)鏈路上行協(xié)議選擇與平臺接入實操選好物理通路之后緊接著要解決數(shù)據(jù)怎么變成平臺能看懂的東西。這部分我按從易到難的順序講并給出最常見的實操路徑。4.1 有線和WiFiModbus RTU/TCP與MQTT有線溫濕度傳感器最常見的是RS485總線用Modbus RTU協(xié)議?；玖鞒淌莻鞲衅鲝臋C(jī)地址、寄存器地址表示溫度和濕度主機(jī)通常是邊緣網(wǎng)關(guān)發(fā)03功能碼讀保持寄存器從機(jī)返回兩個16位寄存器值。如果你直接用Modbus TCP就相當(dāng)于把RS485包換成了以太網(wǎng)幀邏輯一樣。實操時注意從站地址別沖突寄存器地址每家廠商的偏移規(guī)則不一樣拿到手先在串口調(diào)試工具里掃一遍。WiFi方案我默認(rèn)推薦走M(jìn)QTT。規(guī)則很簡單傳感器節(jié)點(diǎn)作為MQTT客戶端連上Broker比如本地裝的EMQX或云上實例把溫濕度發(fā)布到一個主題上比如sensors/warehouse/001/temperature。出差錯的幾個點(diǎn)提醒一下MQTT的QoS級別選0還是1直接關(guān)系到重傳邏輯Will Message遺囑消息要在配置里寫對否則節(jié)點(diǎn)異常掉線時平臺拿不到離線告警還有topic的設(shè)計最好在項目開始時就統(tǒng)一模板后面接自動化規(guī)則和告警會省心很多。4.2 蜂窩MQTT over TCP與HTTP流量怎么算蜂窩模組的開發(fā)模式是先把模塊通過串口透傳或者在模組內(nèi)部跑TCP/IP協(xié)議棧然后走M(jìn)QTT或HTTP。很多現(xiàn)成的4G溫濕度傳感器出廠就內(nèi)置了MQTT配置你只要在配置頁填上Broker的地址、端口、ClientID、Topic就能用。也有的平臺只支持HTTP接口那就在模組里做POST請求注意HTTP的Header和Body格式要匹配平臺要求。流量賬本很容易被忽略MQTT空包很小一個溫濕度包可能就一百字節(jié)左右就算每小時上報一次一個月也才百KB級別但如果你開了?；钚奶鳮eepAlive把包發(fā)得特別頻繁加上TLS握手帶來的額外流量一個月也能攢出幾十MB來。我通常建議客戶每月流量按上報字節(jié)數(shù)×次數(shù)×2.5倍來預(yù)估多出來的部分是握手、重傳留下的余量。4.3 LoRaWANOTAA/ABP激活、Class選型LoRaWAN是LoRa鏈路層的標(biāo)準(zhǔn)協(xié)議。節(jié)點(diǎn)要么用OTAA在空中激活要么用ABP在出廠時手動激活。OTAA的好處是安全性高一些可靈活換網(wǎng)關(guān)但過程和硬件交互多一層ABP配置簡單上手快但密鑰寫死后移植性差。新手做測試時可以先ABP跑通做產(chǎn)品化時再切OTAA。Class選型更關(guān)鍵。Class A最省電節(jié)點(diǎn)發(fā)完上行數(shù)據(jù)后短暫開兩個接收窗口聽網(wǎng)關(guān)下發(fā)數(shù)據(jù)就睡Class B多了定期接收下行的時間槽功耗會上升Class C幾乎一直開著接收適合有持續(xù)電源的節(jié)點(diǎn)。溫濕度采集絕大多數(shù)場景用Class A就行別一上來就選Class C那會把LoRa省電的優(yōu)勢全部丟掉。4.4 采樣與上傳頻率設(shè)計一個數(shù)據(jù)包的成本計算最后聊一下頻率——這是協(xié)議設(shè)計中性價比最高的一步。溫濕度是緩變量5分鐘采樣一次和5秒采樣一次對于環(huán)境監(jiān)測來說幾乎沒有本質(zhì)差別但對功耗、流量、網(wǎng)關(guān)容量的影響是數(shù)量級的。比如用MQTT上傳時每多一倍的頻率就多一倍的TCP握手可能、多一倍的心跳包流量費(fèi)用直接翻番用LoRaWAN時一類地區(qū)的占空比限制比如1%決定了每個節(jié)點(diǎn)每個小時只能累計占用那么長空中時間。所以我的習(xí)慣是先按需求設(shè)頻率再按頻率反推功耗和流量最后做取舍。現(xiàn)場沒人盯著看的時候甚至可以把上報頻率降到15分鐘一次真需要告警時再臨時加一個超閾值立即上報的機(jī)制。5. 部署中的真實體驗我踩過的坑與注意事項這些坑大多不是理論書上的是我在實際項目里被現(xiàn)實教育過后才總結(jié)出來的。按四種方案列一下幫你提前繞開。5.1 WiFi的信號死角與重連問題WiFi項目最常見的故障場景頭天測試時所有節(jié)點(diǎn)在線第二天一早上班發(fā)現(xiàn)三個節(jié)點(diǎn)離線其中兩個在倉庫角落、一個在金屬機(jī)柜里。原因之一是2.4G信號在穿金屬貨架、鐵皮柜之后衰減劇烈原因之二是節(jié)點(diǎn)長時間待機(jī)后路由器把它的DHCP租約回收了模塊卻不知道導(dǎo)致重連時IP查不到。我的應(yīng)對措施有三條第一點(diǎn)位勘測時先用手機(jī)裝個WiFi分析儀在預(yù)放位置實測信號強(qiáng)度信號低于-70dBm就直接考慮換方案第二給節(jié)點(diǎn)配靜態(tài)IP或做IP-MAC綁定防止租約問題第三在固件里加自動重連和看門狗邏輯設(shè)備掉線后能主動重?fù)芏皇强ㄋ涝谀堑热斯じ深A(yù)。5.2 蜂窩的SIM卡管理、物聯(lián)卡與流量預(yù)警蜂窩方案最容易被卡在這個字上。物聯(lián)卡管理平臺要有專人盯套餐到期不續(xù)費(fèi)、流量跑超被?？ㄟ@類事我見過太多次。另外不同運(yùn)營商的APN參數(shù)不一樣采購一批卡前最好確認(rèn)它們是不是同一個接入點(diǎn)信息。我自己的建議是盡量選擇支持遠(yuǎn)程管理的物聯(lián)卡平臺把每張卡的用量設(shè)置閾值告警比如用到80%就發(fā)一次通知避免流量跑完一整個月的數(shù)據(jù)斷掉。還有一點(diǎn)很現(xiàn)實部分便宜物聯(lián)卡在郊區(qū)或高速移動場景下的網(wǎng)絡(luò)優(yōu)先級低實際信號可能弱于手機(jī)裝之前先在現(xiàn)場插手機(jī)測一下不要只看運(yùn)營商的覆蓋圖。5.3 LoRa的組網(wǎng)調(diào)試天線擺放、信道分配、占空比LoRa的坑排前三的一是天線方向性二是頻率參數(shù)配置三是下行確認(rèn)的占空比。天線的常規(guī)誤區(qū)是天線離地越高越好其實還要注意天線垂直極化、周圍不能有大面積金屬遮擋。我調(diào)試過一套園區(qū)的LoRa網(wǎng)絡(luò)節(jié)點(diǎn)放地面和放桿頂收發(fā)成功率完全兩回事。頻率參數(shù)方面國內(nèi)常用470-510MHz但同一區(qū)域多個項目一起跑時可能互相干擾最好先做頻譜掃描挑空一點(diǎn)的頻段。還有LoRaWAN限定了每小時的空中占用時間如果你配了確認(rèn)模式一個節(jié)點(diǎn)反復(fù)重傳同一包不僅耗電還容易被網(wǎng)關(guān)限制這個坑不做壓測很難提前發(fā)現(xiàn)。5.4 有線的線纜敷設(shè)與抗干擾有線方案的問題很少出在傳感器上多數(shù)出在線纜上。因為溫濕度傳感器節(jié)點(diǎn)分散走線經(jīng)常和動力電纜并行如果不做區(qū)分敷設(shè)RS485通訊會受到干擾出現(xiàn)偶發(fā)性亂碼。我的經(jīng)驗是采用屏蔽雙絞線屏蔽層單點(diǎn)接地且盡量避開和變頻器電纜同管敷設(shè)。接線端子也要用好一點(diǎn)的防潮端子尤其是高濕場景端子氧化之后接觸電阻上升通訊直接飄。6. 按場景選型四個真實項目的決策復(fù)盤前面說了那么多原理和坑最后用四個我做過的項目把邏輯串起來。你看完后應(yīng)該能對著自己的現(xiàn)場條件做一個判斷了。6.1 室內(nèi)機(jī)房/實驗室機(jī)柜有線或WiFi一個客戶要在機(jī)房機(jī)房列頭柜加裝溫濕度監(jiān)測點(diǎn)一共十幾個點(diǎn)。機(jī)房信號復(fù)雜2.4G頻段干擾源多而且WiFi設(shè)備綁定運(yùn)營商的APN在這類環(huán)境并不靠譜另外公司網(wǎng)絡(luò)要求高強(qiáng)度安全WiFi入網(wǎng)要走一堆流程。最終用的方案是RS485有線采集到邊緣網(wǎng)關(guān)網(wǎng)關(guān)用網(wǎng)線上傳至內(nèi)部IoT平臺。這套方案的優(yōu)勢是走出了一條很清晰的隱患鏈路現(xiàn)場無線的復(fù)雜性被直接消滅了數(shù)據(jù)回到內(nèi)網(wǎng)安全策略也好執(zhí)行。如果點(diǎn)位特別分散且不方便布線我才會考慮WiFi條件是現(xiàn)場有專屬IoT的SSID且每個點(diǎn)位信號強(qiáng)度滿足要求。6.2 溫室大棚/種植基地LoRa為主另一位客戶的蔬菜大棚基地三個大棚跨度一百多米中間還隔著一片空地接WiFi和有線都很費(fèi)勁。我們直接用LoRa每個棚里放兩個溫濕度節(jié)點(diǎn)棚頂中心一個、側(cè)邊一個網(wǎng)關(guān)放在中間的農(nóng)具房頂上。節(jié)點(diǎn)用兩節(jié)5號鋰鐵電池每15分鐘上報一次跑到現(xiàn)在七個多月都沒換過電。這套方案很典型節(jié)點(diǎn)數(shù)量在幾十個以內(nèi)、現(xiàn)場無公共網(wǎng)絡(luò)、布線麻煩、維護(hù)半徑又遠(yuǎn)LoRa網(wǎng)關(guān)MQTT上云的組合基本就是最優(yōu)解。6.3 冷鏈運(yùn)輸/偏遠(yuǎn)監(jiān)測點(diǎn)蜂窩為主冷鏈車的情況完全不一樣車是移動的現(xiàn)場沒有固定網(wǎng)絡(luò)也沒有地方架網(wǎng)關(guān)。蜂窩方案就成了唯一合理選擇。我們用的是內(nèi)置4G模組的溫濕度記錄儀配合物聯(lián)卡從裝車到卸貨全程每5分鐘上報一次溫度。偏遠(yuǎn)山區(qū)的氣象監(jiān)測點(diǎn)也一樣沒有局域網(wǎng)、沒有有線條件但有運(yùn)營商的信號那么蜂窩也是首選。這類方案核心要看流量和電源冷鏈車可以指望車載電源偏遠(yuǎn)獨(dú)立站就得配太陽能鋰電池了。6.4 大型園區(qū)/工廠有線LoRa/WiFi混搭上了規(guī)模的園區(qū)單一方案往往搞不定。我做過一個老廠區(qū)改造項目辦公區(qū)樓宇內(nèi)的機(jī)房、檔案室用有線RS485車間內(nèi)部點(diǎn)位密集、電磁條件差用有線的同時還要注意屏蔽處理成品倉庫跨度大貨架多單獨(dú)搞WiFi容易有死角最后加了LoRa網(wǎng)關(guān)做覆蓋還有幾處室外配電箱直接放4G DTU省去拉線。數(shù)據(jù)統(tǒng)一匯到一個MQTT Broker里平臺層完全無感——對上層來說不管是LoRa網(wǎng)關(guān)還是4G DTU還是網(wǎng)口網(wǎng)關(guān)都只是透傳數(shù)據(jù)的一個通道。這幾套方案串下來我個人體會最深的一點(diǎn)是不要追求用一套方案打通全世界。先想清楚運(yùn)維半徑再決定通訊半徑然后把數(shù)據(jù)出口定好最后才落到具體協(xié)議和硬件選型上。每次項目都這樣走一遍你會發(fā)現(xiàn)很多糾結(jié)根本不是選型問題而是你沒搞清楚這數(shù)據(jù)到底怎么出去、后續(xù)誰負(fù)責(zé)維護(hù)這兩個根本問題。