阿里云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，是否给阿里提工单呢?）。