Corebluetooth: What Is the Lifetime of Unique Uuids

CoreBluetooth: What is the lifetime of unique UUIDs

Long story short, YES you can use the UUID to reconnect to the same device even after you close the application (in exactly the way you say).

I assume however, that you are not actually pairing with peripheral. That's a big problem right there. You need to actually establish the pairing request and get the peripheral to show up in the bluetooth table. The UUID will then be solidified with the iOS device and will remain until you flush the Network Settings of the iOS device.

The other possibility is that your BLE device has a firmware problem, wherein after you disconnect, it forces itself into advertising mode or something. This will also mess with your ability to reconnect. Let me know if you have any questions!

How long is a CBPeripheral's stored UUID valid for reconnection?

In my opinion, directly holding onto the CBPeripheral objects in an NSArray or NSDictionary is the easiest way. Connect and disconnect as many times as you would like (without scanning each time) to a CBPeripheral once it is retained. The only thing you have to be mindful of is the CBCentralManager's state. You will receive state changes by implementing the CBCentralManagerDelegate centralManagerDidUpdateState: method. If the state changes to anything except CBCentralManagerStatePoweredOn then you need to get rid of all of your retained CBPeripheral objects and do another scan once the state turns back on.

According to the apple docs:

If the state moves below CBCentralManagerStatePoweredOff, all CBPeripheral objects obtained from this central manager become invalid and must be retrieved or discovered again.

However, I would suggest invalidating/releasing all of your CBPeripheral objects if the state moves below CBCentralManagerStatePoweredOn. It is no secret that CoreBluetooth is a little buggy and this has seemed to help me avoid "invalid CBPeripheral" warnings in the past.

If you would like to identify a specific CBPeripheral after the app is reset or the device is shut down or even a network settings reset (cache reset) then you will need to have a custom implementation that uniquely identifies another device not based on anything CoreBluetooth offers you for free.

Here is how I do it in one of my apps:

  1. Alloc/Init a NSUUID object the first time the app is launched and save it in NSUserDefaults as a NSString. Think of this UUID as a pseudo-MAC address for your app. This UUID will remain constant for the lifetime of the app.
  2. centralManager discovers a CBPeripheral, connects, and then reads the value for a specific characteristic
  3. CBPeripheral device responds to the request with its non-bluetooth-related UUID from step 1. I also include a whole bunch of user provided information in this step along with the UUID.
  4. centralManager saves this UUID (and any other information you include) using Core Data or NSUserDefaults if it hasn't already.
  5. Repeat steps 2-4 for all newly discovered CBPeripherals.

Now, whenever centralManager discovers a CBPeripheral it can check its local database of UUIDs and determine which device is related to this CBPeripheral without a doubt.

See Paulw11's answer for how reconnect while in the background. Note that if your app has been quit by the user (swipe the app's preview up after pressing the home button twice), any long term "connects" will be cancelled even if the app is restarted.

Corebluetooth, How to get a unique UUID?

The peripheral uses a random resolvable address that changes at least every 15 minutes, at which point the peripheral will appear to be new. To change this behavior you need to pair with the peripheral, then you will see the UUID and it will be persistent.

CoreBluetooth peripheral identifier changes

Unfortunately, I dont think you get around iOS's changing of peripheral UUIDs.

Depending on the control you have to change the BLE services/characteristics on the scales, you could advertise an additional service which contains a characteristic where you put a custom identifier in.

On iOS you could scan for that service and read the characteristics value to identify the scale.
This way, you would not be dependent on the UUID the OS assigns to your peripherals.

Hope this helps!



Related Topics



Leave a reply



Submit