• 云端设置

    云端设置

    云端设置主要包含了, 创建新产品, 创建新设备

    登录腾讯云, 搜索"云产品"下的"物联网通信"产品, 或直接访问 https://console.cloud.tencent.com/iotcloud

    云端设置 - 图1

    创建新产品

    云端设置 - 图2

    云端设置 - 图3

    在"添加新产品"的时候, 注意选择. 产品类型选择普通产品, 产品名称随意, 认证方式选择密钥认证, 数据格式选择自定义.

    关于认证方式和数据格式的选择解释

    认证方式默认的是证书认证, 数据格式默认的是json格式.

    对于认证方式, 指定了设备通过何种方式和云端进行双向认证. 默认的证书方式相对于密钥认证安全性高一点, 但是问题在于证书方式需要在嵌入式设备端存储证书同时实现证书的相关处理, 对设备的RAM和ROM要求较高, 相对而言, 密钥认证的方式资源占用量就小点, 由于我们主要支持的设备都是小型嵌入式设备, 因此选用密钥认证.

    数据格式指的是设备和云端进行数据交互时候使用的格式, json格式为文本字符串, 可读性高, 并且便于解析, 对于功能复杂的设备交互而已比较理想, 但是对于小型设备或是定制设备, 数据单一, 或是有自定义的格式(二进制或是文本), 这种时候, 用自定义的数据格式, 一方面节约流量, 另一方面比较灵活.

    注: 这里的数据格式选择会影响之后腾讯云"规则引擎"组件的设置.

    云端设置 - 图4

    新建完产品后, 会获得一个平台分配的productID.

    创建新设备

    云端设置 - 图5

    云端设置 - 图6

    设置的时候只需要设置设备名称即可, 由于我们在创建产品的时候, 认证方式选择了密钥认证, 因此在创建设备的时候将会提供设备对应的密钥, 这里选择默认的"使用物联通通信提供的密钥"即可.

    云端设置 - 图7

    添加完设备后, 会告知设备对应的密钥. 该密钥将会用于之后设备与平台通信时的认证.

    为了实现设备间的通信, 我们还需要创建第二个设备, 操作同上, 不妨将其命名为"dev2".

    云端设置 - 图8

    此时, 在产品"my_product"下面, 有2个我们添加的设备, 分别为"dev1"和"dev2".

    Topic设置

    我们知道, 设备通过MQTT协议进行通信, 是基于发布(publish)和订阅(subscribe)相关的话题(topic)来进行的, 因此, 还需要在云端对话题进行设置.

    云端设置 - 图9

    我们可以在"权限列表"中看到Topic对应的操作权限, 此处还可以添加新的Topic.

    在这里, 我们可以看到, 平台默认配置了两类的Topic, 用于执行发布和订阅. 这里之所以是两类而不是两个, 是因为Topic里使用了变量. 这里的QOW7EO9S31实际上是productID; ${deviceName}为平台设置的变量, 即设备名; controlevent为Topic名字. 所以, 在我们创建了2个设备dev1和dev2的情况下, 在my_product产品下, 即存在4个Topic, 分别为:

    • QOW7EO9S31/dev1/control 订阅权限
    • QOW7EO9S31/dev1/event 发布权限
    • QOW7EO9S31/dev2/control 订阅权限
    • QOW7EO9S31/dev2/event 发布权限这里默认的Topic已经足够我们使用, 不需要额外添加Topic和权限了.

    MQTT的Topic本身是一个普通的字符串, 但是可以由多个层级组成, 根据/来划分. 这种分层的Topic结构使得主题的过滤和匹配变得相对灵活.

    多层通配符"#"

    必须位于最后一个字符, 匹配多层级. 例如对于QOW7EO9S31/#, 将会匹配QOW7EO9S31/dev1, QOW7EO9S31/dev2, QOW7EO9S31/dev1/control, QOW7EO9S31/dev1/event, QOW7EO9S31/dev2/controlQOW7EO9S31/dev2/event主题.

    单层通配符"+"

    匹配单个层级, 在主题的任何层级都可以使用, 包括第一个层级和最后一个层级.

    例如, 对于QOW7EO9S31/+/event, 将会匹配QOW7EO9S31/dev1/eventQOW7EO9S31/dev2/event.

    设置规则引擎

    规则引擎本身不属于MQTT协议的范畴, 但是平台侧出于安全角度考虑添加了规则引擎, 实现了Topic之间的转发操作, 我们需要合理的设置规则引擎才能实现多个设备之间的数据收发, 由于理解起来比较复杂, 我们这里简要讲解下为什么需要规则引擎, 规则引擎的作用, 如何设置规则引擎.

    • 为什么需要规则引擎

    在上节的Topic中, 我们知道, 在平台侧, 对于不同的Topic, 规定了不同的权限, 例如, 对于QOW7EO9S31/dev1/event这个Topic, 只具有发布权限, 而对于QOW7EO9S31/dev1/control这个Topic, 只具有订阅权限. 对于设备dev1, 很自然的, 会朝QOW7EO9S31/dev1/event这个Topic发送数据, 并且订阅QOW7EO9S31/dev1/control这个Topic的消息. 但是这里就会涉及到, event的数据最后到哪去, control的数据从哪里来的问题.

    在本文的例子中, 我们希望dev1和dev2发生交互, 即相互收发消息. 由于MQTT是基于Topic的发布订阅机制, 因此, dev1想要获得dev2的数据, 直觉上, 需要订阅dev2发布消息的那个Topic. 假定dev2朝QOW7EO9S31/dev2/eventTopic上发送数据, 那么dev1想要获得dev2发布的消息, 最直接的办法是订阅同样的Topic, 即QOW7EO9S31/dev2/event, 但是这里存在几个问题, 首先, event Topic只具有发布权限, 没有订阅权限, 其次, 在平台侧, 规定了, 不允许跨设备发布或是订阅Topic, 也就是说, 对于dev1, 只能看到或只允许访问QOW7EO9S31/dev1这个Topic以及其下属的Topic, 不能访问QOW7EO9S31/dev2及其下属Topic.

    平台侧添加不允许跨设备访问Topic的规则虽然不直观, 但却是合理的. 如果不添加这条限制, 那么一个设备可以不加限制的订阅同一个产品下所有其他设备的Topic, 获取其上报的消息, 这存在潜在的安全漏洞.

    • 规则引擎的作用

    因为不允许直接跨设备访问Topic, 所以需要依靠"规则引擎"来手动添加规则, 将指定的Topic消息转发到另一个Topic上, 实现不同设备之间的通信.

    云端设置 - 图10

    上图介绍了规则引擎的主要作用"republish", 即将一个Topic下的消息republish到另一个Topic下. 从图中我们可以看到, 规则引擎将QOW7EO9S31/dev2/event的消息republish到了QOW7EO9S31/dev1/control下. 将QOW7EO9S31/dev1/event的消息republish到了QOW7EO9S31/dev2/control下.

    这样, 对于dev1而言, 只需要订阅QOW7EO9S31/dev1/control就可以接收来自QOW7EO9S31/dev2/event的消息了. dev2同理.

    • 设置规则引擎

    云端设置 - 图11

    在物联网通信界面选择"规则引擎"—"新建规则", 随意指定一个规则名称, 我们这里不妨设置为"1to2".

    云端设置 - 图12

    这里, 我们看到规则的详细设置信息, 主要包括"筛选数据"和"行为操作". "筛选数据"针对指定Topic接收到的消息内容进行进一步的筛选, 比如匹配消息中的字段来决定是否执行之后的设置的"行为操作". 而"行为操作"则是指定对通过匹配的消息进行何种操作, 主要的操作有"数据转发到另一个Topic(Republish)", "转发到第三方服务(Forward)"以及转发到腾讯云各个对应组件中.

    云端设置 - 图13

    上图是设置好的规则, 这里, 我们将"筛选数据"部分的筛选字段设置为*, 筛选的Topic为QOW7EO9S31/dev1/event, 条件设置为空, 即不筛选数据, 全部匹配. 然后, 执行的操作是将数据转发到QOW7EO9S31/dev2/control, 设置完这条规则, 就实现了dev2通过订阅control就能收到dev1发送到event的数据.

    关于"筛选数据"的设定

    由于我们在新建产品, 设置数据格式的时候选择了自定义数据格式, 在自定义数据格式的情况下, 当前平台将其当做二进制流来处理, 也就无法通过匹配字段进行数据筛选.

    如果在进行产品的时候, 使用数据格式是json, 那么此处就可以根据json中的字段进行SQL的匹配和筛选.

    同理, 我们再设置新的一个规则"2to1", 实现QOW7EO9S31/dev2/eventQOW7EO9S31/dev1/control的转发.

    云端设置 - 图14

    这样, 在平台侧dev1到dev2的双向数据通路就打通了.

    云日志和消息队列CMQ

    在平台侧都设置好后, 我们在之后的测试过程或是通信过程中, 往往还需要查看平台是否收到了设备发送上来的消息, 对消息执行了哪些操作, 消息的具体内容(payload)是什么. 腾讯云提供了物联网通信产品的"云日志"功能和腾讯云组件"消息队列CMQ".

    云日志

    可以在产品列表下找到"云日志", 点击搜索即可显示对应的行为日志

    云端设置 - 图15

    参考日志如下, 可以看到日志记录了设备的连接, 连接断开, 发布, 订阅等行为, 也记录了规则引擎的操作, 还有CMQ队列的一些行为日志. 但是关于设备发布的消息内容, 在云日志中无法查看, 需要借助消息队列CMQ.

    云端设置 - 图16

    消息队列CMQ

    可以在产品列表中找到"消息队列"选项, 设置队列所想要接收的消息类型后保存配置, 即可将平台侧收到的设备消息额外发送到腾讯云消息队列CMQ组件中.

    云端设置 - 图17

    设置完消息队列后可以在"云产品"中搜索CMQ, 即可找到对应的消息队列, 点击"开始接收消息" 接收消息队列中的内容, 参考如下

    云端设置 - 图18

    其中可以看到有些消息带有"PayloadLen"和"Playload"字段, 即为具体的消息内容.

    在密钥认证下, 消息的内容(payload)是经过base64编码的, 所以在平台侧看到的数据类似乱码实际上是经过编码后的结果, 想要查看具体的内容, 可以在linux下, echo <payload> | base64 —decode.