Joakim, I have been using the UUID as a key in a NSDictionary object because the CBPeripheral object does not conform to NSCoding and cannot be used as a key. With the UUID now nil, is it now impossible for me to have a CBPeripheral or other identifying means as a key in an NSDictionary? And obviously, it is now impossible to do a retrievePeripherals if you have never connected to it. And what if I want to save the ID of a broadcast-only peripheral? I only listen for data in the advertising packets, never connect. Seems like that's impossible now also. Seems a lot of things are now impossible with this change. Borna. On Aug 23, 2012, at 9:04 AM, 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/bornav%40gmail.com

This email sent to bornav@gmail.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