Following off of this question:
Corebluetooth, How to get a unique UUID?
After connecting to a peripheral, I can retrieve its CFUUIDRef, which is unique, and can use it to reconnect via retrievePeripherals. However, I have found that I can not use it to reconnect after closing the application.
Is the unique UUID generated after a connection only valid for the lifetime of the application or are we supposed to be able to save it for later use? I am trying to have my application remember one particular peripheral, but besides peripheral.UUID, I don't know of any other unique identifiers.
Long story short, YES you can use the UUID to reconnect to the same device even after you close the application (in exactly the way you say).
I assume however, that you are not actually pairing with peripheral. That's a big problem right there. You need to actually establish the pairing request and get the peripheral to show up in the bluetooth table. The UUID will then be solidified with the iOS device and will remain until you flush the Network Settings of the iOS device.
The other possibility is that your BLE device has a firmware problem, wherein after you disconnect, it forces itself into advertising mode or something. This will also mess with your ability to reconnect. Let me know if you have any questions!
Related
I have MFi device which uses BLE for control and Classic Bluetooth for audio streaming.
In the App, i use coreBluetooth framework to scan BLE and EAAccessory framework to scan Classic Bluetooth.
I don't want the BLE of target device to be connected if its Classic Bluetooth is not yet connected. So i need to know which EAAccessory is corresponding to target CBPeripheral.
I am familiar with coreBluetooth, there is UUID string to identify the CBPeripheral. But it looks not exist in EAAccessory.
I have an idea but not sure: maybe firmware side can config EAAccessory's serial number and CBPeripheral's manufacture data in advertisement data with the same
serial number, so that App side can check if they are the same.
Dose anyone knows the general way to implement this in App side and firmware side?
I really do not think there is s relationship between the 2. BT and BTLE are managed by different chip at peripheral side and phone side.
Usually in BT you use the MAC address to identify the peripheral on BTLE side the MAC address is not used anymore since iOS at the first connection give its own identifier to the peripheral.
What you can do is probably at firmware side, by exposing a service with a characteristic that somehow relate the 2.
UPDATE AFTER COMMENT
I see, as far as I know there a best practice doesn't exist.The worst part is that you have to handle connections differently, mostly due to how connection are made on iOS side. While on the BLE you can choose a not encrypted connection that would not require paring or bonding, on BT side I guess that bonding is required.
Probably the most simple flow would be, user bond the BT device. Once you are in the app and detect the connected BT device, use a scan method for detect BLE companion device by filtering for a specific service id that your device exposes, once you do that you can also filter discoveries using BLE name without still making a connection.
Adv packet are restricted in size (29 usable byte) but you can also use the scan response (31 byte), that exposes some additional properties such as manufacturer data that will be exposed in a dictionary (kCBAdvDataManufacturerData).
Once you know that is the correct device you can start a connection, that does not require pair or bond but is NOT encrypted (Pair and Bond will require the user to accept the connection inside your app).
I have two BLE devices with the same UUID. Is there any way to connect to both of them so that they are both connected at the same time?
Right now I'm not able to even see both devices simultaneously using a bluetooth explorer, so I assume for the system they appear as just one device. Is it still somehow possible?
I assume that with UUID you mean the MAC-Address (Bluetooth address) of the device. UUIDs are typically used for services and characteristics.
All connection procedures work with the Bluetooth address as the main parameter. So two devices with the same address will be treated as the same device. (In fact, it is a common requirement that MAC-Addresses of Bluetooth devices should be unique, exactly for this reason.)
So it is not possible to connect to two devices with the same address at the same time. (*)
You can find more information about how connection is done in the Bluetooth Core Spec, Vol. 3, Part C, chapter 9.3.5 - 9.3.8.
(*) This is meant in the common way of having a connection to two different devices. Since incoming messages are not distinguishable on Link Layer level between the two devices with identical address (your control will always think there is only one device with the given address out there), you could mess around with this fact, especially in non-encrypted connections (since encryption is negotiated on a device-to-device basis, another device could not join in an encrypted connection, even if it has the same Bluetooth address). But it is definitely not recommended to do so.
If two devices are having the same UUID , then I think they would be consider as a single device. What I would suggest , send a trigger notification to the UUID and check which device will respond first . Secondly , try to send notification to devices put them far apart . The nearer to your smartphone/bluetooth explorer , will get notify first . Bluetooth works on the distance basis, the device which is near to the source will get the notification than the other one.I tried the same with Beacons but end up like you.
I have an app that connects to a CC2541 over Bluetooth Low Energy. I simply want to cache something unique to each device so a user only connects to "their" device. I've tried using
- (NSArray *)retrievePeripheralsWithIdentifiers:(NSArray *)identifiers
and even scanning and comparing the UUID's of the scanned peripherals, but I have to select a newly generated UUID every few app launches. The same code worked well on 8.1 and I rarely (if ever) had to select a new UUID.
I've debated checking the System ID (2A23 uuid) in the Device Information service, but that requires a connection to check the address so I'd have to connect to each nearby peripheral, get and compare the System ID, then either stay connected or disconnect and check the next one.
The CC2541 code I'm running isn't using pairing and I'd like to keep it that way. I'm curious if anyone else has found a solution to this situation.
Having been down this road, spending weeks to find a work-around to the limitations, the only way I have found is if you have control over the hardware and can put your own unique identifier in the advertising packet. While one can make all kinds of assertions about the (in)sanity of this, it is what it is.
I just want to post some code here that may help others in the future.
Put this somewhere outside of a function:
__xdata __no_init uint8 BT_MAC_ADDR[6] # 0x780E;
Put this in your advertData array:
7, //length of data
GAP_ADTYPE_MANUFACTURER_SPECIFIC, //Custom data
0,0,0,0,0,0, //Placeholder bytes
And finally update the advertData before you call GAPRole_SetParameter.
uint8 advertSize = sizeof(advertData);
memcpy(&advertData[advertSize-6], BT_MAC_ADDR, 6);
Sorry for the long title, but we are having a pretty interesting issue with using corebluetooth for ios. We are issuing a call to retrievePeripherals in CBCentralManager and are able to find the previously paired device.
This happens though regardless if the device is on or off though. I can't find anything in apple's documentation as to why it's able to find the device when it is off though and it isn't showing up in Settings -> Bluetooth -> Devices. I'm suspecting that Apple is caching this information but can't find any documentation to confirm this. Also, when the device is off and we issue the connect call, the program continues to execute as normal but the delegate for didFailToConnect never gets called. When the device is turned on, it will connect immediately.
Is there a way to pass a timeout parameter when trying to connect to a device? If not, what would the best solution be to handling reconnecting to a previously used device for an application (we're storing the last connected device within the app).
Two points you need to know about retrievePeripherals: and connectPeripheral:
1.) retrievePeripherals: attempts to retrieve the CBPeripheral object associated with the uuid you supply. Even if the ble device is off (or on the other side of the country) retrievePeripherals: will still return an instance of CBPeripheral that you can call connectPeripheral: on. This is done intentionally so that you can issue a call to a peripheral that is not even around and still automatically connect to it when it comes back into range. It basically creates a marker inside the system bluetooth so that when the device is actually seen, it will know it should connect to it.
2.)connectPeripheral: will not time out unless the communication channel is broken with the actual device. If the iOS device has not seen the device, it will not fail and should not time out (unless some error occurs inside the system bluetooth).
And as for the timeout parameter, there is no documented way inside the CoreBluetooth framework. You can create your own implementation for it, however I believe you'd be better off keeping a list of which peripheral uuid's you've actually called connectPeripheral: on and then just pop them from the list when they connect. If you no longer want to connect to a peripheral in the list call cancelPeripheral: on that UUID, call connectPeripheral: on the other, and swap entries. Good to go.
I want to advertise a single id lets say "stackoverflow1" on a ble device. So people close to the sensor can get this message (welcome to wwdc2012) as popups on the iPhone. That's it! meaning that there is no update on the value or anything else in other words I just want to know which room I came in. In another room there's another sensor adversing "stackoverflow2".
Now the question is, should I put the rooms' sensor (advertiser) as Peripherals and visitors' iPhones as Centrals?
If your answer is yes, can I send this Id in advertising packet? i.e. can I skip connection to the room's peripheral? Please guide me a little but on this
Thanks
Yes, the iPhones should be centrals and the in-room device should be a peripheral. It's perfectly fine to put enough data in the advertisement that the iOS app can do something useful after simply seeing the peripheral advertised without actually connecting to it. That way, multiple centrals/phones can detect proximity at once without a single phone tying up an exclusive connection to the device. Instead of specifying the room in the service name, you should be able to put it in the advertisement data for the device, giving them all the same service name. That way the iOS app doesn't need to know the completely list of rooms (i.e. services) in advance and they can be added to without changing the app.
In short, the gist of what you described should work fine, and seems like a sound approach to me.
You can include information in the advertisement from the peripheral as "Manufacturer Specific" data. Then the iOS application can get it from the advertisement data dictionary using the CBAdvertisementDataManufacturerDataKey.