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: Borna Vojdani <email@hidden>
- Date: Thu, 23 Aug 2012 13:56:51 -0700
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 <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
_______________________________________________
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