In iOS not possible to get mac address of CBPeripheral object. Now I have no. of BLE devices with different UUIDs but with same peripheral name. User has to first register to that BLE device by registration command to that BLE device whose MAC address will get at the time of QR code scanning. But how can I get that to which device user is doing registration as in iOS I am not getting MAC address in peripheral?
3
votes
You need to modify your peripheral so that it exposes some unique identifier via a GATT characteristic. Then you can connect to the peripheral and read the value.
– Paulw11
You could also put a unique id in the advertisement data so you can identify the individual peripheral even before connecting to it.
– Dorian Roy
1 Answers
1
votes
As Dorian Roy notes, a good basic approach is to encode the MAC into the manufacturer specific data in the advertising packet. The MAC is 6 bytes, so you generally should have room if you're not already storing too much there. You can usually get away with the lower 3 bytes if all your devices have the same OUI (the manufacturer prefix).
I've actually designed systems that just advertise the last byte of the MAC, and then double-check by connecting to fetch the full MAC. You've got better than a 50% chance of no collisions until there's about 20 devices advertising in the same room. If there are likely fewer than 3 devices in the same room, then there's less than a 2% chance of collision (but remember, that means 1 in 50 situations will have a collision, so you can't ignore it). Obviously the more bytes you include, the better.
There is a subtle corner case with this design that may or may not matter to you. The device may already be BLE connected to the phone. This can happen due to another app (such as LightBlue), but also due to your own app. Say you connect to a device, and then your app dies and you're relaunched. The device may still be connected to the phone's BLE system, and it won't advertise. The way you discover that device is with retrieveConnectedPeripherals. But in that case, you'll never see an advertising packet. If this MAC-check is a one-time event, then this situation may not be a major issue for you, but it's something to remember if customers complain that your app can't find the device. (The easiest solution is to reboot the device, and if that's not possible, to reboot the phone.)
Paul's suggestion of exposing your MAC via a characteristic is a necessary piece, but it's comparatively slow, and a bit complicated in practice since there may be multiple devices advertising. I typically would start with the advertising packet if you can, and only connect to likely correct devices, and then check their characteristic. Connecting is expensive. Only connect if there's a good chance you're right.
