跳到主要内容

一型一密接入

产线只烧同一把产品密钥。设备上电向平台报到,拿到自己的 MQTT 账号再建长连接。少预制、少驻场,对准「一次调通」。

千台同型设备不必逐台灌不同密钥。凌点域把「认产品」放在 HTTP 激活,「连 Broker」放在一机一账号上——两件事拆开,远程才说得清。

你在意的平台怎么扛
产线要快同型共享 ProductKey / ProductSecret
出事要能追激活后每台独立 mqttAccount,连 gmqtt
密钥别乱用ProductSecret 只激活,不长连

1、接入步骤​

  1. 建产品模型(认证方式:设备认证),取走产品证书
  2. 创建设备(或预注册后再激活),确认 system_identifier
  3. 同型固件烧录 ProductKey / ProductSecret / 型号
  4. 设备调用激活接口(one_type_one_key)
  5. 保存返回的 mqttAccount,连 gmqtt,按 Topic 上报
  6. 在设备详情核对在线与双轨日志

2、流程一眼看懂​

3、操作​

3.1、平台:模型与证书​

进入产品 / 网关模型 → 认证方式选 设备认证 → 打开产品证书,记下:

  • ProductKey(产品标识)
  • ProductSecret(产品密钥)

再创建设备,或走预注册台账。没有台账上的 system_identifier,激活会失败。

3.2、产线:同型预置​

把 ProductKey、ProductSecret、型号写入同型固件。
不要把 ProductSecret 打进公开二维码或说明书附件。

3.3、设备:激活​

开放接口(免登录):POST …/register/auth/authenticate
(完整路径以现场 EPS / Swagger 为准。)

请求示例:

{
"system_identifier": "<system_identifier>",
"auth_type": "one_type_one_key",
"auth_data": {
"product_key": "<ProductKey>",
"product_secret": "<ProductSecret>",
"model_number": "<型号>"
},
"timestamp": 1710000000000
}

成功响应示例:

{
"system_identifier": "<system_identifier>",
"timestamp": 1710000000000,
"mqttAccount": {
"username": "<mqttUsername>",
"password": "<mqttPassword>",
"clientId": "<clientId>",
"mqttHostUrl": "<broker-host>",
"port": "<mqtt-port>",
"ssl": true,
"useSsl": true
}
}
字段说明
system_identifier本台系统标识,与请求一致
timestamp平台响应时间戳
mqttAccount.usernameMQTT 用户名(长连用,不是 ProductSecret)
mqttAccount.passwordMQTT 密码
mqttAccount.clientIdMQTT ClientId,一般与设备标识一致
mqttAccount.mqttHostUrlBroker 公网接入主机
mqttAccount.port公网接入端口(开/关 TLS 通常同一入口)
mqttAccount.ssl / useSsl客户端是否按 TLS 连接该入口;二者同义,以 true 为准

成功后本地只存 mqttAccount,再按 ssl / useSsl 决定是否 TLS,连 gmqtt。之后 Topic、物模型、双轨日志与普通 MQTT 设备相同。

不确定支持哪种认证时,可先:GET …/register/auth/getAuthConfig?device_identifier=…。

3.4、验收​

  • 设备在线
  • 上行能在双轨日志里对上原文与标准结果
  • 不再用 ProductSecret 去连 Broker

4、别踩这些坑​

现象先想
激活失败平台有没有添加网关台账,或有没有预注册设备;system_identifier 是否对得上;密钥/型号是否对
激活成功但 MQTT 拒连是否误用 ProductSecret 当 MQTT 密码;ssl / useSsl 与实际连法是否一致
整型设备异常ProductSecret 是否已泄露,需轮换并刷固件
反复激活被拒次数策略触顶,找管理员,勿暴力重试

下一步​