簡(jiǎn)介基于.NET8的跨平臺(tái)物聯(lián)網(wǎng)網(wǎng)關(guān)源碼包面向工業(yè)物聯(lián)網(wǎng)平臺(tái)開(kāi)發(fā)、邊緣計(jì)算及數(shù)據(jù)采集場(chǎng)景解決PLC、CNC、掃碼槍、OPC UA/Server、MQTT等多種設(shè)備與Thingsboard、IoTSharp或私有MES/SCADA之間的雙向數(shù)據(jù)互通問(wèn)題。資源以可視化配置為主同時(shí)提供驅(qū)動(dòng)開(kāi)發(fā)接口便于快速接入異種協(xié)議包含1233個(gè)文件、約30MB以C#源碼cs為核心輔以cshtml/js/css界面文件、gif演示動(dòng)畫(huà)及png圖片并涵蓋OPC UA客戶(hù)端幫助類(lèi)、WTM框架封裝、通用CRUD模板等實(shí)用代碼可直接開(kāi)啟項(xiàng)目開(kāi)發(fā)或作為技術(shù)選型參考。已有46人瀏覽學(xué)習(xí)適合需要搭建跨平臺(tái)網(wǎng)關(guān)模塊、梳理邊緣計(jì)算處理流程或評(píng)估.NET物聯(lián)網(wǎng)中間件的開(kāi)發(fā)者。1. 基于.NET8的物聯(lián)網(wǎng)網(wǎng)關(guān)為什么值得再花一次精力選型做工廠數(shù)據(jù)采集和SCADA對(duì)接的老手大多有這種體會(huì)設(shè)備的通訊協(xié)議五花八門(mén)Modbus、OPC UA、S7、DL/T645各說(shuō)各話上層的IoT平臺(tái)也在換前幾年忙著接Thingsboard這陣子又有人把Thingsboard老用戶(hù)往JetLinks上遷還有用IoTSharp做私有化交付的。每一次平臺(tái)調(diào)整最大的工作量往往不在平臺(tái)本身而是在網(wǎng)關(guān)——現(xiàn)場(chǎng)那些既要下沉到設(shè)備層采集數(shù)據(jù)、又要上行到平臺(tái)做雙向控制的邊緣盒子。選錯(cuò)一次網(wǎng)關(guān)后面每換一個(gè)平臺(tái)就要重新寫(xiě)一遍設(shè)備接入邏輯非常傷。.NET8物聯(lián)網(wǎng)網(wǎng)關(guān)這類(lèi)項(xiàng)目解決的就是這個(gè)環(huán)節(jié)的痛點(diǎn)把設(shè)備接入、協(xié)議解析、平臺(tái)轉(zhuǎn)發(fā)、下行控制這些通用能力做成一款可視化配置的跨平臺(tái)網(wǎng)關(guān)部署后靠配置不靠改代碼設(shè)備接入和平臺(tái)對(duì)接都能在頁(yè)面上完成。它的適用人群很明確——正在做MES、SCADA數(shù)據(jù)采集的集成商接了多個(gè)Thingsboard/IoTSharp項(xiàng)目、想減少重復(fù)開(kāi)發(fā)的團(tuán)隊(duì)以及用.NET技術(shù)棧做工業(yè)互聯(lián)網(wǎng)、設(shè)備智能運(yùn)維的研發(fā)人員。對(duì)這些人來(lái)說(shuō)值得把時(shí)間花在“網(wǎng)關(guān)怎么選、配置怎么設(shè)計(jì)、坑在哪里”上。下文按落地路徑展開(kāi)。先從技術(shù)選型說(shuō)起看 .NET8 為什么適合做網(wǎng)關(guān)的底座再講可視化配置怎么設(shè)計(jì)才不會(huì)變成黑匣子然后把 Thingsboard、IoTSharp、自研平臺(tái)的對(duì)接方式拆開(kāi)最后專(zhuān)門(mén)列一個(gè)避坑清單把做網(wǎng)關(guān)容易翻車(chē)的幾個(gè)地方一次說(shuō)透。2. 技術(shù)底座選型為什么是.NET8跨平臺(tái)發(fā)布帶來(lái)的變化2.1 .NET8在工業(yè)網(wǎng)關(guān)上的三個(gè)關(guān)鍵優(yōu)勢(shì)做工業(yè)物聯(lián)網(wǎng)網(wǎng)關(guān)以前的主流路線是C跑在Linux工控板上或者Java跑在軟網(wǎng)關(guān)容器里。.NET 框架在過(guò)去很長(zhǎng)一段時(shí)間里給工業(yè)用戶(hù)留下的印象是“Windows專(zhuān)用、內(nèi)存占用大、部署麻煩”直到 .NET Core 之后才慢慢改觀。.NET8 把跨平臺(tái)能力、內(nèi)存占用和發(fā)布方式都推向了一個(gè)新的成熟度選它做網(wǎng)關(guān)的底座有三個(gè)點(diǎn)值得展開(kāi)說(shuō)。第一個(gè)是內(nèi)存占用。用 .NET 8 做邊緣程序配合 GC 配置和 Native AOT 發(fā)布空閑內(nèi)存可以壓到幾十MB量級(jí)。相比傳統(tǒng) .NET Framework 動(dòng)輒幾百M(fèi)B起步這個(gè)量級(jí)放在工業(yè)網(wǎng)關(guān)的嵌入式環(huán)境里就有了可行性。第二個(gè)是跨平臺(tái)發(fā)布。一套代碼可以同時(shí)發(fā)布出Linux ARM64跑在RK3568、樹(shù)莓派這類(lèi)邊緣盒子上、Linux x64跑在軟網(wǎng)關(guān)或工控機(jī)上和Windows x64跑在SCADA服務(wù)器上這在工廠現(xiàn)場(chǎng)很有用——有些車(chē)間是Windows工控機(jī)有些又是ARM盒子同一個(gè)網(wǎng)關(guān)程序要能同時(shí)覆蓋兩種環(huán)境。第三個(gè)是庫(kù)生態(tài)。.NET 生態(tài)里有成熟的 MQTT 客戶(hù)端庫(kù)MQTTnet、OPC UA 客戶(hù)端庫(kù)OPCFoundation 官方庫(kù)、Modbus 庫(kù)NModbus 等、數(shù)據(jù)庫(kù)驅(qū)動(dòng)和 Web 框架網(wǎng)關(guān)需要的通信、存儲(chǔ)、配置界面這些基礎(chǔ)設(shè)施不用全部自己寫(xiě)。2.2 跨平臺(tái)發(fā)布與AOT裁剪邊界.NET8 發(fā)布跨平臺(tái)程序常見(jiàn)做法是用dotnet publish自帶 runtime并通過(guò).csproj里的RuntimeIdentifiers指定目標(biāo)平臺(tái)。這樣發(fā)布出來(lái)的是自包含程序目標(biāo)機(jī)器上不需要安裝 .NET 運(yùn)行時(shí)對(duì)工業(yè)現(xiàn)場(chǎng)很友好——很多工控機(jī)不讓裝額外運(yùn)行時(shí)。PropertyGroup OutputTypeExe/OutputType TargetFrameworknet8.0/TargetFramework RuntimeIdentifierslinux-arm64;linux-x64;win-x64/RuntimeIdentifiers SelfContainedtrue/SelfContained PublishSingleFiletrue/PublishSingleFile PublishTrimmedtrue/PublishTrimmed InvariantGlobalizationtrue/InvariantGlobalization /PropertyGroup這段配置里主要看三處。RuntimeIdentifiers決定了可以發(fā)布的目標(biāo)平臺(tái)列表發(fā)布命令里用-r linux-arm64指定具體平臺(tái)。PublishSingleFile把程序打成單文件部署時(shí)只拷貝一個(gè)文件加配置文件。PublishTrimmed開(kāi)啟裁剪以減小體積但這個(gè)選項(xiàng)要謹(jǐn)慎——網(wǎng)關(guān)程序通常大量使用反射來(lái)做協(xié)議插件加載和配置反序列化裁剪會(huì)把反射需要的元數(shù)據(jù)剪掉導(dǎo)致運(yùn)行時(shí)“找不到類(lèi)型”。如果確實(shí)需要裁剪做法是給有反射調(diào)用的程序集加上DynamicDependency特性或者直接在 csproj 里設(shè)置TrimmerRootAssembly把相關(guān)程序集排除在裁剪之外。實(shí)際項(xiàng)目里我一般不會(huì)對(duì)所有平臺(tái)開(kāi)啟裁剪而是把 ARM64 單文件作為首選部署形態(tài)。裁剪后的 ARM64 網(wǎng)關(guān)程序連帶運(yùn)行時(shí)體積在 30-50MB 量級(jí)對(duì)于存儲(chǔ)不大的盒子來(lái)說(shuō)很舒服。Win-x64 部署在服務(wù)器上空間不緊張裁剪帶來(lái)的收益不大風(fēng)險(xiǎn)卻不少不裁剪反而省心。2.3 網(wǎng)關(guān)程序的最小骨架配置加載、設(shè)備接入、數(shù)據(jù)上行三件事網(wǎng)關(guān)程序本質(zhì)上是個(gè)常駐服務(wù)喚醒后啟動(dòng)三部分邏輯讀配置、啟設(shè)備的接入通道、建上行的平臺(tái)通道。配置放JSON文件比放數(shù)據(jù)庫(kù)更直觀格式大致是這樣{ gatewayId: GW-0001, deviceChannels: [ { name: modbus-rtu-1, type: modbus-rtu, portName: /dev/ttyS4, baudRate: 9600, dataBits: 8, parity: None, stopBits: 1, pollIntervalMs: 1000, devices: [...] }, { name: opcua-channel-1, type: opcua-client, endpoint: opc.tcp://192.168.1.10:4840, security: None, pollIntervalMs: 500, devices: [...] } ], upstream: { type: mqtt, brokerHost: 192.168.1.100, brokerPort: 1883, topicPrefix: gw/GW-0001 } }加載配置的代碼非常簡(jiǎn)單用System.Text.Json反序列化成強(qiáng)類(lèi)型配置類(lèi)即可。但有幾個(gè)參數(shù)要在代碼里處理成約定而不是留給用戶(hù)隨意配。比如pollIntervalMs最低限到200毫秒——低于這個(gè)值會(huì)對(duì)設(shè)備和網(wǎng)關(guān)CPU造成無(wú)意義的壓力噴在文檔里不如直接寫(xiě)在代碼里。upstream.type當(dāng)前支持 mqtt、thingsboard、iotsharp 三種每種對(duì)應(yīng)不同的上行協(xié)議封裝。這樣的配置結(jié)構(gòu)把設(shè)備接入與平臺(tái)上行解耦了換平臺(tái)時(shí)只改 upstream 塊不動(dòng)設(shè)備通道配。3. 可視化配置從設(shè)備模型到規(guī)則鏈的落地設(shè)計(jì)3.1 可視化配置的兩個(gè)層次和生產(chǎn)者的選擇可視化配置有兩種做法。第一種是淺層的把設(shè)備接入?yún)?shù)做成界面表單比如選串口、填波特率、加寄存器表。第二種是深層的還要把數(shù)據(jù)處理和轉(zhuǎn)發(fā)規(guī)則做成圖形化編排比如“溫度超過(guò)閾值就報(bào)警并寫(xiě)入另一個(gè)Topic”。網(wǎng)關(guān)要能服務(wù)MES和SCADA的復(fù)雜場(chǎng)景只做到第一種不夠——SCADA場(chǎng)景通常需要對(duì)原始報(bào)文做規(guī)約解析、點(diǎn)位映射甚至要做簡(jiǎn)單的計(jì)算累計(jì)流量、溫差、效率這些靠死板的表單配置表達(dá)不了所以可視化配置的含義應(yīng)該包含規(guī)則鏈編排。在實(shí)現(xiàn)方案上開(kāi)源社區(qū)有Node-RED這種成熟的可視化編程工具可以直接嵌很多網(wǎng)關(guān)項(xiàng)目用Node-RED做規(guī)則流開(kāi)發(fā)者從零開(kāi)發(fā)一套拖拽配置的成本太高。但網(wǎng)關(guān)交付時(shí)要考慮現(xiàn)場(chǎng)實(shí)施人員的使用水平Node-RED的節(jié)點(diǎn)類(lèi)型對(duì)非IT背景的調(diào)試人員來(lái)說(shuō)上手門(mén)檻不低。如果目標(biāo)用戶(hù)是系統(tǒng)集成商工程師我一般建議自己做一個(gè)輕量級(jí)的“設(shè)備-點(diǎn)位-轉(zhuǎn)發(fā)”三層配置界面把配置項(xiàng)控制在二三十個(gè)左右再輔以簡(jiǎn)單的Web API做批量導(dǎo)入導(dǎo)出實(shí)用程度比上全套Node-RED高得多。3.2 用Web API方式做點(diǎn)位映射配置數(shù)據(jù)結(jié)構(gòu)的核心點(diǎn)位映射是整個(gè)可視化配置最核心的部分它解決“設(shè)備寄存器/節(jié)點(diǎn)的哪個(gè)值對(duì)應(yīng)平臺(tái)的哪個(gè)遙測(cè)字段”的問(wèn)題。配置界面本質(zhì)上是操作一套點(diǎn)位映射數(shù)據(jù)。舉個(gè)例子一個(gè)Modbus設(shè)備讀到的保持寄存器地址40001對(duì)應(yīng)平臺(tái)上的temperature字段地址40002對(duì)應(yīng)humidity。這個(gè)對(duì)應(yīng)關(guān)系如果只存在現(xiàn)場(chǎng)工程師的腦子里后面交接一定出問(wèn)題。{ deviceName: plc-1, points: [ { name: temperature, address: 40001, dataType: float, byteOrder: ABCD, multiplier: 0.1, storeRule: always, reportToUpstream: true, upstreamKey: temp }, { name: runningState, address: 40009, dataType: bool, bitIndex: 2, storeRule: onChange, reportToUpstream: true } ] }這樣一個(gè)點(diǎn)位配置要解決三個(gè)問(wèn)題。address和dataType解決“從設(shè)備哪里讀、讀出來(lái)是什么類(lèi)型”的問(wèn)題。byteOrder解決浮點(diǎn)數(shù)字節(jié)序的問(wèn)題——這是Modbus采集里最容易出錯(cuò)的點(diǎn)很多設(shè)備用“CDAB”而不是“ABCD”配置項(xiàng)里必須暴露出來(lái)而且建議做成下拉選擇而不是自由填。multiplier是系數(shù)有的設(shè)備原始值是0-1000實(shí)際工程量是0-100.0乘0.1就是顯示值。storeRule是存儲(chǔ)與上報(bào)策略——always表示每個(gè)采集周期都上報(bào)適合需要密集采樣的模擬量onChange表示只在值變化時(shí)上報(bào)適合開(kāi)關(guān)量和狀態(tài)量能大幅減少上行流量。4. 對(duì)接Thingsboard、IoTSharp和自研平臺(tái)三個(gè)平臺(tái)三種接法4.1 Thingsboard接入MQTT協(xié)議與雙向RPCThingsboard對(duì)網(wǎng)關(guān)的支持在物聯(lián)網(wǎng)平臺(tái)里算做得規(guī)范的。它提供了 Gateway MQTT API專(zhuān)門(mén)的網(wǎng)關(guān)Topic用于上報(bào)設(shè)備列表、遙測(cè)數(shù)據(jù)和設(shè)備屬性。網(wǎng)關(guān)接入Thingsboard大致分兩步先以網(wǎng)關(guān)身份連接MQTT然后通過(guò)v1/gateway/telemetry上報(bào)設(shè)備數(shù)據(jù)通過(guò)v1/gateway/rpc接收下行命令。訂閱RPC后Thingsboard 服務(wù)端發(fā)來(lái)的設(shè)備控制指令會(huì)到達(dá)網(wǎng)關(guān)網(wǎng)關(guān)再把指令解析成實(shí)際的設(shè)備寫(xiě)操作。// 使用 MQTTnet 作為客戶(hù)端庫(kù) var factory new MqttFactory(); var mqttClient factory.CreateMqttClient(); var options new MqttClientOptionsBuilder() .WithTcpServer(brokerHost, brokerPort) .WithCredentials(GW-0001, access-token) .WithClientId($gw-{Guid.NewGuid():N}) .Build(); await mqttClient.ConnectAsync(options, CancellationToken.None); // 上報(bào)遙測(cè) var telemetry new { ts DateTime.UtcNow.Ticks, values new Dictionarystring, object { { temp, 25.3 }, { humidity, 60 } } }; var payload JsonSerializer.Serialize(new { // Thingsboard 網(wǎng)關(guān)遙測(cè)上報(bào)格式{ 設(shè)備名: [ { ts:..., values: {...} } ] } devices new Dictionarystring, object { { plc-1, new[] { telemetry } } } }); await mqttClient.PublishAsync(new MqttApplicationMessageBuilder() .WithTopic(v1/gateway/telemetry) .WithPayload(payload) .Build());把這段代碼放在定時(shí)器里每秒鐘觸發(fā)一次網(wǎng)關(guān)就以設(shè)備名義持續(xù)向Thingsboard上報(bào)這條遙測(cè)鏈路的數(shù)據(jù)。注意一個(gè)細(xì)節(jié)上報(bào)周期要設(shè)置成略大于設(shè)備采集周期否則同一批數(shù)據(jù)會(huì)被重復(fù)上報(bào)兩次。Thingsboard的遙測(cè)存儲(chǔ)對(duì)同一時(shí)間戳的數(shù)據(jù)做了去重但重復(fù)上報(bào)還是會(huì)造成不必要的帶寬浪費(fèi)。如果設(shè)備上報(bào)頻率不高推薦storeRule為 onChange 的點(diǎn)位用事件驅(qū)動(dòng)上報(bào)而 always 點(diǎn)位才用定時(shí)上報(bào)。4.2 IoTSharp和自研平臺(tái)的接法先看API再談配置IoTSharp 的設(shè)備和遙測(cè)模型與Thingsboard相似都用“設(shè)備-遙測(cè)-屬性-命令”這套結(jié)構(gòu)所以接入邏輯大體可以復(fù)用。區(qū)別在于API路徑和認(rèn)證方式以及命令下行的Topic格式不一樣。接入這類(lèi)平臺(tái)最可靠的方式是去翻它的HTTP API文檔或者用Swagger頁(yè)面實(shí)測(cè)接口不要照抄Thingsboard的做法。常見(jiàn)做法是網(wǎng)關(guān)的 upstream 模塊支持一種“generic-http”類(lèi)型每秒或按點(diǎn)位變化批量POST JSON到平臺(tái)的/api/telemetry端點(diǎn)下行控制則通過(guò)輪詢(xún)平臺(tái)的命令接口實(shí)現(xiàn)。所謂輪詢(xún)而不是長(zhǎng)連接是因?yàn)镠TTP輪詢(xún)的兼容性最好幾乎任何自研平臺(tái)都有HTTP接口改造成本最低。遇到對(duì)標(biāo)MQTT的自研平臺(tái)時(shí)我一般會(huì)先問(wèn)三個(gè)問(wèn)題。平臺(tái)對(duì)設(shè)備接入有沒(méi)有官方SDK走M(jìn)QTT的話Topic命名規(guī)范是什么下行命令是同步請(qǐng)求還是發(fā)消息讓客戶(hù)端自己拉這三個(gè)問(wèn)題的答案直接決定了接入方案的選型。只要平臺(tái)支持MQTT就優(yōu)先讓自研平臺(tái)復(fù)用Thingsboard的Topic風(fēng)格——網(wǎng)關(guān)代碼里可以抽象一個(gè)IPlatformAdapter接口每個(gè)平臺(tái)一個(gè)實(shí)現(xiàn)類(lèi)配置文件里指定upstream.type即可。這樣后期接入新平臺(tái)時(shí)不需要改設(shè)備采集部分的代碼只增加新的Adapter類(lèi)設(shè)備側(cè)配置和點(diǎn)位映射表保持原樣。4.3 雙向數(shù)據(jù)通訊的方向定義上行遙測(cè)、下行控制、雙向心跳雙向數(shù)據(jù)通訊在SCADA和MES場(chǎng)景里不是一句空話要明確分成三個(gè)方向來(lái)實(shí)現(xiàn)。上行遙測(cè)采集周期內(nèi)的傳感器值、設(shè)備狀態(tài)、報(bào)警事件從設(shè)備經(jīng)網(wǎng)關(guān)到平臺(tái)。這個(gè)方向占據(jù)絕大多數(shù)流量由網(wǎng)關(guān)主動(dòng)推送。下行控制平臺(tái)的遠(yuǎn)程操作從平臺(tái)到網(wǎng)關(guān)再到設(shè)備寄存器或OPC UA節(jié)點(diǎn)。這要求網(wǎng)關(guān)具備“寫(xiě)”操作的能力。Modbus場(chǎng)景下寫(xiě)保持寄存器、寫(xiě)線圈是常見(jiàn)操作OPC UA場(chǎng)景下寫(xiě)Node的Value屬性。關(guān)鍵點(diǎn)在于權(quán)限和審計(jì)——網(wǎng)關(guān)應(yīng)該記錄每次下行控制的操作來(lái)源和結(jié)果否則現(xiàn)場(chǎng)“誰(shuí)改的參數(shù)”根本說(shuō)不清。雙向心跳網(wǎng)關(guān)和平臺(tái)之間的連接檢測(cè)。用MQTT的KeepAlive機(jī)制而非應(yīng)用層自定義心跳這樣省流量且標(biāo)準(zhǔn)。但要注意一件事MQTT斷開(kāi)重連后需要重新上報(bào)所有設(shè)備的狀態(tài)屬性表示網(wǎng)關(guān)重啟過(guò)否則平臺(tái)側(cè)看到的是舊狀態(tài)會(huì)誤判設(shè)備長(zhǎng)時(shí)間未上報(bào)。網(wǎng)關(guān)設(shè)備列表異常。每臺(tái)設(shè)備的設(shè)備狀態(tài)屬性通常包含lastSeen時(shí)間戳。在網(wǎng)關(guān)重連成功后發(fā)一次“設(shè)備在上線”屬性更新這個(gè)細(xì)節(jié)在可靠通訊評(píng)估里很重要。5. 常見(jiàn)問(wèn)題與避坑清單網(wǎng)關(guān)落地最容易翻車(chē)的5個(gè)地方5.1 串口被多個(gè)通道搶占導(dǎo)致采集線程崩潰現(xiàn)象現(xiàn)場(chǎng)一臺(tái)網(wǎng)關(guān)盒子里配置了兩個(gè)Modbus RTU通道物理上共用同一個(gè)串口。調(diào)試時(shí)發(fā)現(xiàn)一會(huì)兒這個(gè)通道正常一會(huì)兒那個(gè)通道超時(shí)采集數(shù)據(jù)亂跳。原因Modbus RTU是半雙工總線同一時(shí)刻只能由一個(gè)主站發(fā)起請(qǐng)求。多個(gè)通道同時(shí)輪詢(xún)同一個(gè)串口報(bào)文在物理層就沖突了設(shè)備端根本沒(méi)辦法正確應(yīng)答。解決要么用不同串口承載不同總線要么在網(wǎng)關(guān)內(nèi)部給每個(gè)串口加一把全局鎖同一串口上的所有通道串行輪詢(xún)。后者是更常見(jiàn)的處理注意輪詢(xún)的總周期會(huì)變長(zhǎng)比如兩個(gè)通道各50個(gè)點(diǎn)位每個(gè)點(diǎn)位20毫秒超時(shí)總周期可能超過(guò)2秒SCADA實(shí)時(shí)性要求高時(shí)要合理設(shè)計(jì)輪詢(xún)分組。5.2 OPC UA連接被“假在線”迷惑現(xiàn)象OPC UA客戶(hù)端連接成功后訂閱的數(shù)據(jù)項(xiàng)長(zhǎng)時(shí)間不更新但網(wǎng)關(guān)日志顯示連接正常平臺(tái)界面上數(shù)據(jù)卻是舊值。原因這是OPC UA訂閱的采集中斷導(dǎo)致的“假在線”。OPC UA服務(wù)端的訂閱publishing interval較長(zhǎng)或者服務(wù)端連接數(shù)達(dá)到上限后不再推送數(shù)據(jù)但TCP連接仍維持客戶(hù)端誤以為一切正常。解決在網(wǎng)關(guān)側(cè)增加應(yīng)用層數(shù)據(jù)新鮮度檢查——如果某個(gè)訂閱的數(shù)據(jù)項(xiàng)超過(guò)N個(gè)周期未更新N通常取5-10個(gè)publishing interval判定為數(shù)據(jù)陳舊主動(dòng)重建訂閱。這個(gè)邏輯不能省因?yàn)橹苯訑嚅_(kāi)TCP會(huì)讓服務(wù)端產(chǎn)生很多日志重建訂閱才是優(yōu)雅的做法。5.3 Thingsboard遙測(cè)字段類(lèi)型不匹配導(dǎo)致數(shù)據(jù)寫(xiě)不進(jìn)現(xiàn)象網(wǎng)關(guān)上報(bào)溫度數(shù)據(jù)正常但平臺(tái)側(cè)遙測(cè)列表里始終查不到temp字段另一些字段又正常。原因Thingsboard對(duì)遙測(cè)字段做了類(lèi)型推斷如果設(shè)備歷史最早上報(bào)的temp是字符串比如網(wǎng)關(guān)側(cè)做成了25.3后面再上報(bào)數(shù)值型double平臺(tái)的Cassandra時(shí)序存儲(chǔ)會(huì)拒絕類(lèi)型不一致的寫(xiě)入。解決點(diǎn)位配置里的dataType要和上游原始數(shù)據(jù)結(jié)構(gòu)保持嚴(yán)格一致這個(gè)類(lèi)型不能被“可視化配置”自動(dòng)轉(zhuǎn)換。網(wǎng)關(guān)里做類(lèi)型轉(zhuǎn)換時(shí)也要小心寧可統(tǒng)一用浮點(diǎn)數(shù)不要一會(huì)兒字符串一會(huì)兒數(shù)值。已經(jīng)壞掉的歷史數(shù)據(jù)類(lèi)型在Thingsboard里很難改最徹底的辦法是把遙測(cè)字段名換掉讓平臺(tái)重新推斷。5.4 網(wǎng)關(guān)重啟后設(shè)備狀態(tài)“假離線”現(xiàn)象網(wǎng)關(guān)斷電重啟平臺(tái)側(cè)所有通過(guò)該網(wǎng)關(guān)接入的設(shè)備全部顯示離線即使網(wǎng)關(guān)本身顯示在線遙測(cè)數(shù)據(jù)也仍在上報(bào)。原因設(shè)備在線狀態(tài)不是平臺(tái)實(shí)時(shí)探測(cè)的而是依賴(lài)設(shè)備上報(bào)的“在線心跳”或“離線消息”。網(wǎng)關(guān)重啟后它和設(shè)備間的TCP/串口鏈路消失但平臺(tái)側(cè)的連接狀態(tài)還是舊的。解決網(wǎng)關(guān)啟動(dòng)流程里加一步“初始狀態(tài)上報(bào)”連接上行通訊成功后立即上報(bào)所有子設(shè)備的在線狀態(tài)和基礎(chǔ)屬性。這個(gè)動(dòng)作放在程序入口的IHostedService.StartAsync()中不要放在后臺(tái)定時(shí)任務(wù)里——定時(shí)任務(wù)依賴(lài)的通道可能在StartAsync時(shí)還沒(méi)就緒順序要保證。5.5 高并發(fā)下點(diǎn)位上報(bào)表導(dǎo)致內(nèi)存暴漲現(xiàn)象一個(gè)網(wǎng)關(guān)上接了500個(gè)點(diǎn)位每個(gè)點(diǎn)位都設(shè)成 always 上報(bào)運(yùn)行一小時(shí)后網(wǎng)關(guān)內(nèi)存漲到幾百M(fèi)B最后被系統(tǒng)殺掉。原因點(diǎn)位上報(bào)產(chǎn)生大量小對(duì)象放入內(nèi)存隊(duì)列后消費(fèi)速度跟不上生產(chǎn)速度。尤其當(dāng)上游平臺(tái)暫時(shí)不可用、MQTT重連失敗時(shí)內(nèi)存隊(duì)列會(huì)無(wú)限膨脹內(nèi)存爆炸是遲早的問(wèn)題。解決內(nèi)存隊(duì)列要有界設(shè)置最大積壓條數(shù)常見(jiàn)做法是10萬(wàn)條超過(guò)后丟棄最老的遙測(cè)數(shù)據(jù)并記錄一條告警。代碼上用ChannelT做生產(chǎn)者消費(fèi)者模型更穩(wěn)消費(fèi)端批量打包發(fā)送減少M(fèi)QTT發(fā)布次數(shù)。如果現(xiàn)場(chǎng)對(duì)數(shù)據(jù)完整性要求極高那就把遙測(cè)寫(xiě)入本地SQLite做持久化緩沖等平臺(tái)上連后按序補(bǔ)發(fā)代價(jià)是網(wǎng)關(guān)代碼復(fù)雜度上升一個(gè)等級(jí)。6. 進(jìn)階數(shù)據(jù)新鮮度自診斷和看門(mén)狗自恢復(fù)網(wǎng)關(guān)部署到現(xiàn)場(chǎng)后遠(yuǎn)程維護(hù)的痛點(diǎn)不是功能不夠而是不知道它什么時(shí)候“卡住”了。設(shè)備采集死鎖、上行斷連后重連不成功、磁盤(pán)寫(xiě)滿(mǎn)這些問(wèn)題在無(wú)人值守的盒子上潛伏很久直到業(yè)務(wù)方發(fā)現(xiàn)數(shù)據(jù)異常才被暴露。所以在網(wǎng)關(guān)里加兩個(gè)機(jī)制都屬于投入小收益大的事。數(shù)據(jù)新鮮度自診斷在網(wǎng)關(guān)注冊(cè)一個(gè)“診斷設(shè)備”每5秒一次自檢檢查每個(gè)通道最近一次成功采集的時(shí)間。如果某個(gè)通道超過(guò)10個(gè)采集周期沒(méi)有成功采集就把診斷設(shè)備的遙測(cè)數(shù)據(jù)中增加一個(gè)channel_healthyfalse的字段上報(bào)給平臺(tái)。這樣不用登錄網(wǎng)關(guān)在Thingsboard或自研平臺(tái)的大屏上就能看到網(wǎng)關(guān)健康狀況。public class HealthChecker : BackgroundService { private readonly IChannelHealthRegistry _registry; private readonly IUpstream _upstream; private static readonly TimeSpan CheckInterval TimeSpan.FromSeconds(5); protected override async Task ExecuteAsync(CancellationToken ct) { while (!ct.IsCancellationRequested) { var unhealthyChannels _registry.GetUnhealthyChannels(TimeSpan.FromSeconds(10)); if (unhealthyChannels.Any()) { await _upstream.ReportTelemetry(diagnostic, new { unhealthyChannels string.Join(,, unhealthyChannels) }, ct); } await Task.Delay(CheckInterval, ct); } } }這段代碼把每個(gè)通道的“最近成功時(shí)間”集中在注冊(cè)表里維護(hù)。設(shè)備采集線程每次成功讀取一幀數(shù)據(jù)后調(diào)用_registry.MarkHealthy(channelName)HealthChecker獨(dú)立巡檢這些時(shí)間戳。這個(gè)模式的好處是診斷邏輯與采集邏輯完全解耦采集代碼不關(guān)心有沒(méi)有人看它診斷代碼不關(guān)心具體協(xié)議?？撮T(mén)狗則是另一個(gè)層面的保障。最簡(jiǎn)單的做法是在部署配置里放一個(gè)守護(hù)腳本每30秒檢查主進(jìn)程是否還在不在就拉起。用systemd部署時(shí)直接配置Restartalways加RestartSec10s比自己寫(xiě)守護(hù)腳本可靠得多。[Unit] DescriptionIoT Gateway Service Afternetwork.target [Service] WorkingDirectory/opt/iot-gateway ExecStart/opt/iot-gateway/gateway Restartalways RestartSec10s EnvironmentASPNETCORE_ENVIRONMENTProduction [Install] WantedBymulti-user.target加上WatchdogSec也是可選的它能利用systemd的軟看門(mén)狗機(jī)制程序內(nèi)每N秒調(diào)用一次sd_notify(WATCHDOG1)超時(shí)后systemd強(qiáng)殺主進(jìn)程并重啟。這種方式比外部進(jìn)程輪詢(xún)更準(zhǔn)確適合對(duì)通訊可靠性要求高的SCADA場(chǎng)景。我自己做網(wǎng)關(guān)的經(jīng)驗(yàn)里被反復(fù)驗(yàn)證的規(guī)律是可視化配置解決“接入慢”的問(wèn)題而健康檢查解決“壞了不知道”的問(wèn)題這兩個(gè)能力比某個(gè)具體協(xié)議實(shí)現(xiàn)得多么完美更重要。網(wǎng)關(guān)類(lèi)項(xiàng)目真正的成本不在開(kāi)發(fā)而在現(xiàn)場(chǎng)維護(hù)和診斷——把這些工具做進(jìn)產(chǎn)品里后面的日子會(huì)好過(guò)得多。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取