The problem I have is that the values in the manufacturer data are not already known to the app so i cannot create a descriptor to describe them. They are actually part of an application-level IRK that normally changes at the same time as the MAC. The entry into pairing mode is a special case where they remain unchanged even though the MAC changes.
We do have a bit in the manufacturer data for pairing mode so I can filter out devices not in pairing mode but we prefer to discover those devices then give users specific instructions on how to get their device into pairing mode as instructions can vary by model.
Post
Replies
Boosts
Views
Activity
Hi!
Our accessories currently use their public address only when they are in pairing mode (otherwise they rotate the address periodically). They ship in pairing mode so first time setup usually isn't an issue. The bigger issue is in trying to re-pair a previously paired accessory (that's not in pairing mode) or trying to pair to a second device. To do this the user must put the accessory back into pairing mode. If they do this while the picker is displayed duplicate entries result.
We currently solve for this use case in our custom pairing flow by having specific fields in the advertising data that are guaranteed to not change upon entry into pairing mode. This allows our app to detect the address change and ensure we connect using the proper address.