蓝牙mesh组网实践（厂商透传模型介绍）

目录

CH582的官方EVT中，除了代理节点例程和天猫精灵例程外都提供了厂商定义的透传模型。

模型位于蓝牙mesh网络协议中的最上层，负责标准化用户应用场景的实例，比如说开关模型、亮度模型、风速模型。由于蓝牙mesh网络中所有数据都经由广播承载层传输，根据网络地址来区分节点，判断数据来源，也就缺少了管道、路由、端口等的区分数据种类、路径的工具和手段，故需要模型来对数据进行判别。对于模型来说，举个例子，一个智能小灯，只支持打开或者关闭，程序中只有一个开关模型，这时候收到一个指令让它调节色温，就会出错；要想小灯能够识别该指令，就需要添加色温模型来处理指令；换言之，开关模型规定了开关小灯的指令应该是什么样的，色温模型规定了调节色温的指令应该是什么样的。标准模型可以参考天猫精灵例程中的通用模型。

对于请求、设置服务端状态的一边，称之为客户端；对于存储模型状态以及收到消息时的应对方法的一边，称之为服务端。在配网器配网方式中，配网器作为网络的“中心节点”，包含的模型为客户端；其他节点除了代理节点没有包含透传模型外，都使用服务端模型。

客户端透传模数据向服务端发送函数，一个有应答机制，函数为：int  vendor_message_cli_write(struct send_param *param, uint8_t *pData, uint16_t len)；

一个无应答机制，函数为：int  vendor_message_cli_send_trans(struct send_param *param, uint8_t *pData, uint16_t len)，两者只有有无应答的区别，参数相同。

*pData指向需要发送的数组，len是发送的数组字节数长度。

其中最关键是第一个参数——发送参数结构体↓

app_idx：16位的AppKey的索引，用于选择16字节的AppKey。配网器可以存储多个AppKey并且需要维护模型与AppKey的绑定关系，配网器在配网时会将模型与AppKey绑定，每个模型可以绑定一个或多个AppKey（默认每个模型绑定一个AppKey，可在app_mesh_confg.h头文件中更改，最多三个）。绑定同一个的AppKey后，模型之间才可通信。对于配网器例程，这里的self_prov_app_idx指向的是配网时透传模型绑定的AppKey，用户若添加了更多模型和更多AppKey，可以直接赋值比如说0x0001来指向对应的AppKey。

addr：配网过程中，配网器会自动存储节点的网络地址在一个结构体数组中，可以将绝对地址0x0001改成app_nodes[n].node_addr来代入第n个节点的网络地址。默认0x0001地址为配网器地址。

trans_cnt：对于需要应答的消息，每次发送都会等待应答消息一定时长（默认2秒），超时便会重传；等待时间内收到应答，则不会重传。对于无应答消息，由于不知道接收方是否收到了消息，都会按本参数发送相应次数。0x03表示总计传输次数为3次，0x01即为只传一次，不重传。应答超时时长可在 app_vendor_model_cli.c 中的 cli_msg_timeout 静态变量处修改。

period：重传间隔，数据量较多、网络内同一时刻的消息数较多，建议重传间隔加大。

rand：随机延迟，图中为0即没有加延迟。可以使用（tmos_rand()%200）来设置一个0～199范围内的随机数。这个值为1600时会延迟1s发送，设置0～199则延迟不超过125ms。

tid：用于应用层判断消息是否重复，是回复还是丢弃。比如说配网器往某个节点发送一个无应答消息，tid标号为0x11（3次重传的tid均为0x11）；接下来再往某个节点发送一个有应答消息，tid标号即为0x12。客户端(_cli)使用标号0～127，服务端(_srv)使用标号128～191。

send_ttl：在mesh协议中占7位。默认值为255（不是最大值，是指使用系统默认TTL值），用户指定的话最大值为127（0x7F）。可以根据预计消息转发的跳数来设置最佳TTL值以减小广播承载层压力。

类似的，服务端透传模数据向客户端发送函数，一个有应答机制，函数为：int  vendor_message_srv_indicate(struct send_param *param, uint8_t *pData, uint16_t len)；

一个无应答机制，函数为：int  vendor_message_srv_send_trans(struct send_param *param, uint8_t *pData, uint16_t len)，两者只有有无应答的区别，参数相同。

注意：服务端向客户端发包，才可用indicate；若服务端向另一个服务端模型发包，由于服务端是没有注册indicate操作码对应的函数的，故只能用trans。只有客户端有注册indicate操作码对应函数。

发送参数与客户端一致，参考上面的结构体。

上面展示了如何在用户层面发出数据，接下来展示如何显示接收到的数据，这样以来就能将透传模型最基本地用起来了。

在app.c中有如下函数↓。官方例程中打印了部分数据，没有将透传内容全部打印出来。可以在下图的函数中添加相应代码来打印全部数据。

同样可以在这个函数接下来的判断中作相应处理↓

小贴士：①使用CH582官方提供的透传模型，不一定要是客户端与服务端互相发消息，因为该模型主要是透传数据使用，不存在对于模型状态的存储和请求（比如说智能灯的当前状态是开，收到指令后下一个状态是关，状态切换时需要广播一个消息表示状态切换成功），客户端给客户端发消息也可。

②CH582是单线程单片机，不能同时处理多个消息，也不能同时处理收和发，故不要让多个节点同时给同一个节点发消息，可以在发包节点调整为不同的重发间隔，或者加上随机延迟参数，否则会造成严重丢包。

③若接收的数据较长，全部打印出来可能会影响丢包率，尤其是对于作为需要管理多个节点的“中心节点”的配网器来说。