Thus I would be inclined to do things the slow-but-certain way of collecting a list of Bluetooth addresses first (over 10-30 seconds) and then stop the scan and go through the list and connect to each (unknown) device to identify it.
Actually, I did things the slack way: list all Bluetooth device name+addresses (some don't have names), except for device (addresses) that I *know* from my "seen this before" list are *not* devices of the type I am connecting to.
Thus, the list includes devices that:
1/ are of the type I am connecting to (because they are on my "seen this before" list as such)
2/ *might* be of the type I am connecting to (because they are *not* on my "seen this before" list)
and when the user selects a device to connect to, it might be one of the maybe-it-is-or-maybe-it-isn't types, and when I go to connect to it, then I find out:
- yes, it's the type I am connecting to, and I add it to the list as "this address is a device of the right type", and all is good
- no, it's not the type I am connecting to, and I add it to the list as "this address is *not* a device of the right type" and fall back to showing the device select activity again
So what will happen is that sometimes the user will select a device that is not a relay board, and when they press the Ok/Select button, they'll be returned to the selection list to have another go, but the nice-try-no-cigar not-a-relay-board device is now not on the list.
A long press of the Cancel button clears the "seen this before" list, just in case somehow an address is accidentally blacklisted, but that problem has never actually occurred (yet). I'm pretty certain that if I had not implemented this reset/fix feature, then the problem would have occurred ;-)