aliyun的topic说明 [ Luat doc 社区文章静态页面 ]

说在前面，所有的topic都是需要配合物模型使用

属性

所有properties下面的都是属性，对应使用

/sys/a1PODPi5ohj/${deviceName}/thing/event/property/post

/sys/a1PODPi5ohj/${deviceName}/thing/service/property/set

Events下面是事件，对应

/sys/a1HnMJCnqYK/${deviceName}/thing/event/${tsl.event.identifer}/post

${tsl.event.identifer}字段说明

事件都是上报，默认会添加属性上报的topic

thing.event.property.post

对应topic就是

/sys/a1HnMJCnqYK/${deviceName}/thing/event/property/post

其实也就是我们第一部分属性上报的topic

自己添加的事件说明

事件标识对应identifier，我这里是shijian，上报的topic就是thing.event.shijian.post

/sys/a1HnMJCnqYK/${deviceName}/thing/event/shijian/post

Services下面是服务对应

/sys/a1PODPi5ohj/${deviceName}/thing/service/${tsl.event.identifer}

和事件相反，服务只能订阅

默认添加thing.service.property.set，和thing.service.property.get

/sys/a1PODPi5ohj/${deviceName}/thing/service/property/set

/sys/a1PODPi5ohj/${deviceName}/thing/service/property/get

可以看到其实还是第一部分的属性获取

第二个topic我没用过不知道干啥的，估计可以通过这个下发属性。

自己添加服务说明，这里选用异步，同步需要rrpc

其实有了上面例子很好理解thing.service.fuwu，也就是

/sys/a1PODPi5ohj/${deviceName}/thing/service/fuwu

· RRPC请求消息Topic：/sys/${YourProductKey}/${YourDeviceName}/rrpc/request/${messageId}

· RRPC响应消息Topic：/sys/${YourProductKey}/${YourDeviceName}/rrpc/response/${messageId}

· RRPC订阅Topic：/sys/${YourProductKey}/${YourDeviceName}/rrpc/request/+

关键点就是订阅那个通配符topic，因为每次messageId是不同的，也就是说每次都需要按照发过来的messageId重新组合topic。