边缘网关（协议汇聚 / 边缘计算）

有一类展厅场景，串口服务器搞不定：你有十几台 RS485 传感器，还有继电器、采集器，中控在别的楼，中间还有不稳定的网络；数据要上云做可视化大屏；某些紧急联动（温度超标立刻关电）要求网络断了也能在本地执行；不同设备协议还不一样（有 Modbus RTU、有私有串口协议）……

串口服务器是一根"透明管道"，它不理解数据，不存储，不运算，不做本地决策。这些需求超出它的能力范围。这时候你需要的是边缘网关。

边缘网关的核心能力是：在现场本地采集多协议设备的数据、做边缘计算（本地规则/联动）、汇聚后上报云端或中控，网络断了本地逻辑照跑。我们在一些展馆环境监控和设备管理项目里参考了有人 M300 这款边缘网关的方案，下面以它为例讲清楚原理和用法。

R2 内容，涉及设备配置与接线。有人 M300 的配置界面、支持协议、MQTT 参数、Wukong Edge 功能以有人官方产品文档为准（文末来源）；下文描述为参考实践记录，具体操作细节 hedge"以手册为准"，部署前务必查阅对应版本文档。

---

边缘网关 vs 串口服务器：本质区别

很多人一开始分不清这两个东西，因为外形类似、都带网口和 RS485。核心区别在于它有没有"大脑"：

维度	串口服务器（如 USR-TCP232）	边缘网关（如 USR-M300）
数据处理	透传，不理解数据内容	解析数据，理解寄存器/数值含义
本地规则/联动	无，数据送出去靠上层	有，本地规则引擎可在网关上运行"如果…那么…"逻辑
协议转换	简单 TCP↔串口	多协议解析（Modbus、自定义串口等）+ 统一上报格式
数据上云	靠中控/服务器转发	直接推 MQTT、HTTP 等，自带上云能力
断网自治	断网透传失效	断网本地规则继续跑
配置复杂度	低（IP+串口参数）	高（要配采集模板、上报策略、规则引擎）
适用场景	单台/少量串口设备接入网络	多设备/多协议汇聚、有上云需求、需要本地自治

一句话区别：串口服务器是管道，边缘网关是现场的小型数据中台。

---

边缘网关做什么：三个核心能力

能力一：多协议数据采集（汇聚侧）

M300 这类边缘网关带多路 RS485 和网口，支持 Modbus RTU 主动查询（主机模式）：你告诉网关"每隔 5 秒，去读这台设备（地址 01）的第 0~3 个保持寄存器"，网关就自动定时发 Modbus 请求、收数据、存进本地缓存。

可以同时配多个 Modbus 设备（多个从机地址）的采集任务，所有通道的数据统一管理。还能对接部分私有串口协议（以 M300 支持的协议列表为准）。

这样，现场十台 RS485 传感器/继电器的数据都进了网关，不需要中控频繁轮询每台设备——中控只和网关对话，网关帮你管底层。

能力二：本地规则引擎（边缘计算）

M300 内置 Wukong Edge 物控系统（以有人官方文档为准），支持在网关本地配置规则：

IF 温度传感器 CH1 > 40℃ THEN 继电器 A 断开 (关冷却设备供电)
IF 水位传感器 CH3 < 20% THEN 推送 MQTT 告警
IF 时间 = 每天 22:00 THEN 所有继电器关闭

规则在网关本地执行，不需要经过中控或云端。即使网络断了，这些保护和联动逻辑也照跑。展厅里这一点很重要：展馆后半夜无人值守，要求设备保护逻辑在网络闪断时依然可靠。

能力三：数据上云（MQTT）

边缘网关把本地采集到的所有传感器数据，按配置的间隔，通过 MQTT 协议推送到云端 MQTT Broker（如阿里云 IoT、有人云、或自建 MQTT 服务）。云端拿到数据后可以做可视化大屏、历史趋势、异常报警推送等。

MQTT 推送链路：

网关（MQTT Client）
    │  MQTT Publish，Topic: 如 /gateway/M300/data
    ▼
MQTT Broker（云端或局域网内自建）
    │  订阅
    ▼
云端后台 / 可视化大屏 / 告警系统

MQTT 是轻量的发布/订阅协议，适合物联网场景（带宽小、弱网也能跑）。以 M300 配置为例，需要填 Broker 地址/端口（MQTT 默认 1883，TLS 加密默认 8883）、ClientID、Topic 规则、上报间隔等（参数以 M300 手册为准）。

---

展厅里怎么用边缘网关：典型角色分工

边缘网关不是用来取代串口服务器的，而是针对特定场景补位。展厅里一个典型的三层架构：

传感器/继电器/采集器（RS485 设备层）
        │  RS485 Modbus RTU
        ▼
