原文出处:煜寒了 php
在写这个博客以前,空余时间抽看了近一个月的文档和Demo,系统给的解释很详细,接口也比较实用,惟独有一点,对于设备的惟一标示,网上众说纷纭,在这里我目前也尚未本身的看法,只是在不断的测试各类状况,亲测同一设备的UUID对于每台iPhone设备都不同,只能尽可能保证设备的惟一性,特别是自动重连的过程,让用户没有感知。html
我以前也找了好久,发现CBCentralManager和CBPeripheral里边都找不到和Mac地址有关的东西,后来发现通常是外设在Device Information服务中的某个特征返回的。通过与硬件工程师的协商,决定APP端将从这个服务中获取到蓝牙设备以及个人iPhone手机的蓝牙Mac地址,为自动链接的惟一性作准备。ios
这里通过和硬件工程师的测试,发现设备端在获取手机蓝牙MAC地址的时候,当用户手机重启以后,这个地址也是会随机变化的,也就是说,做为开发者,只有设备的MAC地址可以保持惟一性不变化。git
有疑问的朋友能够先去这里瞅一瞅
一个关于蓝牙4.0的智能硬件Demo详解github
下面是两台iPhone6链接同一台蓝牙设备的结果:数组
1ide 2函数 3测试 4ui |
|
iOS的蓝牙开发很简单,只要包含一个库,建立CBCentralManager实例,实现代理方法,而后就能够直接和设备进行通讯。
发现附近的特定蓝牙设备
1 |
|
首先能够定义一些即将使用到的UUID的宏
1 2 3 |
|
若是不是把手机做为中心设备的话,这些没有必要设置。
这里我也没有用到,仅仅是提了一下,具体操做后续添加。
对于生成UUID,你们能够谷歌一下,直接经过mac终端生成32位UUID。
1.声明属性
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
2.遵照协议(这里我用到了table)
1 |
|
3.初始化数据
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
4.实现蓝牙的协议方法
(1)检测蓝牙状态
1 2 3 4 5 6 7 8 9 10 |
|
注:[_manager scanForPeripheralsWithServices:@[[CBUUID UUIDWithString:@"FF15"]] options:@{CBCentralManagerScanOptionAllowDuplicatesKey : @YES }];
中间的@[[CBUUID UUIDWithString:@"FF15"]]
是为了过滤掉其余设备,能够搜索特定标示的设备。
(2)检测到外设后,中止扫描,链接设备
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
(3)链接外设后的处理
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
(4)发现服务和搜索到的Characteristice
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
|
(5)获取外设发来的数据
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 |
|
(6)其余辅助性的
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 |
|
在和硬件之间的数据发送和接受,用的都是byte数组。最后,添加一个存储已链接过得设备
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
|
最主要是用UUID来肯定你要干的事情,特征和服务的UUID都是外设定义好的。咱们只须要读取,肯定你要读取什么的时候,就去判断UUID是否相符。 通常来讲咱们使用的iPhone都是作centralManager的,蓝牙模块是peripheral的,因此咱们是want datas,须要接受数据。
1.判断状态为powerOn,而后执行扫描
2.中止扫描,链接外设
3.链接成功,寻找服务
4.在服务里寻找特征
5.为特征添加通知
5.通知添加成功,那么就能够实时的读取value[也就是说只要外设发送数据[通常外设的频率为10Hz],代理就会调用此方法]。
6.处理接收到的value,[hex值,得转换] 以后就自由发挥了,在这期间都是经过代理来实现的,也就是说你只须要处理你想要作的事情,代理会帮你调用方法。[别忘了添加代理]
关于write我这里还有些注意的地方要强调!!!!
并非每个Characteristic均可以经过回调函数来查看它写入状态的。就好比针对 immediateAlertService(1802) 的 alertLevelCharacteristic(2A06),就是一个不能有response的Characteristic。刚开始我就一直用CBCharacteristicWriteType.WithResponse来进行写入始终不成功,郁闷坏了,最后看到每一个Characteristic还有个属性值是指示这个的,我将每一个Characteristic打印出来有以下信息:
1 2 |
|
这个的properties是什么刚开始不知道,以为他没意义,后面才注意到properties是Characteristic的一个参数,具体解释以下:
1 2 3 4 |
|
能够看到0x04
对应的是CBCharacteristicPropertyWriteWithoutResponse
0x0A
对应的是CBCharacteristicPropertyNotify
因此 immediateAlertService(1802) 的 alertLevelCharacteristic(2A06)是不能用CBCharacteristicWriteType.WithRespons进行写入,只能用CBCharacteristicWriteType.WithOutRespons。这样在之后的开发中能够对每一个Characteristic的这个参数进行检查再进行设置。
最后讲一下关于蓝牙绑定的过程,在iOS中,没有讲当绑定的过程,直接就是扫描、链接、交互。从而不少人会认为,链接就是绑定了,其实否则。在iOS开发中,链接并无完成绑定,在网上找到了个很好的解释:
you cannot initiate pairing from the iOS central side. Instead, you have to read/write a characteristic value,
and then let your peripheral respond with an "Insufficient Authentication" error.
iOS will then initiate pairing, will store the keys for later use (bonding) and encrypts the link. As far as I know,
it also caches discovery information, so that future connections can be set up faster.
就是当发生读写交互时,系统在会和外设进行绑定操做!!!
如题,手机做为主设备,在使用CoreBluetooth时候,想获取蓝牙的数据广播包。在使用
1 |
|
方法时候获取的advertisementData打印出来只有
1 |
|
三个属性对应的值,但这并不是广播包的数据。例如安卓能够经过scandata来获取到广播包的值,那么iOS这边我应该怎么作呢?
好像苹果这边禁止读取这种广播内容的的,真要的话你可让硬件那边把数据作到kCBAdvDataManufacturerData这个字段里面。
原文:http://bbs.520it.com/forum.php?mod=viewthread&tid=3033&page=&extra=#pid33613