1. 工业传感器数据采集方案的整体设计与选型思路1.1 为什么工业现场的数据采集不能照搬互联网那套干了十几年工业自动化我见过太多项目在数据采集这一环翻车。互联网那套 HTTP 轮询、RESTful 接口放到车间里根本跑不通——PLC 的扫描周期是毫秒级你一个 HTTP 请求发过去光 TCP 三次握手加 JSON 序列化就几十毫秒没了更别说车间里电磁干扰大、网络抖动频繁丢一个包可能就意味着一条产线的关键参数丢失。工业传感器数据采集的核心诉求跟互联网完全不同确定性、实时性、可靠性。确定性指的是采集周期必须稳定不能这次 100ms 下次 500ms实时性要求从传感器到上位机或云端的延迟可控可靠性则意味着断网、断电、设备重启后数据不能丢至少不能丢关键数据。所以这套方案的设计思路很明确分层采集、协议归一、边缘缓冲、按需上云。底层用 Modbus RTU/TCP 这类轻量协议跟传感器和 PLC 打交道中间层用 OPC UA 做语义化建模和跨厂商互通上层用 MQTT 做发布订阅式的数据分发。这三层各司其职谁也不越界。1.2 三种核心协议的分工与选型逻辑很多人一上来就问“Modbus、OPC UA、MQTT 到底选哪个”这个问题本身就问错了。它们不是竞争关系而是不同层级、不同场景的互补工具。Modbus是工业现场的“普通话”。它简单、成熟、几乎所有的 PLC、仪表、变频器都支持。Modbus RTU 跑在 RS485 总线上一主多从接线简单成本极低Modbus TCP 跑在以太网上速度更快适合设备密集的车间。但 Modbus 的短板也很明显没有数据类型定义寄存器里放的是整数还是浮点数、单位是什么、量程多少全靠文档约定换个厂家就得重新对表。OPC UA是工业 4.0 的“世界语”。它自带信息模型每个变量都有明确的语义、数据类型、工程单位还支持订阅模式和内置安全机制。西门子、倍福、罗克韦尔这些主流厂商的新一代控制器都原生支持 OPC UA。但 OPC UA 对硬件资源要求高老设备跑不动而且配置复杂度比 Modbus 高一个数量级。MQTT是数据上云的“快递员”。它基于发布订阅模式一个 Broker 可以连接成千上万个客户端消息开销极小最小报文只有 2 字节支持 QoS 0/1/2 三级消息可靠性。特别适合把采集到的数据从边缘网关送到云端或数据中心。但 MQTT 本身不解决设备接入问题它只管传输不管数据从哪来、是什么含义。我的选型原则是现场设备能走 Modbus 就走 Modbus新设备优先 OPC UA上云统一走 MQTT。如果现场有西门子 840D sl 或 828D 这类数控系统直接上 Sinumerik OPC UA 客户端省去中间转换环节。1.3 方案整体架构与数据流向整套方案的架构可以概括为“三层两网”设备层各类传感器温度、压力、流量、振动、PLC西门子 S7-1200/1500、三菱 FX 系列、欧姆龙 CP 系列、智能仪表E5CC 温控器、电表、流量计。这一层输出的是 Modbus RTU/TCP 或 OPC UA 协议的数据。边缘层工业网关或工控机推荐用 Ubuntu 或 Windows IoT运行采集程序。Modbus 侧用轮询方式读取寄存器OPC UA 侧用订阅方式接收数据变化。采集到的数据先写入本地 SQLite 或时序数据库做缓冲然后通过 MQTT 发布到 Broker。平台层MQTT BrokerEMQX 或 Mosquitto负责消息路由后端服务订阅主题后写入时序数据库InfluxDB、TDengine再对接可视化大屏或 MES 系统。两网指的是OT 网络设备层到边缘层通常用 Modbus RTU 的 RS485 或 Modbus TCP 的工业以太网和IT 网络边缘层到平台层走 MQTT over TCP/TLS。两网之间通过网关做隔离避免 IT 侧的流量风暴影响 OT 侧的实时性。注意OT 网络和 IT 网络一定要做物理或逻辑隔离。我见过一个项目IT 侧有人跑了个网络扫描工具直接把 Modbus RTU 总线上的轮询周期从 100ms 拖到了 2s导致温控器失控。这个坑后面会详细说。2. Modbus 协议深度解析与实操要点2.1 Modbus RTU 报文结构与地址映射的坑Modbus RTU 的报文格式看起来简单但细节里全是坑。一帧完整的 RTU 报文包括从站地址1 字节、功能码1 字节、数据域N 字节、CRC 校验2 字节。帧与帧之间靠 3.5 个字符时间的静默间隔来区分。功能码常用的就几个0x01 读线圈、0x02 读离散输入、0x03 读保持寄存器、0x04 读输入寄存器、0x05 写单个线圈、0x06 写单个寄存器、0x10 写多个寄存器。读传感器数据最常用的是 0x03 和 0x04。地址映射是新手最容易翻车的地方。Modbus 协议文档里经常看到 40001、30001 这种地址这是“PLC 地址”或“逻辑地址”跟报文里实际传输的“协议地址”差一个偏移量。规则是地址类型逻辑地址范围协议地址范围功能码线圈00001-099990000-99980x01离散输入10001-199990000-99980x02输入寄存器30001-399990000-99980x04保持寄存器40001-499990000-99980x03也就是说逻辑地址 40001 对应的协议地址是 040002 对应 1以此类推。很多 Modbus Poll 的注册版本里直接填 40001 能读到数据是因为软件帮你做了转换。但如果你自己写代码就必须用协议地址。实操心得拿到一个 Modbus 设备第一件事是确认它的地址是从 0 开始还是从 1 开始。有些国产仪表厂家文档写的是“寄存器地址 1”实际协议地址就是 1有些写的是“40001”实际协议地址是 0。最稳妥的办法是用 Modbus Poll 或 Modbus Slave 先手动试读确认地址偏移。2.2 Modbus TCP 与 RTU 的差异及转换技巧Modbus TCP 在 RTU 的基础上加了一个 7 字节的 MBAP 头事务标识符 2 字节、协议标识符 2 字节、长度 2 字节、单元标识符 1 字节去掉了 CRC 校验因为 TCP 本身保证了数据完整性。实际项目中经常遇到“设备只有 RTU 接口但上位机只有网口”的情况。这时候有两种方案一是用串口服务器如有人 USR-N510、MOXA NPort做 RTU over TCP 转换二是用网关软件做协议转换。串口服务器的优点是稳定、免驱、配置简单缺点是每个串口服务器只能接一条 RS485 总线设备多了成本高。如果现场有西门子 S7-1200/1500可以用 CM 1241 RS485 模块扩展串口然后在 PLC 里写 Modbus RTU 主站程序再通过 OPC UA 或 S7 协议把数据吐出来。三菱 FX3U 的话加 FX3U-485ADP-MB 模块用 ADPRW 指令做 Modbus RTU 通讯梯形图程序网上有很多模板可以参考。2.3 用 Modbus Poll 和 Modbus Slave 快速验证通讯调试 Modbus 的第一步永远是“先通再调”。我习惯用 Modbus Poll 做客户端、Modbus Slave 做服务端在同一台电脑上模拟主从通讯确认参数配置正确后再接真实设备。具体步骤打开 Modbus Slave设置从站地址为 1功能码选 03保持寄存器起始地址填 0数量填 10。在数据区手动填入几个测试值比如 100、200、300。打开 Modbus Poll连接方式选 Modbus TCPIP 填 127.0.0.1端口 502。设置从站地址 1功能码 03起始地址 0数量 10。如果一切正常Modbus Poll 的数据区会显示 Modbus Slave 里填的值。这个流程看起来简单但能帮你排除 90% 的配置问题。等模拟通了再把 Modbus Poll 的 IP 改成真实设备的 IP或者把连接方式改成 Serial Port 接 RS485 转换器。注意Modbus Poll 和 Modbus Slave 是商业软件有 30 天试用期。网上流传的注册码和破解版本存在安全风险建议公司采购正版授权或者用开源的 QModMaster、pymodbus 替代。我自己写采集程序时Python 环境下直接用 pymodbus 库几行代码就能跑起来。2.4 一主多从的轮询策略与超时处理Modbus RTU 是严格的一主多从协议总线上只能有一个主站。主站轮询多个从站时必须等上一个从站响应或超时后才能发下一帧。如果某个从站掉线主站不能死等必须设置合理的超时时间。我的经验值是波特率 9600 时超时设 300ms19200 时设 200ms115200 时设 50ms。超时时间太短会导致正常从站被误判为掉线太长则拖慢整个轮询周期。假设总线上有 10 个从站每个从站读 10 个寄存器波特率 9600每帧大约 25 字节。9600 波特率下一个字节 10 位1 起始位 8 数据位 1 停止位传输 25 字节需要 25 × 10 / 9600 ≈ 26ms。加上从站处理时间和 3.5 字符间隔单次轮询大约 40ms。10 个从站轮一遍就是 400ms。如果要求每个从站的数据刷新周期不超过 1s这个配置是可行的如果要求 200ms 刷新一次就必须提高波特率或减少从站数量。实操心得轮询顺序也有讲究。把响应快的从站放在前面响应慢的放在后面可以减少总线空闲时间。另外对于变化缓慢的模拟量如温度可以降低轮询频率对于开关量或报警信号提高轮询频率。这种差异化轮询策略能显著降低总线负载。3. OPC UA 在工业数据采集中的落地实践3.1 OPC UA 的信息模型为什么比 Modbus 香Modbus 最大的问题是“数据没有语义”。你读到一个寄存器值是 235它可能是 23.5°C也可能是 2350rpm还可能是 0x00EB 的位组合。每次对接新设备都要翻手册、对地址、算量程累且容易出错。OPC UA 从根上解决了这个问题。它用地址空间Address Space来描述设备每个节点Node有 NodeId、BrowseName、DisplayName、DataType、EngineeringUnits 等属性。客户端连上服务器后可以浏览整个地址空间自动发现有哪些变量、每个变量是什么类型、单位是什么。这就是所谓的“语义互操作”。举个例子西门子 S7-1500 的 OPC UA 服务器里一个温度变量可能长这样NodeId: ns3;sDB1.TemperatureBrowseName: TemperatureDataType: FloatEngineeringUnits: °CAccessLevel: CurrentRead客户端不需要任何手册直接读这个节点就能拿到带单位的温度值。换一台设备只要它支持 OPC UA客户端代码几乎不用改。3.2 用 UaExpert 快速浏览服务器节点UaExpert 是 Unified Automation 出的免费 OPC UA 客户端Windows 64 位版本目前是 v2.0.2 build 665。虽然界面不算现代但功能齐全是我调试 OPC UA 的首选工具。连接步骤打开 UaExpert右键 Servers → Add → Custom Discovery输入 OPC UA 服务器的端点 URL比如opc.tcp://192.168.1.10:4840。如果服务器启用了安全策略需要选择对应的 Security PolicyNone、Basic128Rsa15、Basic256Sha256 等和认证方式匿名、用户名密码、证书。连接成功后左侧地址空间树会展开所有节点。找到你的目标变量拖到中间的 Data Access View 里就能实时看到数值变化。右键变量可以查看属性包括 DataType、EngineeringUnits、AccessLevel 等。注意西门子 S7-1500 的 OPC UA 服务器默认可能没开启需要在 TIA Portal 里勾选“激活 OPC UA 服务器”并设置端口号默认 4840和安全策略。另外S7-1200 只有固件 V4.4 以上才支持 OPC UA 服务器功能老固件只能做客户端。3.3 Sinumerik OPC UA 客户端的特殊配置数控机床的数据采集是个独立赛道。西门子 840D sl、828D、840D 这些系统自带 OPC UA 服务器但节点结构和普通 PLC 不一样。你需要用 Sinumerik OPC UA 2.2 Client 或者直接通过 UaExpert 连接浏览Sinumerik命名空间下的节点。关键节点包括/Channel/Configuration/ChannelAxisName通道轴名称/Channel/State/ActFeedRate实际进给率/Channel/State/ActSpindleSpeed实际主轴转速/Channel/ProgramInfo/ProgramName当前程序名/Tool/State/ActToolId当前刀具号这些节点的 NodeId 通常是ns2;s/Channel/State/ActFeedRate这种形式。采集频率建议不要超过 10Hz因为数控系统的 OPC UA 服务器资源有限高频读取会影响加工实时性。3.4 OPC UA 订阅模式与数据变化通知OPC UA 有两种数据获取方式Read主动读取和Subscription MonitoredItem订阅监控。Read 适合低频、按需读取订阅适合高频、持续采集。订阅模式的工作流程客户端创建一个 Subscription设置 PublishingInterval发布间隔比如 100ms。在 Subscription 下创建 MonitoredItem指定要监控的 NodeId、SamplingInterval采样间隔、QueueSize队列大小。服务器按照 SamplingInterval 采样数据变化时放入队列然后按照 PublishingInterval 打包发送给客户端。客户端收到 Publish Response 后处理数据。这种模式的好处是客户端不需要轮询服务器主动推送变化的数据网络开销小实时性高。但要注意 QueueSize 的设置——如果数据变化频率高于 PublishingInterval队列会堆积QueueSize 太小会丢数据太大则占内存。一般设 10 左右比较合适。实操心得OPC UA 订阅的 SamplingInterval 不要设得比 PublishingInterval 还小否则没意义。比如 PublishingInterval 是 100msSamplingInterval 设 50ms服务器采样两次才发布一次浪费资源。两者相等或 SamplingInterval 略大即可。4. MQTT 协议详解与数据上云实操4.1 MQTT 发布订阅模型与 QoS 等级选择MQTT 的核心是发布订阅模型发布者Publisher把消息发到某个主题Topic订阅者Subscriber订阅这个主题后就能收到消息。发布者和订阅者互不知道对方的存在全靠 Broker 做路由。这种解耦设计特别适合工业场景——传感器只管发数据云端服务只管收数据中间加个 Broker 就能灵活扩展。QoS服务质量是 MQTT 最关键的参数QoS 等级语义报文交互适用场景0最多一次PUBLISH高频传感器数据丢一两帧无所谓1至少一次PUBLISH → PUBACK一般业务数据允许重复但不能丢2恰好一次PUBLISH → PUBREC → PUBREL → PUBCOMP计费、报警等关键数据工业采集里温度、压力这类连续量用 QoS 0 就够了丢一帧下一帧马上补上。但报警信号、累计产量这类数据必须用 QoS 1 或 2。QoS 2 的开销是 QoS 0 的 4 倍以上非必要不用。4.2 在 Windows 和 Linux 上搭建 MQTT BrokerBroker 是 MQTT 的心脏。生产环境推荐 EMQX功能全、性能强、有 Web 管理界面测试环境用 Mosquitto轻量、配置简单就够了。Windows 上把 Mosquitto 设成本地服务从 Mosquitto 官网下载 Windows 安装包安装到C:\Program Files\mosquitto。编辑mosquitto.conf添加listener 1883和allow_anonymous true测试用生产环境要关掉匿名。以管理员身份打开 CMD执行sc create mosquitto binPath C:\Program Files\mosquitto\mosquitto.exe -c \C:\Program Files\mosquitto\mosquitto.conf\ start auto执行sc start mosquitto启动服务。之后开机自动运行不用手动开窗口。LinuxUbuntu上安装 Mosquittosudo apt update sudo apt install mosquitto mosquitto-clients sudo systemctl enable mosquitto sudo systemctl start mosquitto如果服务器不能联网需要离线安装。下载.deb包后用dpkg -i安装依赖缺失的话用apt-get install -f补齐。注意生产环境的 MQTT Broker 一定要开启认证和 TLS。匿名访问的 Broker 暴露在公网上分分钟被扫描到并滥用。EMQX 支持用户名密码、JWT、LDAP 等多种认证方式配置也不复杂。4.3 MQTT 主题设计与消息格式规范主题设计是 MQTT 落地最容易忽视的环节。好的主题结构应该具备层次清晰、可扩展、易订阅。我常用的主题模板factory/{车间编号}/{产线编号}/{设备编号}/{数据类型}例如factory/A1/line01/injection01/temperaturefactory/A1/line01/injection01/pressurefactory/A1/line01/injection01/status订阅时可以用通配符factory/A1/line01//temperature订阅 A1 车间 line01 产线所有设备的温度factory/A1/#订阅 A1 车间所有数据消息格式推荐 JSON可读性好扩展方便{ deviceId: injection01, timestamp: 1712345678000, temperature: 235.6, unit: °C, quality: good }如果带宽紧张可以用 MessagePack 或 Protobuf 做二进制序列化体积能压缩到 JSON 的 30% 左右。但调试难度增加建议只在数据量特别大时使用。4.4 用 MQTT Explorer 和命令行验证消息收发MQTT Explorer 是调试 MQTT 的神器图形界面能实时显示主题树和消息内容。下载安装后新建连接填 Broker 地址和端口如果开了认证就填用户名密码。连接成功后左侧是主题树右侧是消息列表。你可以直接在顶部输入主题发布消息也可以订阅通配符查看所有消息。命令行验证用 mosquitto_pub 和 mosquitto_sub# 订阅所有主题 mosquitto_sub -h 192.168.1.100 -t # -v # 发布一条消息 mosquitto_pub -h 192.168.1.100 -t factory/A1/line01/injection01/temperature -m {value:235.6}如果 Broker 开了认证加-u username -P password。开了 TLS 的话加--cafile ca.crt。实操心得调试 MQTT 时先用#订阅所有主题确认消息能正常收发。然后再逐步缩小主题范围排查是发布端问题还是订阅端问题。另外MQTT Explorer 的消息缓存有限高频消息会刷屏建议在 Broker 端做限流或降采样。5. 边缘采集程序的架构与核心代码实现5.1 采集程序的模块划分与线程模型一个稳定的边缘采集程序不能把所有逻辑塞在一个循环里。我的做法是分成四个模块每个模块独立线程采集线程负责 Modbus 轮询和 OPC UA 订阅回调把原始数据写入内部队列。处理线程从队列取数据做量程转换、单位换算、异常值过滤然后写入本地缓冲。发布线程从本地缓冲读取数据通过 MQTT 发布到 Broker。看门狗线程监控各线程状态检测到卡死或异常时重启对应线程。线程之间用queue.Queue或collections.deque做数据传递避免共享内存加锁的复杂性。Python 的 GIL 对 I/O 密集型任务影响不大采集程序大部分时间在等网络或串口所以 Python 完全够用。如果采集频率要求极高比如 1kHz 以上建议用 Go 或 C 重写。5.2 用 pymodbus 实现 Modbus RTU/TCP 采集pymodbus 是 Python 下最成熟的 Modbus 库支持 RTU、TCP、ASCII 三种模式。下面是一个 RTU 采集的示例from pymodbus.client import ModbusSerialClient import time client ModbusSerialClient( portCOM3, baudrate9600, parityN, stopbits1, bytesize8, timeout0.3 ) client.connect() while True: try: # 读从站1的保持寄存器起始地址0数量10 result client.read_holding_registers(address0, count10, slave1) if not result.isError(): print(f寄存器值: {result.registers}) else: print(f读取错误: {result}) except Exception as e: print(f通讯异常: {e}) time.sleep(0.1)TCP 模式只需把ModbusSerialClient换成ModbusTcpClient参数改成host和port。注意pymodbus 3.x 版本的 API 跟 2.x 有较大变化slave参数在 3.x 里改成了slave或unit具体看版本。建议锁定版本号避免升级后代码跑不起来。5.3 用 asyncua 实现 OPC UA 客户端订阅asyncua 是 Python 下的异步 OPC UA 库基于 asyncio适合做订阅采集import asyncio from asyncua import Client async def main(): async with Client(urlopc.tcp://192.168.1.10:4840) as client: # 获取节点 node client.get_node(ns3;s\DB1\.\Temperature\) # 创建订阅 handler SubscriptionHandler() subscription await client.create_subscription(100, handler) # 订阅节点 await subscription.subscribe_data_change(node) # 持续运行 while True: await asyncio.sleep(1) class SubscriptionHandler: def datachange_notification(self, node, val, data): print(f节点 {node} 的值变为: {val}) asyncio.run(main())这个模式比轮询高效得多服务器只在数据变化时推送网络开销极小。5.4 用 paho-mqtt 发布数据并保证不丢消息paho-mqtt 是 Python 下最常用的 MQTT 客户端库。要保证消息不丢关键是设置 QoS 1 或 2并处理on_disconnect回调做重连import paho.mqtt.client as mqtt import json import time client mqtt.Client(client_idedge_gateway_01) client.username_pw_set(user, password) def on_connect(client, userdata, flags, rc): print(f连接成功返回码: {rc}) def on_disconnect(client, userdata, rc): print(f连接断开返回码: {rc}尝试重连...) while True: try: client.reconnect() break except Exception: time.sleep(5) client.on_connect on_connect client.on_disconnect on_disconnect client.connect(192.168.1.100, 1883, 60) client.loop_start() # 发布数据 data {deviceId: sensor01, temperature: 235.6, timestamp: int(time.time() * 1000)} client.publish(factory/A1/line01/sensor01/temperature, json.dumps(data), qos1)QoS 1 保证消息至少到达一次配合本地缓冲即使网络短暂中断恢复后也能把积压的数据补发出去。实操心得client.loop_start()会启动一个后台线程处理网络收发主线程可以继续做其他事。但要注意paho-mqtt 的publish是异步的消息先进入内部队列实际发送由后台线程完成。如果程序退出太快队列里的消息可能还没发出去。稳妥的做法是在退出前调用client.loop_stop()并等待队列清空。6. 常见问题与排查技巧实录6.1 Modbus 通讯异常排查速查表现象可能原因排查方法完全无响应接线错误、波特率不匹配、从站地址错误检查 A/B 线是否接反用示波器看波形确认从站地址返回 Exception Response功能码不支持、寄存器地址越界查看异常码01 非法功能、02 非法地址、03 非法数据值数据乱码字节序错误、数据类型不匹配尝试大小端切换确认是整数还是浮点数偶发超时总线干扰、终端电阻缺失加 120Ω 终端电阻检查屏蔽线接地多从站冲突从站地址重复、轮询顺序不当逐个断开从站排查调整轮询顺序6.2 OPC UA 连接失败与证书问题OPC UA 的安全机制是双刃剑配置不当会导致连接失败。常见问题证书不受信任客户端和服务器首次连接时需要交换证书并加入信任列表。UaExpert 会弹出证书确认对话框点击“Trust”即可。自己写代码时需要把服务器证书加入客户端的信任库。安全策略不匹配服务器只支持 Basic256Sha256客户端却选了 None直接拒绝。解决方法是先浏览服务器的端点列表选择匹配的策略。端口被占用4840 是 OPC UA 默认端口如果被其他程序占用服务器启动会失败。用netstat -ano | findstr 4840排查。6.3 MQTT 消息丢失的三种场景与对策场景一QoS 0 且网络抖动。QoS 0 不保证送达网络一抖就丢。对策关键数据用 QoS 1。场景二Broker 重启导致会话丢失。客户端连接时如果clean_sessionTrueBroker 重启后会话被清除离线期间的消息全丢。对策设置clean_sessionFalse并给客户端一个固定的 ClientId。场景三发布频率超过 Broker 处理能力。EMQX 单节点能处理几十万 QPS但配置低的 Mosquitto 可能几千就顶不住了。对策在边缘侧做降采样或批量发送降低消息频率。6.4 边缘网关断电断网后的数据补传工业现场断电断网是常态采集程序必须能扛住。我的做法是采集到的数据先写入本地 SQLite 数据库带一个uploaded标志位。发布线程从数据库读取uploaded0的记录发布成功后更新标志位。网络恢复后发布线程自动把积压的数据补发出去。数据库设置容量上限比如 10 万条超过后删除最旧的已上传记录。这套机制实测能扛住 24 小时以上的断网数据零丢失。SQLite 的写入性能足够单表 10 万条记录下插入和查询都在毫秒级。实操心得SQLite 默认的synchronousFULL模式每次写入都刷盘速度慢。改成synchronousNORMAL或WAL模式性能提升明显断电时最多丢最后几条记录。对于工业采集这个取舍是值得的。6.5 采集程序性能优化的几个实用技巧批量读取Modbus 连续寄存器一次读 100 个比读 10 次 10 个快得多。但要注意从站的最大读取长度限制有些设备只支持 32 个寄存器。异步 I/OOPC UA 和 MQTT 都用异步库避免阻塞主线程。连接池如果采集多个 Modbus TCP 设备维护一个连接池避免频繁建连断连。数据压缩MQTT 消息体用 gzip 压缩能减少 60% 以上的带宽。日志分级生产环境只记录 WARNING 以上日志DEBUG 日志写入文件并定期清理避免磁盘写满。这套方案我在三个工厂落地过从单条产线到整车间覆盖最长的稳定运行了两年多。核心体会是协议选型要务实别追求新技术边缘缓冲必须有别信网络永远可靠调试工具要顺手Modbus Poll、UaExpert、MQTT Explorer 这三个装好能省一半时间。