边缘网关（M300）
├─ 本地规则引擎：温度超标→切断对应继电器（网络断也跑）
├─ MQTT 上云：数据推到云端大屏/告警
└─ Modbus TCP 对上：中控软件可以从网关查询汇聚后的数据
        │  以太网（Modbus TCP 或 HTTP/MQTT）
        ▼
中控软件（SoftControl）
        │  整合传感数据+用户触发，跑展厅联动场景
        ▼
展厅设备（投影/灯光/音响/电动机构…）

在这个架构里，中控管展厅体验逻辑（参观者触发什么、场景怎么切），边缘网关管设备保护和数据汇聚（传感器监控、上云、本地应急联动）。两者职责清晰，互不干扰。

---

M300 配置关键步骤（参考）

以下是参考实践的配置思路，具体界面和参数以有人 M300 官方手册/配置说明为准：

步骤一：网络配置

配 M300 的 IP（静态 IP 推荐，展厅里设备地址不能飘），子网掩码、网关、DNS。确认 M300 能 ping 通局域网其他设备和互联网（如需上云）。

步骤二：RS485 串口参数

M300 的 RS485 串口参数（波特率/数据位/停止位/奇偶）需和总线上设备一致。如果挂的是科星 Modbus 设备，对齐科星设备配置的串口参数（以科星手册为准，通常 9600/19200-8-N-1 之类）。

步骤三：添加采集设备和数据点

在 M300 的配置界面（Web UI 或有人配置工具），添加每台 RS485 从机：填设备地址（Modbus Unit ID）、选协议（Modbus RTU）、添加要采集的寄存器点位（地址、数据类型、采集间隔）。每个数据点对应一个传感器通道的寄存器。

步骤四：配置本地规则（Wukong Edge）

按 Wukong Edge 的规则配置界面，写条件-动作规则（以手册为准）。例如：某温度数据点超过阈值时，触发某继电器 DO 输出动作。规则保存后本地自动生效。

步骤五：配置 MQTT 上云

填 MQTT Broker 地址、端口、认证信息（ClientID、用户名/密码），选要上报的数据点，设上报间隔，保存后 M300 开始定时推 MQTT 消息。

---

边缘计算本地规则示例（概念示意）

以下为规则引擎配置的概念示意，具体语法以 Wukong Edge 文档为准，不同版本可能有差异：

规则名: 高温保护
条件: 传感器_CH1_温度 > 40.0
动作: 继电器_DO1 = OFF  (断开对应回路)
触发模式: 条件持续 10 秒后触发

规则名: 低水位告警
条件: 液位_CH3 < 20.0
动作: MQTT 推送告警消息 to Topic "/alarm/water_level"
触发模式: 状态变化时立即触发

这些规则在 M300 本地运行，哪怕局域网或云网络断了，保护逻辑继续有效。

---

MQTT 数据格式说明

有人 M300 的 MQTT 上报数据格式以官方文档为准，通常是 JSON，包含设备 ID、时间戳、各数据点名称和值。示例（概念格式，以实际手册为准）：

{
  "device_id": "M300_001",
  "timestamp": 1687400000,
  "data": {
    "temperature_ch1": 23.5,
    "humidity_ch2": 55.2,
    "water_level_ch3": 78.0
  }
}

云端 MQTT 订阅方拿到这个 JSON，按字段取值存数据库/推大屏。如果你用的是阿里云 IoT 或华为云 IoT，还需要按平台要求做设备注册和 Topic 鉴权，细节以各云平台文档为准。

---

边缘网关 vs 串口服务器 完整选型对比

场景	选串口服务器	选边缘网关
设备数量	1~几台串口设备接入网络	十几台以上，多种协议混用
数据处理需求	不需要，透传即可	需要协议解析、量程换算、聚合
本地自治需求	无	需要断网也能跑的本地保护/联动
上云需求	无，或靠上层转发	直接推 MQTT/HTTP 上云
配置复杂度接受度	简单，几分钟配完	需要时间学习配置规则和数据模板
成本	低（百元级）	高（千元级以上，以官方报价为准）
典型案例	接一台老投影串口	展馆环境监控、多设备数据汇聚上大屏

---

故障排查表

现象	最可能的原因	怎么办
网关连不上 RS485 从机	串口参数不一致/A-B 接反/地址错	核对波特率、数据位、A/B 极性；确认设备 Unit ID 与配置一致
数据点一直读不到值	寄存器地址错/功能码错/采集间隔未到	用 Modbus Poll 单独验证那个地址能读到值；核配置里功能码和地址
本地规则不触发	条件阈值配错/规则未启用/数据点名对不上	检查规则界面是否已启用；核对条件里引用的数据点名和采集配置里的名字完全一致
MQTT 连接不上 Broker	IP/端口/认证信息错/防火墙	确认 Broker 地址可 ping；确认端口（1883/8883）未被防火墙封；核对 ClientID/用户名/密码
MQTT 连上但收不到数据	Topic 配错/未订阅该 Topic/上报间隔太长	确认推送 Topic 和订阅 Topic 完全一致（区分大小写）；检查上报间隔设置
网络断了本地规则也停了	规则配置依赖网络的数据源	本地规则只能基于网关本地采集的数据点触发；云端数据不可用时检查是否有网络依赖
上报数据和传感器读数不符	量程换算配置错/采集精度问题	检查数据点配置里的量程/比例因子；和直接读 Modbus 原始值核对

