1. 先说清楚那些无通信接口的老设备卡在了哪一步1.1 没有网口不代表没有数据接口多数设备藏着RS485干过现场改造的人应该都有这种经历业主指着车间里一台用了快二十年的温控柜说这设备没有通信接口数据上不了云。等你掀开柜门绕到仪表和PLC后面一看大概率能找到一组A、B接线端子或者一个九针串口母座。很多老设备所谓的无通信接口其实是指没有以太网口、没有RJ45、没有TCP/IP能力不代表它连串口都没有。像老款温控仪、变频器、智能电表、部分中小型PLC出厂时几乎都会保留RS485接口跑Modbus RTU协议。因为Modbus从1979年提出到现在已经成为工业现场设备事实上的通信标准。哪怕设备品牌已经倒闭、说明书早就没了只要底板上标着A/B多半就是Modbus RTU的差分信号线。所以遇到无通信接口的老旧设备第一反应不该是换设备而是先确认现场有没有RS485、RS232这类串口以及有没有暴露Modbus寄存器地址。这一步判断正确后面所有事情都能顺下来。1.2 为什么Modbus能活几十年成了老设备事实标准Modbus能活到今天核心原因是简单到几乎没有学习成本。Modbus RTU的数据帧结构极其直白设备地址、功能码、数据区、CRC校验。一个功能码05写单个线圈功能码03读保持寄存器功能码04读输入寄存器大约不到十种功能码覆盖了95%的工业读写需求。对于单片机开发来说Modbus协议栈甚至不需要操作系统一个定时器加串口中断就能跑起来。这导致二十年前的仪表厂、PLC厂没有理由不用它。另一个关键因素是Modbus天生适合RS485总线。RS485是差分信号抗干扰能力强最远能到1200米左右一条总线上可以挂32个节点标准驱动下足够覆盖一个车间里的大部分设备。而老旧设备往往分布在几十米甚至上百米的范围内用Modbus RTU加手拉手接线比用4-20mA模拟量省线得多比用网线也更能忍受现场的电机启停干扰。换句话说老设备选择Modbus不是落后而是在当时条件下最合理的工程决策。1.3 无接口场景的三种出路换设备、加数采模块、上协议网关确认完接口情况后通常有三条路可以走。换设备最省心但最贵业主一听要重新布线、停产期、调试基本就摇头了。加数采模块适合完全没有Modbus口、只有4-20mA或开关量信号的设备在仪表和网关之间多一层模拟量采集成本不低但也能接受。如果是已经有Modbus RTU串口但缺网口的设备最省事的路线就是加一个Modbus转MQTT网关直接把串口数据翻译成MQTT报文通过Wi-Fi、4G或以太网上传到MQTT服务器。我这次做的项目就是第三种情况。现场有一批老式压力变送器、三台PLC和几个电能表全部是RS485接口协议是Modbus RTU但车间没有敷设工业以太网而且设备分布在三个不同区域。最终方案是每个区域放一台Modbus转MQTT网关网关通过RS485总线把区域内设备串起来再通过4G把采集数据发布到云端MQTT服务器。整个过程不需要动原有设备程序也不需要新增PLC模块这是它最大的价值。2. Modbus转MQTT网关到底在做什么别把它的能力想小了2.1 网关的职责不只是改变协议格式很多人以为协议转换就是把Modbus读回来的寄存器值换成JSON然后发给MQTT Broker。这个理解太浅。一台及格的Modbus转MQTT网关内部至少要完成四件事轮询采集、协议解析、数据映射、周期上报。轮询采集是最容易被忽视的部分。Modbus RTU是主从模式网关作为主站必须按照设定的周期挨个问询从站设备。每个从站设备有地址、寄存器起始地址、寄存器数量、功能码这些参数网关要能维护一张问询表。假设现场有10台设备每台设备要读20个寄存器那么网关每个周期至少要发出10条读命令每条命令之间还要留出串口切换和从站应答的时间窗口。如果现场RS485总线上有设备响应慢或掉线网关还得有超时重试机制不能因为一台设备没响应就把整条总线堵死。数据映射才是真正考验网关设计的地方。Modbus读回来的本质是16位寄存器它的实际含义可能是32位浮点、16位有符号整数、32位长整数甚至可能被拆成两个寄存器存放。而且不同厂商PLC的字节顺序可能不一样有的高字节在前有的低字节在前。网关如果不在这一层做字节交换和数据类型转换就算数据采集上来了云端看到的数字也完全是乱的。后面我会专门讲这个坑。2.2 从Modbus RTU到MQTT一条数据的一生我用一个具体例子描述数据流。假设有一台设备地址是1要读它的温度值寄存器地址是40001对应Modbus协议里的保持寄存器地址0数据类型是16位无符号整数。网关先通过RS485发送一条Modbus RTU请求帧01 03 00 00 00 01 84 0A。其中01是设备地址03是读保持寄存器功能码00 00是寄存器起始地址对应4000100 01是读1个寄存器84 0A是CRC16校验。设备收到后回复一个帧包含数据字节和CRC。网关把回复帧里的原始字节取出来按照配置好的数据类型和字节顺序转换成真正的温度值。可能实测是25.6度也可能因为字节顺序反了变成-12625之类的怪数字。转换正确后网关把数据整理成JSON形如{ device: 1, timestamp: 1699840000, data: { temperature: 25.6 } }然后网关把它发布到MQTT Broker的某个Topic比如factory/area1/device1/data同时设置QoS级别和KeepAlive心跳。云端订阅那个Topic的应用程序就能实时收到温度值。如果网络断了网关里还得有本地缓存等重连后把断线期间的数据补发上去避免数据丢档。这就是一条数据从RS485到MQTT的完整生命周期。你会发现网关介于物理层、数据链路层和应用层之间任何一个环节配置错误数据都会在某个节点悄悄消失或变形。2.3 网关和DTU、PLC加模块有什么本质区别经常有朋友问我用一个串口DTU不行吗把RS485转成TTL转成4G不也能把数据发出去这里的区别在于DTU只解决透明传输问题它把串口收到的Raw Byte原封不动通过Socket发给服务器不做Modbus协议解析也不生成MQTT消息。服务器端还得自己写一套TCP解析程序去拆Modbus报文等于把工作量从设备端搬到了软件端。PLC加通信模块的方案则太重。很多中型PLC有RS485模块和以太网模块可以通过编程把Modbus RTU数据读上来再通过Socket或Modbus TCP转发出去但这里面有几个问题第一PLC程序要重写可能影响原设备的逻辑控制第二老旧PLC的存储和计算能力有限要考虑内存占用和扫描周期第三PLC本身不具备MQTT客户端能力通常还要再配一个边缘网关或者数据采集软件才能在云端实现MQTT发布。这样算下来成本和时间都上去了。相比之下一台嵌入式Modbus转MQTT网关是专门为这个场景设计的上电即跑协议栈有独立的Modbus主站功能内置多条主题配置和JSON模板还能设置断线缓存。它不需要编程环境web配置页面就能搞定一切。这就是它在老旧设备改造中能快速落地的原因。3. 选型之前先按这五条硬边界把需求焊死3.1 物理层和协议层RS485/RS232/网口的选型第一关选网关第一个问题不是支持不支持MQTT而是它能不能连接你现场的设备。市面上很多网关标称Modbus网关但物理层可能只有RS485没有RS232或者RS485接口是共地非隔离。对于老旧设备接口形式很杂有的仪表是RS232九针有的智能模块是RS485端子还有的PLC编程口是自定义物理层需要原厂编程电缆转RS485。我的建议是先把现场每个设备的通信接口拍照存档区分RS485两线制、RS485四线制、RS232、RS422再看网关接口数量是否满足分组要求。比如你现场有两条RS485总线为了让某条总线波特率可以是9600、另一条19200就不能买只有一路RS485的网关至少得买双串口型号避免为了迁就低速设备拖慢高速设备。同时问清楚网关的RS485接口有没有做隔离。工业现场地电位差很常见两个设备相隔很远时RS485的A/B线对地电压可能差到十几伏。如果网关没有隔离轻则通信误码重则烧毁网关的主芯片。选型时隔离RS485几乎是刚需别省这个钱。3.2 点位和通道数按设备和寄存器量估算别只数设备台数很多人说我现场就5台设备网关肯定够用结果配置的时候发现一台设备的寄存器就分成了好几段有连续地址也有不连续地址。Modbus协议规定一次读命令最多读125个寄存器功能码03/04如果设备的寄存器不连续就要分成多条读命令。网关的点位概念通常指的是它能配置的采集点数量一个采集点可以是一个寄存器或一组寄存器。你不仅要算设备数量还要算每台设备需要读的寄存器数量、有几个功能码、有几个起始地址段。比如一个电能表要读电压、电流、功率等参数可能需要读3个不同起始地址段那就是三个采集点。我遇到过现场有6台变频器每台变频器要读运行频率、电流、母线电压、运行状态每个参数地址还不连续最终用了20多个采集点。如果当初按设备台数选了一个廉价入门网关采集点上限只有16个后期就会很被动。所以选型前把每台设备的寄存器地址表调出来逐台统计采集点宁可多留30%余量也别选卡在临界值的型号。3.3 供电、安装、工作温度的现场条件网关要装在现场就得考虑现场环境。老旧车间的电气柜普遍空间紧张导轨上已经挤满了空开和继电器所以网关最好选DIN35导轨式安装宽度尽量窄。供电电压通常选择DC24V但有些现场没有24V开关电源只有220V那就需要带AC220V输入的型号或者外加一个微型电源模块。工作温度这个参数看起来无关紧要实际很关键。有的网关标称-10到55度在北方车间里冬天没有保温措施现场温度可能接近0度还没问题但如果网关被装在阳光直射的仪表箱里夏天内部温度能到60度普通消费级芯片就会死机重启。做设备改造至少要选工业级温度范围-40到85度的网关尤其是4G型号功耗高发热量大散热条件不好的地方容易出问题。此外还要关注天线位置。4G/ Wi-Fi网关需要外置天线柜体如果是不锈钢全封闭结构无线信号会衰减严重。选型时建议用带SMA天线接口的网关天线可以引到柜外不要选那种内置PCB天线的紧凑型网关否则信号差到让你怀疑人生。3.4 上行MQTT参数Topic结构、QoS、用户名密码和证书网关采集到数据后要发布到哪个MQTT服务器该服务器的连接参数必须和网关兼容。这一条坑很多人踩过有些云平台要求TLS加密连接而低价网关往往只支持TCP连接不带TLS证书配置也没有结果买回来发现连不上平台。选型时要确认网关的MQTT客户端支持哪些核心参数支持标准MQTT 3.1.1或5.0支持自定义ClientID、Username、Password支持TLS/SSL最好还能上传CA证书和客户端证书支持自定义Topic前缀最好Topic里能嵌入设备ID或时间戳变量支持设置KeepAlive和Clean Session支持遗嘱消息Will Message这样设备掉线时云平台能收到离线通知。Topic结构设计也要提前规划。比如统一用{project}/{location}/{deviceType}/{deviceId}/data网关配置里可以把通配符映射到固定字段。如果平台侧有数据清洗规则Topic乱的话后面维护就是灾难。另外MQTT QoS等级要务实。网关默认发布消息用QoS 0最多一次在高丢包率的无线网络下会丢数据QoS 2恰好一次又占资源不必要。一般选QoS 1比较折中配合断线缓存基本能保证数据不丢。3.5 可靠性断线缓存、看门狗、离线告警能力老旧设备改造最怕的就是网关悄悄罢工生产现场数据丢失没人知道。选型时一定要问清楚几项可靠性指标。第一断线缓存。网关在4G网络闪断时采集到的数据能否缓存在本地网络恢复后自动按时间戳补传缓存容量多大能存多少条有的网关支持SD卡扩展有的只支持内存缓存掉电就丢。对于不允许丢数的项目必须选择带Flash掉电保存功能的网关。第二硬件看门狗。工业现场电磁干扰强网关偶尔死机不可怕可怕的是死机后不重启。一个带硬件看门狗的网关能在程序卡死后自动复位业务中断时间不超过几十秒。这一点很多参数表里不写要直接问客服或看说明书。第三离线告警。网关本身作为MQTT客户端应该有自己的状态上报功能例如每隔30秒发一条/status消息里面包含信号强度、内存使用率、当前采集状态。云平台如果一段时间没收到状态消息就能自动生成网关离线告警。这个功能很重要否则网关坏了你还以为设备数据一直正常。4. 实战配置一把过从接线到云端看到数据4.1 硬件接线与现场勘测我们这次改造接线的第一步是把RS485总线理清楚。把每个设备串成手拉手结构从网关A端子出来接到第一个设备再从第一个设备的另一个A端子串到第二个设备B端子同理。注意手拉手不要搞成星形否则总线反射会导致通信不稳定。接线时用万用表量一下A/B之间的电压正常空闲状态应该在1.5V到5V之间。如果发现电压接近0可能总线被某个设备拉死如果量出来有交流干扰说明有强电干扰需要检查屏蔽层接地。RS485屏蔽线建议单端接地一般是柜内电源地或PE排另一头悬空避免形成地环路。另外总线终端电阻很有讲究一条RS485总线两端要各接一个120欧终端电阻。如果你的设备或网关内部没有集成这个电阻就要在第一个和最后一个设备上外接。很多现场通信不稳定加两个终端电阻就解决了。接线完成后先不要急着配网关用笔记本电脑加一个USB转RS485转换器通过Modbus Poll软件直接读一下设备确认原设备能正常响应。这一步能帮你排除设备坏了地址不对波特率不对的问题不要一上来就怀疑网关。4.2 用Modbus Poll模拟一个从站先验证通信链路Modbus Poll是一个非常好用的Modbus主站调试工具支持RTU和TCP配置也很简单。在老旧设备改造中它可以扮演两个角色一是作为主站去读真实设备检查寄存器返回的原始值二是模拟一个从站用来测试网关的采集功能。我习惯先把网关通过RS485接到电脑上的USB转485在Modbus Poll里选择串口参数比如波特率9600、数据位8、无校验、停止位1然后填写从站地址和寄存器地址点击连接。如果返回的数据看起来正常说明链路OK真实设备的寄存器地址也没问题。如果读不到数据就去查设备手册确认地址和功能码。当需要单独测试网关时可以打开Modbus Slave工具模拟一个真实从站设置好地址、寄存器起始地址和数据类型填入一些有辨识度的数值比如温度填25.6压力填1.02。然后让网关去采集这个模拟从站如果云端或者配置界面上能看到这些值说明网关的采集链路是通的。注意模拟从站的寄存器区要和网关配置的功能码对应例如功能码03对应保持寄存器功能码04对应输入寄存器。我用这个方案排掉了一个大坑现场有一台设备设备上用物理按键看的温度是20度但网关采回来死活是20.5度。后来用Modbus Poll直接去读发现真实设备返回的就是20.5度物理表头显示的是四舍五入后的值。这说明网关本身没有错设备的值就是这样省得我们白改半天配置。4.3 在网关里建寄存器映射表把轮询周期设明白网关的采集配置一般是通过Web界面完成的。以实际配置为例我需要新建一个Modbus从站分组填入设备地址1选择功能码填写起始寄存器和寄存器数量。然后在下方的映射表里定义数据类型、字节顺序、缩放比例、映射到的JSON字段名。这里有个容易犯的错寄存器数量填多了或填少了。Modbus一次最多读125个寄存器如果设备的保持寄存器从40001到40010是连续的你当然可以填起始地址0、数量10但如果中间夹杂了只读输入寄存器就要拆成两条采集命令不能偷懒。另外有些设备寄存器地址是1-based的而Modbus Poll里可能显示0-based网关配置时要搞清楚偏移关系否则会差1个地址。轮询周期的设置也要动脑子。假设你的网关连接了8个Modbus从站每个从站有2条采集命令那么一个完整轮询周期就是16条串口命令。每条命令包括发送和应答加上延时按19200波特率跑一个周期可能耗时几百毫秒。你可以把实时性要求高的设备放在前面、加上快速轮询分组把低压的、温度变化慢的设备放在慢速轮询分组周期设成5秒一次。不要所有设备都挤在同一个快周期里否则总线会异常繁忙反而增加冲突概率。在网关的MQTT配置页面把Broker地址、端口、用户名密码填进去然后设置Topic模板。我用的是iot/project/area1/{deviceId}/data其中{deviceId}会自动替换成JSON里的设备标识。上报内容可以选择变化上传或周期上传。建议温度类、压力类信号用变化上传加最小变化幅度比如变化超过0.1才上报能大大减少流量状态类和开关量用每次变化都上报保证及时性。4.4 用MQTTX订阅Topic检查JSON数据是否正常配置完网关后我用MQTTX这个桌面客户端去连接云端Broker实时订阅网关上报的Topic。MQTTX比命令行好用可以看到JSON结构化内容也支持多种主题过滤非常方便。连接Broker时填上服务器地址、端口如果是TLS还要选择证书或忽略证书测试阶段可以忽略。然后把Topic前缀写进去加通配符#就能看到所有网关上报的数据。看到数据后先用肉眼比对几条关键数据比如设备表显示的温度、压力与云端值是否一致再检查时间戳、设备ID是否正常。一个常见问题是QoS不匹配导致数据看不到网关发布时用了QoS 1但MQTTX订阅时用了QoS 0这并不影响互相接收因为订阅和发布可以独立指定QoS。但如果网关的Broker是云厂商提供的要确认Topic权限是否正确比如有的平台要求设备发布权限与订阅权限分开网关发布Topic和状态Topic不能直接开全部权限否则连不上。在MQTTX里看到数据并不能证明端到端流程已经OK。还要做断网测试把网关网络断开等30秒观察云平台是否收到遗嘱离线消息同时测试网关本地缓存了多少条数据恢复网络后这些数据是否补传上来。这一步做完基本可以放心移交给运维了。5. 最容易翻车的五类问题附带完整排查链路5.1 数据错位字节顺序和数据类型映射在作怪这是Modbus转MQTT项目里最高频的坑。比如读一个32位浮点两个寄存器顺序一个是AB CD一个是CD AB具体还分成ABCD、BADC、CDAB、DCBA四种字节序。如果你在网关里选错字节序25.6就可能变成1.7E-37之类的天文数字或者明明是正数突然变成负数。排查思路分三步先用Modbus Poll读原始寄存器值确认设备返回的原始整数是多少判断这个原始值是16位还是32位是整数还是浮点然后根据设备手册确定字节顺序再到网关映射表里选对应的数据类型和字节序。我遇到过一个典型案例某牌子的温控器寄存器地址30000里存的是一个整数高位字节在低地址低位字节在高地址。网关默认按高字节在前转换结果读到的值比实际大了256倍。排查时我直接读原始值发现Modbus Poll显示十进制2560而电动调节阀面板却显示10.0后来把字节顺序改成低位在前数值立刻变成10。所以怀疑数据异常时第一个动作是回到Modbus原始值别直接改网关的缩放系数。5.2 通信超时波特率、校验位、终端电阻逐个查RS485通信失败的排查链路我的习惯是从物理层往协议层查。先用万用表量A/B电压确认不短路、有偏置再检查所有设备地址是否冲突两个设备都不能用同一个地址然后把网关和电脑串口接到同一台设备上用Modbus Poll去读。如果Modbus Poll也读不到多半是波特率或校验位完全不匹配。老设备有些喜欢Even校验有些是None只在拨码开关或参数表里藏着一格两位。另一个隐藏坑是数据位为8位时要和校验位配合有些设备用8E1有些用8N1配置错了通信就会静默失败。如果电压正常、参数也对还是超时那就要检查终端电阻和线缆长度。我自己调试时就遇到过一台设备在室外线径太细总长超过300米波特率却设成19200结果怎么点读都超时。后来把波特率降到9600线缆两端加120欧终端电阻立即恢复通信。记住线缆越长波特率要越低总线两端加电阻空闲状态要保证A高于B。5.3 CRC校验真的不用自己写吗很多网关宣传说自动CRC校验这是好事但也带来一个盲区。有些设备为了简单CRC可能不太标准有些设备把CRC校验挂在地址字段后面有些又是反字节序。网关如果校验不通过可能直接丢弃数据包表现为有时能通、有时不通。排查方法是抓总线报文。你可以用USB转485的串口监视器抓一下设备回复的原始帧把CRC两个字节拉出来用Modbus CRC算法工具在线算一下对比设备发的CRC是否正确。如果设备本身CRC就不对那问题不在网关而在设备如果设备CRC正确但网关不认就去找网关固件有没有宽松CRC模式或者忽略CRC的选项。虽然不建议长期全局忽略但调试阶段可以确认一下问题范围。我遇到过一次一台国产仪表在某个温度段会偶尔返回一个坏的CRC原因竟然是仪表内部晶振在低温下漂移导致波特率偏了一点数据帧错位。这时不管网关怎么宽容都没用只有把设备移到恒温环境才恢复。所以CRC问题背后可能是时钟精度、电平驱动能力等更深层的现场问题。5.4 MQTT老掉线心跳、KeepAlive和遗嘱消息网关连上MQTT Broker后偶尔会掉线重连这本身正常但如果频繁掉线就要排查了。第一个看KeepAlive设置和Broker配置是否匹配。MQTT协议中客户端必须在每个KeepAlive时间内发一次心跳包否则Broker会主动断开连接。有些网关默认心跳周期是60秒但你在Broker端配置了30秒超时网关就会频繁掉线。第二个常见原因是无线网络质量差。使用4G网关时SIM卡的APN参数、DNS解析、公网IP稳定性都要检查。如果Broker是部署在内网的服务器还要看防火墙有没有放行TCP 8883等端口。我排过一个掉线问题最后发现是SIM卡流量被运营商断了月包用超之后4G网络变成有信号但无数据网关不断尝试重连但永远连不上。这种问题光查网关配置没用要查流量余额。第三个要注意的是遗嘱消息。网关连接Broker时应设置Will Topic和Will Message例如{deviceId}/status消息内容offline。这样网关非正常掉线时Broker会代替网关发布一条离线消息让你的云平台感知到。如果网关不支持遗嘱消息你得额外实现一套超时判定逻辑否则很多掉线要被动发现。5.5 上电启动和程序升级时网关丢数据老旧设备改造后有一个容易被忽略的场景现场突然停电或者设备上电瞬间网关还没来得及初始化就启动了结果漏掉了前几秒的数据。解决思路是网关最好保存上次采集到的值上电后先把缓存值和当前值一起打包发出去而不是等下一个新值才上报。很多网关具备重启后立即发布一次当前值的功能选型时可以重点考虑。另外程序升级时如果配置没有备份可能会让现场配置全部丢失这是灾难级的操作失误。我习惯在每次配置完成后导出网关配置文件本地存一份云盘存一份。部分网关支持配置导入导出选型时最好带上这个功能能省掉大量的重复劳动。还有一个容易忽视的是主板RTC电池。如果网关使用时间戳作为上行数据的时间标识而RTC电池没电重启后时间会回到1970年导致云端时间排序错乱。低成本网关可能没有RTC数据时间戳依赖MQTT Broker接收时打的标签高可靠性网关需要支持SNTP校时或有电池保持RTC。选型时问一句有没有RTC支持不支持NTP校时能帮你避雷。6. 关于选型和落地最后再唠叨几句6.1 选型需求表模板如果你正要评估项目建议先做一张需求表别急着让销售报价。下面是我常用的模板可以直接复制到Excel里填项目填写内容现场设备清单台数、品牌型号、通信接口类型RS485/RS232/以太网设备协议版本Modbus RTU / Modbus TCP / 自定义地址映射采集点位总数每个寄存器段单独计数预留30%余量数据上报频率多长时间变化量需要上传秒级/分钟级上行网络方式以太网 / Wi-Fi / 4G / LoRaMQTT服务器地址、端口、用户名密码、TLS证书要求Topic命名规范前缀、设备标识、数据/状态/遗嘱主题断线缓存要求缓存时长、是否要求掉电不丢环境条件工作温度、供电电压、安装方式、天线位置远程运维要求是否支持远程配置导出、远程固件升级预算上限单台网关预算包含流量卡成本这张表填完你基本就清楚要选什么样的产品了。然后拿这张表和三种网关的参数对比胜出的很可能就是最合适的而不是功能最花哨的。6.2 我的一些实际体会做了这么多年现场看了太多选型失误导致项目烂尾的例子。有人贪便宜买一台不支持断线缓存的网关网络一抖数据就缺档有人迷信大品牌买了一台配置极其复杂的网关光研究配置就花了两天还有人把网关装在不通风的铁皮箱里夏天高温死机只能重新开孔加风扇。我个人经验是老旧设备改造项目里Modbus转MQTT网关的选型成败有五成取决于能不能接上设备三成取决于数据能不能按预期格式上报剩下两成才是稳定性与售后。所以第一步永远是到现场摸清设备底细而不是在网上比来比去。另外别指望一台网关解决所有问题。如果现场既有Modbus设备又有BACnet楼宇设备既有RS485又有网口就选模块化边缘网关一个机架配不同协议模块而不是一台多功能网关死磕到底。将来扩展平台或新增设备时也不至于推翻重来。最后再分享一个实用小技巧正式买样机前可以先从一些大厂的试用计划申请一台设备或者淘一台二手的同型号网关在自己的办公桌上搭个最小环境一个Modbus模拟器、一台MQTT Broker如EMQX一台网关。花两个小时把整个数据链路跑通再决定买不买。现场问题千奇百怪但只要你把链路逻辑理清楚Modbus转MQTT这种改造方案其实是老旧设备上云的最短路径。