协议网关开发

约 1001 字大约 3 分钟

2026-10-16

协议网关负责把厂家报文转换为平台认可的设备消息，独立构建、独立部署。用公开 SDK 注入 RPC、消息总线、存储与认证，不依赖平台服务端源码。

先收集协议资料

确认身份算法、传输方式、上行/下行样本、属性类型、时间单位、控制应答、超时重试和重复消息语义。Modbus 还需点表、地址基准、单元号、字节/字序与缩放；MQTT 需主题、QoS、设备认证和 ACL 配置。

厂家名称不等于协议规格。资料不全时先做编解码与模拟设备验证，明确尚未验证的真实设备条件。

能力	ur-kit 入口
协议注册、心跳、消息信封与下行	`things/sdk/protocol/core`
标准 NATS 总线	`things/sdk/protocol/natsbus`
MQTT 连接与收发	`things/sdk/protocol/mqtt`
设备身份验证与会话跟踪	`things/sdk/deviceauth`、`protocol/tracking`
运行配置读取	`things/sdk/protocol/runtimeconfig`
云配置、产品映射和设备同步	`things/sdk/protocol/cloud`
Modbus 读写、会话与模拟设备	`protocols/modbus`

RPC 使用公开 pb，禁止从平台私有 service/.../client、internal/svc 或 platformcore 导入实现。upstream/ 仅作源码对照。

协议心跳不自动提供认证或同步 RPC。需要协议 RPC 时显式注册服务并暴露可达端口，配置认证拦截器。普通 NATS 发送接受不代表已持久化，需要持久重投时使用相应总线适配。

设备 → 厂家解码 → 身份和归属核验 → 物模型转换
    → core.Message / Publish → 平台消费与存储 → 平台 API 读回

普通属性使用 Handle=thing、Type=property。转换后的载荷示例：

{"method":"report","msgToken":"sample-report-1","timestamp":1792022400000,"sys":{"noAsk":true},"params":{"temperature":42.25}}

使用运行时毫秒时间与唯一消息标识；ProductID、DeviceName 必须来自核验映射。Payload 为原始字节，外层 JSON 编码会处理字节数组，不再手工套一层 Base64。

上行主题为 device.up.<Handle>.<ProductID>.<DeviceName>。发布成功后还要查询实际设备属性，核对值、时间、单位和目标设备。

平台下行经 device.down.<协议Code>.> 到 SubscribeDownlink，网关核验目标和可写字段，再按厂家格式发送。收到真实设备应答后关联原 msgToken 上报结果，不能把 Broker 收到消息当成设备执行成功。

MQTT 认证需分别测试：正确身份通过、错误密钥失败、跨设备主题拒绝、通配和系统主题受控。确认设备正常/异常断线、网关重连后恢复已确认订阅，权限变化后不继续使用旧会话。

# 在固定标签 ur-kit 根目录运行。
go run ./protocols/modbus/cmd/demo
go test ./protocols/modbus/...

先验证模拟设备的 42 → 258，再按真实点表配置 TCP/UDP/RTU。覆盖只读点拒绝写入、合法异常响应、超时、断线恢复、缩放和字节序；同设备位域读改写需要处理并发。

交付记录分别列出模拟、真实平台与硬件结果。测试注册心跳、上下线、属性上报后读回、控制后设备实值、重启与停止清理。网关使用自己的 Docker/Compose，经urops部署，云端页面只查看资料和心跳状态。

2026/10/16 17:31

查看所有更新日志