4G控制器通讯协议怎么设计

给控制器加 4G，是很多工厂把产品做成"可远程监控"的第一步。模组买回来，AT 指令也调通了，接下来的问题是：数据按什么格式发？发到哪里？平台下发的指令设备怎么确认？信号不好的时候怎么办？

这篇从嵌入式工程师的角度，讲 4G 控制器和云平台之间的通讯协议怎么设计。我们做过冷库控制器（4G DTU + Modbus）、避雷器监测终端（4G + MQTT 透传 Modbus）、BMS（蓝牙 + 4G 双链路）等项目，下面的建议都来自这些项目里踩过的坑。

先选架构：模组透传，还是 MCU 跑 MQTT

4G 控制器上云，常见两种架构：

透传的典型例子是我们的 避雷器在线监测平台：设备沿用 Modbus 寄存器定义，4G 模块把 RTU 字节装进 MQTT 报文上报，平台按寄存器表解析。设备侧几乎不用改。

现在主流 Cat.1 模组大多内置 MQTT 和 HTTP 的 AT 指令，甚至支持 OpenCPU 二次开发。新产品可以直接让设备发结构化的 MQTT 消息，后面的扩展会更灵活。

设备身份和鉴权

每台设备要有唯一身份，通常用序列号或 IMEI。连接平台时的鉴权，常见做法：

• 一机一密：每台设备烧录独立的密钥，泄露一台不影响其他设备。生产时要有写号工具
• 一型一密：同型号共用密钥，首次连接时向平台动态申请设备密钥，生产简单但安全性弱一些

不要所有设备共用一个 MQTT 账号密码，出了问题没法单独禁用某台设备。

主题怎么规划

以设备序列号区分，按消息方向和类型拆主题：

dev/{sn}/up/telemetry     设备 → 平台  周期数据、状态
dev/{sn}/up/event         设备 → 平台  告警、故障、开关机等事件
dev/{sn}/up/reply         设备 → 平台  对平台指令的回执
dev/{sn}/down/cmd         平台 → 设备  控制指令、参数设置
dev/{sn}/down/ota         平台 → 设备  升级通知

设备只订阅自己的 down 主题，平台在 Broker 上配置 ACL，保证一台设备不能读写别的设备的主题。我们的储能 BMS 远程升级项目，每台模组按序列号独立一组主题，就是这个思路。主题和 QoS 的更多细节，可以看 MQTT、HTTP、CoAP 在物联网项目中怎么选。

上报策略：周期 + 变化

控制器的数据，不是越频繁上报越好。4G 有流量成本，平台也要存储。比较合理的组合：

• 周期上报：运行数据按固定间隔报，比如 1 分钟或 5 分钟
• 变化上报：开关状态、运行模式、故障位一变就立即报
• 事件上报：告警、故障单独走事件主题，不和周期数据混在一起

还有一个容易忽略的问题：如果设备每次只上报变化的字段（稀疏上报），平台要把"没收到"和"值为 0"区分开。我们在 冷链设备管理平台 里就专门处理过：DTU 上报的寄存器是分片、稀疏到达的，没收到的字段按"本次未更新"处理，否则告警会误报。

指令和回执

平台下发指令，MQTT 层面"发出去了"不等于设备执行了。业务层必须有回执：

// 平台 → dev/{sn}/down/cmd
{ "id": "c-20261114-0012", "cmd": "set_param", "params": { "target_temp": 65 }, "ts": 1794643200 }
 
// 设备 → dev/{sn}/up/reply
{ "id": "c-20261114-0012", "code": 0, "result": { "target_temp": 65 } }

几条规则：

• 每条指令有唯一 id，回执带回同一个 id
• 回执里带设备执行后的实际值，平台和 App 以此为准
• 平台设超时，比如 10 秒没回执就标记"未确认"，App 提示用户
• 设备按 id 去重：QoS 1 可能重复投递，同一条指令不能执行两次
• 带时间戳的指令，设备可以丢弃过期太久的（比如断网恢复后收到 10 分钟前的开机指令）

心跳和离线

4G 网络经过运营商 NAT，长时间没有数据的连接可能被静默回收：设备以为自己在线，平台其实已经收不到了。所以：

• MQTT Keep Alive 要比 NAT 超时短，实际值在目标运营商网络下测出来
• 设置遗嘱消息，异常断开时平台能收到离线通知
• 平台再加一层"超过 N 个上报周期没数据就判离线"的检查
• 设备检测到连续发送失败，要主动重连，必要时重启模组

时间同步

设备上报的数据要带时间，告警时间、历史曲线都依赖它。4G 模组一般能从基站或 NTP 获取时间，平台下发指令时也可以带上服务器时间。约定统一用 UTC 时间戳，显示时再按时区转换，避免出海产品的时区混乱。

弱网和断网补传

设备装在地下室、机房、偏远站点，信号差是常态。断网期间的数据怎么办？

• 关键数据（告警、计数、电量）在设备本地缓存，恢复联网后按时间顺序补传
• 补传的数据带原始时间戳，平台按时间入库，不按收到的时间
• 缓存满了按优先级丢弃，先丢普通周期数据，保留告警

流量估算

选卡之前粗算一下：

单条报文 ≈ 主题 + 报文体 + MQTT 头 ≈ 200 字节（JSON）
每分钟 1 条 → 每月 ≈ 200 × 60 × 24 × 30 ≈ 8.6 MB
再加上心跳、TCP/TLS 开销、重连握手，实际可能翻倍

如果流量预算紧张，可以把报文体换成二进制或压缩字段名，或者拉长上报周期、只做变化上报。

远程升级怎么走

4G 设备的远程固件升级，一般是 MQTT 发通知、HTTP 分段下载固件，也可以像我们的储能项目那样通过 MQTT 逐帧透传。详细做法看 4G设备远程固件升级怎么做。

常见问题

用 DTU 透传，平台能解析我们的私有协议吗？

可以，平台按你们的协议文档写解析即可。我们的灯具项目里，控制器用私有二进制协议走 TCP，就是用一个桥接服务解析后转成 MQTT。

设备需要蓝牙和 4G 都有吗？

看场景。首次安装、现场调试用蓝牙更方便，远程监控用 4G。两者配合的做法可以看 蓝牙+4G App开发怎么做。

必须用 MQTT 吗？HTTP 可以吗？

只上报、不需要实时下发指令的设备，HTTP 也能用。需要远程控制、实时回执的控制器，MQTT 更合适。

你们能帮我们定 4G 协议吗？

可以。把控制器的数据项、控制动作和选用的模组 发给我们，我们出协议草案，和你们的嵌入式工程师一起定稿。整体合作方式见 传统设备智能化升级。