阿里云MQTT: 子设备上线流程

0. 背景

阿里云网关子设备上平台的资料很少。有些厂家直接配置每个子设备的DeviceSecret到网关里,显然太麻烦了!我经过阅读阿里文档,发现有些简化的方法,更便于客户使用,因此分享给大家。

1. 主要信息片段

子设备 ${SubProductKey} ${SubDeviceName}  ${SubDeviceSecret}
父网关 ${DadProductKey} ${DadDeviceName} ${DadDeviceSecret}

Product就是所有相同属性和操作的设备的集合或者类。Key就是一串唯一标识了。
Device就是具体一个产品的实例或对象了。
Name就是设备的唯一标识,阿里要求在自己的Product内唯一即可。这就是为什么我起个dev01的名字,系统不提示重名的原因。产品名字空间不同而已。
Secret就是一个密钥,加密用到。到底是公钥还是私钥没深入研究。

2. 阿里平台准备。

父网关必须已具备上线能力。子设备是依赖父网关的MQTT通道上线的。子设备至少已经在平台添加好产品和具体设备。剩下的工作就由父网关设备内部的软件,自动让设备注册,建立拓扑,上线

3.网关内部Alink流程

3.1 动态注册

名字起的不知所云,经过试验,说白了就是查询子设备的${SubDeviceSecret}

父网关发布主题:/sys/${DadProductKey}/${DadDeviceName}/thing/sub/register
父网关订阅主题:/sys/${DadProductKey}/${DadDeviceName}/thing/sub/register_reply

{
  "id": "123",
  "version": "1.0",
  "sys":{
      "ack":1
  },
  "params": [
    {  
      "deviceName": ${SubDeviceName}, 
      "productKey": ${SubProductKey}
    }
  ],
  "method": "thing.sub.register"
}

如果返回200,${SubDeviceSecret}也就抓取到手。

3.2 建立拓扑
说白了,目的是建立子设备与网关的父子关系(如果原先已建立,也会返回成功)

父网关发布主题:/sys/${DadProductKey}/${DadDeviceName}/thing/topo/add
父网关订阅主题:/sys/${DadProductKey}/${DadDeviceName}/thing/topo/add_reply

{
  "id": "123",
  "version": "1.0",
  "sys":{
      "ack":1
  },
  "params": [
    {  
      "deviceName": ${SubDeviceName},
      "productKey": ${SubProductKey},
      "sign": "3908C94C2D9F33AC50A4CC9B1C4BCD45093E3EA4",
      "signmethod": "hmacSha1",
      "timestamp": "1701008186820",
      "clientId":  ${SubProductKey} & ${SubDeviceName}
    }
  ],
  "method": "thing.topo.add"
}

sign这个字段怎么填呢?

这里给个提示:
第一步把参数输入到设备信息框。
第二步点击generate。
第三步:password框里的内容就是sign。

如果返回200,就是建好了父子关系。这样多好,不用在平台上操作费劲了。

3.3 子设备上线

网关应该有感知子设备上线下线的能力。如果子设备上线,父网关应该把子设备上线的事告知平台

父网关发布主题:/ext/session/${DadProductKey}/${DadDeviceName}/combine/login

{
  "id": "123",
  "params": {
      "deviceName": ${SubDeviceName},
      "productKey": ${SubProductKey},
      "timestamp": "1701008186820",
      "clientId": ${SubProductKey}&${SubDeviceName},
      "cleanSession": "true",
      "signMethod": "hmacmd5",
      "sign": "729FB99CA14B62BAD356A22F3B58AC78"
  }
}

注意,自己计算签名sign字段时,不能把"cleanSession"算进去,具体参考Alink协议文档。

3.4 子设备业务数据传输到平台

这个就又多种方法了,有完全透传的,有半透传半翻译的,有完全Alink物模型方式的。
我搞了个物模型方式的。

网关发布主题: /sys/${SubProductKey}/${SubDeviceName}/thing/event/property/post

{
    "id": "123",
    "version": "1.0",
    "sys":{
        "ack":0
    },
    "params": {
        "temperature": 24
    },
    "method": "thing.event.property.post"
}
这里发布一个温度值24度,给平台。

3.5 其他问题
子设备下线,父子关系解除,应该举一反三,自己研究就会了吧?

3.6 异类子设备混编在一个网关下
网关应能识别子设备属于哪种产品。当子设备的产品变更后,网关应能重新处理。
例如modbus网关下,1号从机,原先是灯控开关产品,重新给1号设备分配到智能插座上。
首先在阿里平台上,删除1号(笔者写作时,平台禁止设备改产品),在添加一次1号。
然后,网关设备与1号设备重新配对一次,1号现在是智能插座了,网关因为知道智能插座的
ProducyKey,就会触发注册,拓扑这一套流程,执行后,要记住最重要的一点,把子设备的${SubDeviceSecret}写到E2ROM存起来。也就是如果存过这个密钥,说明执行过一次注册流程。
还有一点补充一下,如果阿里平台手动操作加的父子拓扑,并且网关设备里存的子设备密钥有效,则网关里认为的子设备类型,与平台认为的子设备类型可能不一致,造成传输错误。有一个解决方案,就是网关下的子设备透传自己定义的数据,传到平台后,用平台的”消息解析“功能做物模型翻译。反正路子非常多,体现了阿里云设计的精妙之处。

4.  今天继续。发现很多问题。
4.1 子设备限制太多,平台下发的属性设置,服务调用等Alink协议(JSON大包),里面没有子设备的描述。我只能通过主题,截取里面的deviceName信息,抓取子设备身份。但是如果用透传产品需要消息解析,则无法通过预定义的function protocolToRawData(jsonObj)函数,抓取deviceName(因为参数里,只有jsonObj一个,缺个Topic,是否给阿里提工单呢?)。