Re: UUID is nil for newly discovered CBPeripheral
Re: UUID is nil for newly discovered CBPeripheral
- Subject: Re: UUID is nil for newly discovered CBPeripheral
- From: Etan Kissling <email@hidden>
- Date: Fri, 24 Aug 2012 00:59:55 +0200
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 <email@hidden> 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 <email@hidden> 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 <email@hidden> 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 <email@hidden>
> 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 (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Bluetooth-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden