I saved the UUID in NSUserDefaults to allow automatic reconnection on further app starts. However, when the UUID is nil and the first connect fails / times out / whatever, reconnection won't work. Also, as of the official Bluetooth Accessory Design Guidelines for Apple products, the peripheral doesn't have to use a random device address. Only the iPhone is specified to use a random address, and the peripheral is required to be able to resolve and connect to it. The Bluetooth accessory should be able to resolve a Resolvable Private Address in all situations. Due to privacy concerns, the Apple product will use a Random Device Address as defined in the Bluetooth 4.0 specification, Volume 3, Part C, Section 10.8. In my case, the peripheral has a fixed address. How should iOS even know that it is the same peripheral, if the peripheral uses a random address? Except through pairing, addresses would change, and therefore also the UUID. However, in the stationary case where the BdAddr is fixed, t doesn't make sense to me that a UUID cannot be already provided at app startup - and maybe even consistent over phones so that I know from the start: hey in retrieveperipherals look for this specific UUID and it is always the same device. On Thu, Aug 23, 2012 at 11:34 PM, Peter Skinner <peter@tenonedesign.com> wrote:

Hi Joakim,

Like Borna, I had been using the UUID as a key in a dictionary.

I guess I'm not the best privacy advocate, but from an API standpoint it's convenient to have a valid UUID anytime I'm given a CBPeripheral.

Peter

Ten One Design 201-965-0200 tenonedesign.com @psidentity

On Aug 23, 2012, at 12:04 PM, Joakim Linde <joakim@apple.com> wrote:

Hi Etan and Peter,

Please note that the lack of UUID does not prevent you from doing what I think you want to do (if that's not the case, then please explain to me what you are trying to do). In your app you can still check if it is the same CBPeripheral object that is being reported over and over again. Since the peripheral should use a random resolvable address that changes at least ever 15 minutes, the address will change and the device will appear to be a "new" device. The only way to long term be able to track device is to connect and pair with it. That way we will get the IRK to resolve the address and present that to you as a UUID.

Thanks, Joakim

On Aug 23, 2012, at 12:35 AM, Etan Kissling <etan.kissling@oberon.ch> wrote:

Hi Peter,

That's actually intended if you look into the header files. It says that a UUID is generated on the first connection. Of course, this leads to problems and does not make sense, as a device can be uniquely identified by its BdAddr that is already nown in the advertising stage. I imagine that the reason for this is again "privacy" related, as UUIDs for peripherals change from phone to phone.

An option would be to send the BdAddr in the advertising report.. With this, you could at least compare devices. However, you won't be able to create a custom CBPeripheral instance from it by supplying it to retrievePeripherals.

I also filed a bug report for this, and it was closed as being a duplicate. However, the more bug reports there are for a single problem, the more importance it receives and the higher is a fix prioritized.

Etan

On Thu, Aug 23, 2012 at 12:51 AM, Peter Skinner <peter@tenonedesign.com> wrote:

Hello,

I've encountered a surprising situation. In iOS6 b4, didDiscoverPeripheral delivers a CBPeripheral with UUID set to nil. This only happens the very first time CoreBluetooth encounters a new bluetooth hardware mac address. The next time it sees that address, it uses what seems to be a cached version of CBPeripheral.

The UUID is set to a proper value sometime after discovery. We have several applications published right now that count rather heavily on UUID having a non-nil value in didDiscoverPeripheral.

Is it time to start updating those applications and stop relying on the UUID, or should this be a bug report?

If anyone has seen this, or knows what the expected behavior is, I'm all ears.

Thanks!

Peter Skinner

Ten One Design 201-965-0200 tenonedesign.com @psidentity

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/etan.kissling%40oberon...

This email sent to etan.kissling@oberon.ch

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/joakim%40apple.com

This email sent to joakim@apple.com

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com