
回复
BLEDeviceFind
扫描到的设备后的 结果(点击查看介绍) 中可以获取到每个设备的 deviceId
,也可以称为 临时性 MAC地址
。deviceId
因为是临时性的所以它会改变。不可以使用它来进行重连。GattClientDevice
。后续所有的蓝牙操作都需要基于这个来进行!!!createGattClientDevice
创建完成之后,就 on('BLECharacteristicChange')
监听了 特征值 。但是在文档中所说需要先调用setCharacteristicChangeNotification 接口或 setCharacteristicChangeIndication 接口才能接收server端的通知
这并不是意味着,是要先调用 这两个接口在去进行监听。实际上:这个并无先后顺序,而是 你在没有调用 上面任意一个接口之前 你的监听都是不会被触发。我发现很多开发者都被这个迷惑了。BLEConnectionStateChange
监听里面,监听到连接成功后就可以获取蓝牙里面的服务端了。BLECharacteristicChange
是监听不到消息的。writeCharacteristicValue
来进行写入动作。writeTrait
来进行写入数据的装配。 ArrayBuffer 用来表示通用的原始二进制数据缓冲区,但你不能直接操作其中的数据
Uint8Array 是一种类型化数组(TypedArray),它是 `ArrayBuffer` 的一种视图, 可以通过它来操作 ArrayBuffer
至于我为什么提出这个问题,是因为我在分包的时候第一次使用的是 `subarray`
导致,虽然视图改变了,但是我在写入时候,通过 "视图" 获取 ArrayBuffer 时候,还是同一个未改变的 ArrayBuffer。导致写入失败。后来发现了改成了 slice
每个固件每次数据包所容纳的数据的大小不一致,而 MTU 就是代表最大的容量
所以要根据 mtu 来进行分包发送
setInterval 是一个周期性定时器,它并不会因为回调没执行结束而等待下一次执行。所以不满足 ble 的同时只能有一个写入的要求
while 是一个会阻塞主线程的循环,所以为了避免出现意外情况就没用
setTimeout 比较符合目前的需求,不过是个暂时性方案,后续会使用多线程改造
一个蓝牙会有n个服务,而每个服务会有n个特征值。
而特征值你可以理解为 每个服务所具有的功能。只有有这些功能你才可以使用它。
比如:
把蓝牙比作: 房屋(蓝牙)
而一个 房屋(蓝牙) 里面又有很多 物品(服务)
解释:物品就比如是 床、空调等用来给你提供服务的
而一个 物品(服务) 又具有很多 功能(特征值)
解释:比如 空调这个物品 ,它用来给你提供服务。
但是,有的空调有 制热功能(特征值) 有的空调又没有。
只有具有 制热功能(特征值) 的空调,你才可以使用 制热。
换句话讲:
只有你获取到具有 写入的特征值(上面代码的writeTrait) 你才可以向设备写入。因为别的特征值的 characteristicUuid 设备不认可。
我刚开始接触蓝牙的时候看文档中的 api和指南 都会有 服务端和客户端 两种。所以很晕不知道咋回事。
对于我写 app 来讲,只需要关注 客户端相关的 api 即可
因为这个 setBLEMtuSize 并不是设置了就可以直接用的,需要等到设备响应才可以使用一些服务。
我遇到这个是因为刚开始的时候 setBLEMtuSize 被我放到最前面,在 固件 未响应的时候就去向 固件 写入 导致失败。
这个问题需要考虑一下,如何改造和执行时机
因为现在获取的都是 动态MAC地址(deviceId) 所以无法根据这个 deviceId 来进行 重连。
目前想法是:固件 连接成功后,获取真实的 mac地址 然后通过 扫描的时候解析 设备广播 来匹配 匹配真实MAC地址 从而获取到 deviceId 。然后进行重连。
但是需要要求固件在广播中携带 真实MAC地址