从 RJ45 到 MQTT Broker：以太网温湿度传感器数据透传至云端的协议转换网关设计

原创

盛世宏博科技

发布于 2026-09-16 15:09:13

1430

文章被收录于专栏：盛世宏博物联网盛世宏博物联网

从 RJ45 到 MQTT Broker：以太网温湿度传感器数据透传至云端的协议转换网关设计

一、架构痛点：为什么需要“协议转换网关”

在边缘机房、分布式基站、连锁门店等场景中，以太网温湿度传感器已普遍采用 RJ45 + Modbus TCP。但当数据需要上云时，直接对接云平台的 MQTT Broker 会面临现实问题：

问题	说明
协议不匹配	传感器只懂 Modbus TCP，云平台只认 MQTT/HTTP
连接数限制	云端 Broker 难以维持成百上千个传感器的长连接
网络不稳定	4G/5G 链路抖动，TCP 长连接频繁断开
带宽成本高	每个传感器独立上报，头部开销大，流量浪费
安全合规	传感器不支持 TLS、证书认证，直接暴露公网风险高

协议转换网关（Protocol Conversion Gateway） 正是解决上述问题的关键中间层：它在边缘侧汇聚多台传感器，完成协议转换、数据聚合、缓存补传，再统一通过 MQTT 上云。

二、整体架构：边缘汇聚 + 云端解耦

[温湿度传感器1]  Modbus TCP
[温湿度传感器2]  Modbus TCP  ──> [协议转换网关] ── MQTT over TLS ──> [云端 MQTT Broker]
[温湿度传感器N]  Modbus TCP                         ↓
                                                  [时序数据库/动环平台]

核心角色

下行（边缘侧）：网关作为 Modbus TCP Client，主动轮询或被动接收传感器数据
上行（云端）：网关作为 MQTT Client，向 Broker 发布 JSON/CBOR 格式数据
本地缓存：网络中断时，网关本地存储历史数据，恢复后补传

三、网关核心模块设计

1. 南向接口：Modbus TCP 采集引擎

（1）采集模式选择

模式	说明	适用场景
轮询模式	网关定期向传感器发起 0x03 读保持寄存器	传感器不支持主动上报
被动接收	传感器主动 UDP/TCP 推送，网关监听端口	传感器支持主动上报
混合模式	正常轮询 + 告警时传感器主动上报	兼顾实时性与可靠性

推荐：温湿度变化慢，采用 轮询模式（2–5 秒/次），CPU 和带宽消耗可控。

（2）寄存器映射与归一化

不同厂商寄存器定义不同，网关需做归一化映射：

# 设备模板示例
device_templates:
  th_sensor_a:
    vendor: "VendorA"
    registers:
      temperature: {addr: 40001, type: "int16", scale: 0.1, unit: "℃"}
      humidity:    {addr: 40002, type: "int16", scale: 0.1, unit: "%RH"}
      status:      {addr: 40003, type: "uint16", bitmask: true}

网关内部统一转换为标准数据结构：

{
  "device_id": "RACK-A01-IN",
  "timestamp": 1700000000,
  "temperature": 25.6,
  "humidity": 61.2,
  "status": {"online": true, "calibrating": false}
}

2. 北向接口：MQTT 发布引擎

（1）Topic 设计规范

采用分层 Topic，便于云端订阅和权限控制：

{project}/{region}/{site}/{device_type}/{device_id}/telemetry

示例：

dc/cn-east/sz-IDC-R3/TH/RACK-A01-IN/telemetry

优点：支持按项目、区域、站点、设备类型灵活订阅
权限：云端可精确控制“谁可以订阅哪个 Topic”

（2）Payload 格式选择

格式	优点	缺点	推荐场景
JSON	可读性强，调试方便	体积大，解析慢	通用场景
CBOR	二进制，体积小	可读性差	带宽受限（4G/5G）
Protobuf	强类型，高效	需 IDL 定义	大规模设备

推荐：边缘网关 → 云端，优先 JSON（调试期）→ CBOR（生产期）。

（3）QoS 与 retained 策略

QoS=1（至少一次）：平衡可靠性与性能，避免 QoS=2 的握手开销
Retained=false：温湿度为时序数据，无需保留最后一条
Will Message：网关异常下线时，自动发布离线状态

3. 本地缓存与断点续传

（1）存储结构

网关本地采用 SQLite + 环形队列：

CREATE TABLE telemetry_cache (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  device_id TEXT,
  timestamp INTEGER,
  payload BLOB,
  uploaded INTEGER DEFAULT 0
);

新数据写入数据库，标记为 uploaded=0
MQTT 发布成功后，更新 uploaded=1
定期清理已上传数据（保留最近 24 小时）

