【已解决】涂鸦BLE配网对接开发

蓝牙 BLE设备、蓝牙 MESH设备、蓝牙 Beacon设备、Sub-G设备等


愚者千虑必有一得
Posts: 415

dongyun 2022年 Oct 18日 18:03

"输入到涂鸦SDK的是 AttValue,涂鸦SDK输出也是AttValue ,opcode, atthandle 需ble平台自己填充。"


这里理解起来有点问题,我们通过sniffer抓取了 涂鸦蓝牙配网的 完整过程。
看到在配网过程 有多种 opcode 操作,比如 read_by_group, read_by_type, write_req 等等,
如果说送给 涂鸦SDK时,去掉 opcode 和 att handle, 那涂鸦SDK内部如何区分 不同的req呢,如何响应这些 req 呢

opcode 操作 sdk不关心,tuya app/sdk也定义了一套协议(包含配网、控制等),sdk是按照那套协议来工作的。

你现在的是期望实现什么功能?支持涂鸦蓝牙配网?自己开发自定义的蓝牙功能?

这个unpack error是在解你自定义的蓝牙数据包的出现的?还是使用app控制的时候出现的?


Tags:
dongyun
Posts: 17

Re: 涂鸦BLE配网对接开发

现在是 对接 涂鸦App的蓝牙配网功能,完成蓝牙配网即可。
按照前面的说明,设备收到App发送的ATT数据后,只提取 Attvalue(去掉opcode/atthandle) 送给 涂鸦SDK,没有了 opcode/atthandle 就无法识别 这个 att数据是 干什么了吧。
如果涂鸦sdk不关心opcode,那是不是说涂鸦SDK所接收的数据都是一个固定opcode 和 atthandle(具体是哪个呢,抓包看到 Write_CMD,atthandle好像都是 0x000c)?
涂鸦SDK发送数据时是使用 tuya_ext_bt_send 吧,这个API输入参数也只是 Attvalue的话,那这个数据是 notify ,还是 response 呢?

dongyun
Posts: 17

Re: 涂鸦BLE配网对接开发

从抓包来看,Write_CMD的atthandle 都是 0x000c,Notify的atthandle是 0x000e, 这些是不是 都是固定值?
TY_BT_EVENT_RX_DATA 和 tuya_ext_bt_send 只给涂鸦SDK使用的话,是不是可以理解为:
TY_BT_EVENT_RX_DATA: 只接收Write_CMD 且 atthandle == 0x000c
tuya_ext_bt_send :只用于notify,且 atthandle == 0x000e

那抓包看到的其它opcode,比如 Read_by_group/read_by_type ..., 这些命令的response,不是涂鸦SDK回复的吗?
如果不是涂鸦SDK回复的,demo代码也没有看到 涂鸦SDK 设置什么profile信息呢

hearge
Posts: 39

Re: 涂鸦BLE配网对接开发

从抓包来看,Write_CMD的atthandle 都是 0x000c,Notify的atthandle是 0x000e, 这些是不是 都是固定值?

针对某一平台来说,服务是固定的。实际handle在平台是不变的

TY_BT_EVENT_RX_DATA 和 tuya_ext_bt_send 只给涂鸦SDK使用的话,是不是可以理解为:
TY_BT_EVENT_RX_DATA: 只接收Write_CMD 且 atthandle == 0x000c
tuya_ext_bt_send :只用于notify,且 atthandle == 0x000e

---是的

那抓包看到的其它opcode,比如 Read_by_group/read_by_type ..., 这些命令的response,不是涂鸦SDK回复的吗?
如果不是涂鸦SDK回复的,demo代码也没有看到 涂鸦SDK 设置什么profile信息呢

---这些是需要平台(开发环境)做的.简单来说,平台配置涂鸦服务->等待连接->回应服务发现,MTU交换等流程->通信建立完成->基于tuya服务建立通信链路。
如下所示:1910即涂鸦服务,2b10是设备notify的uuid,2b11是对端write的uuid,Tuya的服务需要在平台(开发环境)实现

Attachments
a4c2e689db8c39f09daf9c98619319fa.jpg
dongyun
Posts: 17

Re: 涂鸦BLE配网对接开发

hearge 2022年 Oct 19日 10:24

从抓包来看,Write_CMD的atthandle 都是 0x000c,Notify的atthandle是 0x000e, 这些是不是 都是固定值?

针对某一平台来说,服务是固定的。实际handle在平台是不变的

TY_BT_EVENT_RX_DATA 和 tuya_ext_bt_send 只给涂鸦SDK使用的话,是不是可以理解为:
TY_BT_EVENT_RX_DATA: 只接收Write_CMD 且 atthandle == 0x000c
tuya_ext_bt_send :只用于notify,且 atthandle == 0x000e

---是的

那抓包看到的其它opcode,比如 Read_by_group/read_by_type ..., 这些命令的response,不是涂鸦SDK回复的吗?
如果不是涂鸦SDK回复的,demo代码也没有看到 涂鸦SDK 设置什么profile信息呢

---这些是需要平台(开发环境)做的.简单来说,平台配置涂鸦服务->等待连接->回应服务发现,MTU交换等流程->通信建立完成->基于tuya服务建立通信链路。
如下所示:1910即涂鸦服务,2b10是设备notify的uuid,2b11是对端write的uuid,Tuya的服务需要在平台(开发环境)实现

配置涂鸦服务
SDK demo里面是哪里配置的?没有看到相关代码,如果有配置服务操作,也可以理解那些response如何回复了

hearge
Posts: 39

Re: 涂鸦BLE配网对接开发

SDK demo是没有的。 服务一般是一个大数组,在平台(开发环境)适配。
sdk demo只关注stack init,adv,scan,send,recv这些抽象的接口。 demo 调用init时需要平台默认把这个服务起来。
Read_by_group/read_by_type这些也都是平台回应的b[/b],sdk不关注,配置好服务后一般平台也不需要关注。

dongyun
Posts: 17

Re: 涂鸦BLE配网对接开发

hearge 2022年 Oct 19日 11:21

SDK demo是没有的。 服务一般是一个大数组,在平台(开发环境)适配。
sdk demo只关注stack init,adv,scan,send,recv这些抽象的接口。 demo 调用init时需要平台默认把这个服务起来。
Read_by_group/read_by_type这些也都是平台回应的b[/b],sdk不关注,配置好服务后一般平台也不需要关注。

这个 服务的数据,不是涂鸦SDK产生的吗? 是由 涂鸦客户 自定义的?

hearge
Posts: 39

Re: 涂鸦BLE配网对接开发

客户需要在平台加上涂鸦的服务,app会识别。如下面的1910的服务,需要客户在平台实现。

Attachments
a4c2e689db8c39f09daf9c98619319fa.jpg
Post Reply