---

进阶 / 应用案例

• 大型展馆环境监控系统：多区域部署多台边缘网关，每台网关管辖本区域 RS485 传感器（温湿度/CO₂/照度），各网关推 MQTT 到中央 Broker，控制室大屏订阅展示全馆实时数据，异常时推钉钉/微信通知值班人员。
• 展厅设备台账和健康监控：网关定期采集继电器状态、电表数据，上报到后台，做设备运行时长统计、用电量统计，为周期性维保提供数据依据。
• 多展馆连锁管理：每个展馆一台边缘网关，统一推 MQTT 到云端，总部能看到所有展馆实时环境和设备状态，不需要每个馆部署独立后台。
• 边缘+中控双保险：中控管"开场/闭场/互动触发"等体验逻辑，边缘网关管"过温断电/断水报警"等保护逻辑，两套系统各管各的，任何一边故障不影响另一边的安全保障。

---

动手挑战

1. 先不上云，用一台 M300 接一台 RS485 Modbus 设备（哪怕是科星继电器），在 M300 配置界面添加这台设备的采集任务，确认能在 M300 管理界面看到实时更新的数据点——先把"本地采集"这步跑通。
2. 配一条本地规则：如果那台设备的某个数据点值超过你设的阈值，M300 做某个 DO 输出动作。用实际值触发一次，看本地规则是不是真的在 M300 上执行——不经过云和中控，本地闭环。

---

本节学到的知识

• 边缘网关 ≠ 串口服务器：串口服务器是透传管道（不理解数据、无本地逻辑），边缘网关是现场小型数据中台（解析寄存器、跑本地规则、自带上云）。
• 接口能力看这几项：网口 / 多路 RS485 / Modbus / MQTT；本文以有人 USR-M300 为例，具体支持协议列表与参数以有人官方文档为准。
• 采集侧：网关做 Modbus RTU 主机（主动查询），按你设的间隔（如每 5 秒）去读从机（Unit ID / 保持寄存器）；一台网关可挂十几台以上多协议设备统一管理。
• 本地规则引擎 = 边缘计算落地形态：在网关上写 IF…THEN… 条件-动作规则，网络断了也照跑，专管过温断电、断水告警这类设备保护级紧急联动。
• 规则分工铁律：本地规则管设备保护级（需断网也跑的），中控管展览体验级（场景切换/参观者交互）；都堆到中控，一旦中控重启或网络抖动，保护逻辑就空档。
• 上云走 MQTT（轻量发布/订阅、弱网也能跑）：默认端口 1883，TLS 加密默认 8883；要填 Broker 地址、ClientID、Topic、上报间隔（参数以 M300 手册为准）。
• MQTT 上报数据通常是 JSON（含 device_id、timestamp、各数据点名值）；订阅 Topic 要和推送 Topic 完全一致（区分大小写），否则连上也收不到数据。
• 展厅三层架构：RS485 设备层 → 边缘网关（本地规则 + MQTT 上云 + Modbus TCP 对上）→ 中控（SoftControl）→ 展厅设备；中控只和网关对话，不必逐台轮询底层。
• 选型分水岭：1~几台串口设备、只需透传 → 串口服务器（百元级）；十几台以上多协议、要上云、要断网自治 → 边缘网关（千元级以上，以官方报价为准）。
• 排查常踩点：读不到从机先核波特率/数据位/A-B 极性/Unit ID；本地规则不触发多为数据点名对不上或规则未启用；上报值不对查量程/比例因子换算。

---

小结 · 你掌握了什么

• 你彻底搞清了边缘网关和串口服务器的本质区别：串口服务器是透传管道，边缘网关是现场小型数据中台，有本地规则引擎、协议解析能力和上云能力。
• 你理解了边缘网关三个核心能力：多协议 Modbus 数据采集、本地规则引擎（断网也跑）、MQTT 上云推送。
• 你知道展厅里边缘网关和中控的角色分工：网关管设备保护级联动，中控管展览体验级联动，职责分开更可靠。
• 你拿到了边缘网关 vs 串口服务器的完整对比表，知道什么场景该升级到边缘网关，以及配置关键步骤和故障排查表。

要把边缘网关采集的数据用在展厅互动里，让中控接到传感器数值并触发场景，了解 SoftControl 展厅中控系统；对串口服务器这个更轻量的方案还有疑问，参考 串口服务器图鉴。