（2）补传策略

网络恢复：优先补传未上传数据（按时间戳升序）
流量控制：补传速率限制（如 10 条/秒），避免拥塞
数据去重：云端根据 device_id + timestamp 去重

4. 安全与认证

（1）MQTT 认证

TLS 加密：强制 mqtts://:8883，禁用非加密端口
证书认证：网关预置 X.509 证书，Broker 验证客户端证书
用户名/密码：作为证书失效时的备用方案

（2）设备鉴权

网关维护 设备白名单（IP/MAC/序列号）
非法设备数据直接丢弃，不上报云端

四、网关部署形态对比

形态	说明	优点	缺点	适用场景
硬件网关	工业 ARM 盒子，预装网关软件	稳定可靠，易维护	成本较高	机房、基站
软件网关	运行在边缘服务器/虚拟机	灵活，成本低	依赖宿主环境	企业私有云
容器化	Docker 镜像，K8s 编排	弹性伸缩，易升级	运维复杂	大规模边缘节点
传感器内置	高端传感器自带 MQTT 功能	无需网关，架构简单	功能受限，难统一	小型站点

推荐：中大型项目采用 硬件网关 + 容器化管理，兼顾稳定性与灵活性。

五、云端数据消费：从“原始数据”到“业务价值”

1. 数据流水线

MQTT Broker → 规则引擎 → 时序数据库 → 动环平台/大屏
                ↓
            告警引擎 → 短信/邮件/APP
                ↓
            分析引擎 → 容量规划/能效优化

2. 规则引擎示例

-- 连续 3 次温度 >28℃ 触发告警
SELECT device_id, AVG(temperature) AS avg_temp
FROM telemetry
WHERE timestamp > NOW() - INTERVAL '5 MINUTE'
GROUP BY device_id
HAVING AVG(temperature) > 28 AND COUNT(*) >= 3;

3. 数据压缩与降采样

原始数据：1–5 秒/次，保留 7 天
降采样数据：1 分钟/次，保留 1 年
聚合数据：1 小时/次，保留永久

六、踩坑实录：网关设计的“暗礁”

1. Modbus TCP 连接数爆炸

问题：网关为每个传感器创建独立 TCP 连接，100 个传感器 = 100 个连接，资源耗尽
解决：复用 TCP 连接，单网关 ≤10 个连接，轮询不同设备

2. MQTT 发布阻塞

问题：网络抖动时，MQTT 发布阻塞，导致网关内存暴涨
解决：发布队列长度限制，满队列时丢弃最旧数据（非关键）

3. 时间戳混乱

问题：传感器无 RTC，网关时间不同步，导致数据时间错乱
解决：网关强制 NTP 同步，传感器数据以网关时间为准

4. 证书过期

问题：网关证书 1 年后过期，无人更新，导致断连
解决：证书有效期 3–5 年，平台监控证书剩余天数，提前告警

5. JSON 解析漏洞

问题：云端 JSON 解析库漏洞，导致服务崩溃
解决：网关侧做 JSON Schema 校验，过滤非法数据

七、典型配置示例（网关软件）

# gateway.yaml
southbound:
  modbus:
    enabled: true
    poll_interval: 5s
    timeout: 2s
    devices:
      - ip: 192.168.100.101
        port: 502
        template: th_sensor_a
        device_id: "RACK-A01-IN"
      - ip: 192.168.100.102
        port: 502
        template: th_sensor_a
        device_id: "RACK-A01-OUT"

northbound:
  mqtt:
    enabled: true
    broker: "mqtts://mqtt.example.com:8883"
    client_id: "gateway-sz-IDC-R3"
    username: "gateway"
    password: "${MQTT_PASSWORD}"
    tls_cert: "/etc/gateway/cert.pem"
    tls_key: "/etc/gateway/key.pem"
    topic_prefix: "dc/cn-east/sz-IDC-R3"
    qos: 1
    retain: false

storage:
  type: sqlite
  path: "/var/lib/gateway/telemetry.db"
  max_cache_days: 7

security:
  device_whitelist:
    - "192.168.100.101"
    - "192.168.100.102"

八、小结：网关设计的“三个统一”

协议统一：南向 Modbus TCP，北向 MQTT，网关完成转换
时间统一：网关 NTP 同步，所有数据时间戳以网关为准
状态统一：网关汇聚设备状态、网络状态、自身状态，统一上报云端

一句话设计原则：

网关是边缘的“翻译官”和“缓冲池”，既要懂设备的“方言”（Modbus），又要说云端的“普通话”（MQTT），还要在网络风暴中守住数据的底线。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

教程

#RJ45温湿度传感器