My application related to bluetooth communication with the peripheral device.Every functionality is working fine right from discovering to connecting .While coming to disconnecting the peripheral from the application i have written code like this
-(void) disconnect
{
if (_selectedPeripheral != nil &&
_selectedPeripheral.state != CBPeripheralStateDisconnected)
{
NSLog(#"Peripheral disconnecting");
[_centralManager cancelPeripheralConnection:_selectedPeripheral];
_selectedPeripheral = nil;
}
}
When i click button this above method is calling and app showing that peripheral is disconnected and when i came out of the application and look into settings /bluetooth/ .Peripheral is showing connected.How to stop connection the peripheral in the device level i.e in the settings .Please help me with the proper solution.
You are unable to guarantee a system level disconnect from the peripheral.
This is a link directly from the CBCentralManager documentation:
cancelPeripheralConnection:
Discussion
This method is nonblocking, and any CBPeripheral class
commands that are still pending to peripheral may or may not complete.
Because other apps may still have a connection to the peripheral,
canceling a local connection does not guarantee that the underlying
physical link is immediately disconnected. From the app’s perspective,
however, the peripheral is considered disconnected, and the central
manager object calls the centralManager:didDisconnectPeripheral:error:
method of its delegate object.
In my experience the physical link is disconnected quickly if you are the only application using the peripheral, but if you potentially are not as Apple clearly states there is a potential for other applications to be maintaining a persisted connection which would cause the physical link to not disconnect even though it is stating to you it has.
We were facing the same issue but we managed to workaround this nasty bug (or API design flaw) by using
Objective C
[peripheral writeValue:x forCharacteristic:y type:CBCharacteristicWriteWithResponse];
Swift
peripheral.writeValue(x, for: y, type: .withResponse)
It's strange that iOS doesn't cancel the physical connection to the peripheral we implemented in the peripheral to perform the disconnect, so we send a string indicating a disconnection should happen.
We used
Objective C
[peripheral writeValue:x forCharacteristic:y type:CBCharacteristicWriteWithoutResponse];
Swift
peripheral.writeValue(x, for: y, type: .withResponse)
and the peripheral disconnects as expected.
Hope this helps anyone facing the same issue by this CoreBluetooth API flaw.
x is the specific cmd supported in your peripheral device (i.e Firmware)
y is the specific characteristic you want to send the value
I know this is an old thread, but I figured I'd add a potential solution here for others.
What you could do is issue a command that causes the peripheral to reboot, resetting the Bluetooth connection. If your device has such a command that you can issue through Bluetooth, you're in luck, otherwise, you'll need access to the firmware for the peripheral in order to add a new command that does this. I'm not a firmware guy, so I can't tell you what exactly you need to do; all I know is the device I'm working with has such a command (it is a proprietary command specifically for our device, not part of the Bluetooth protocol) and that allowed the disconnect to be guaranteed as long as I issue it before calling cancelPeripheralConnection.
Related
In my iOS app I am able to successfully connect to BLE peripherals, discover service and subscribe to characteristics so that app gets notified whenever there is a change in characteristic value. All these happens with no issues as long as app runs in background.
But issue occurs when state restoration happens. In centralManager:willRestoreState: method, I am able to retrieve previously connected peripherals using the method retrieveConnectedPeripheralsWithServices:. But nothing happens when I call discoverServices: method on the retrieved peripheral. peripheral:didDiscoverServices: method never gets called. The value of retrieved peripheral's services property is also null. Does iOS not cache the services and characteristics ?
Note: Our BLE peripheral advertises service initially. When the app launches for first time, it reads value from peripheral and writes user specific data to a characteristic. Post writing, peripheral stops advertising services. But firmware engineer claims that even though service is stopped by peripheral, peripheral retrieved from state restoration should have the cached service. Is it true ?
Have you checked the connection state of the peripherals that you have retrieved via retrieveConnectedPeripheralsWithServices:? The CoreBluetooth framework has some quirks that you need to be aware of, one being the behaviour of the retrieveConnectedPeripheralsWithServices: method:
When you obtain the peripherals via the aforementioned method they might only be connected on the system level (iOS) but not within your app (see the Discussion section in the API documentation). Therefore, you still have to call connect on the peripherals before you can use them properly. Here is the corresponding part from the API documentation:
The list of connected peripherals can include those that are connected by other apps and that will need to be connected locally using the connectPeripheral:options: method before they can be used.
Regarding the caching of services: iOS caches any discovered service and corresponding characteristic. There are only to ways to force iOS to update the cache:
a BLE power cycle, e.g., turning off and on BLE in the Settings App or restarting your iOS device
send a Services Changed notification via the GAP service from the peripheral side (requires an active connection)
Note: You can also activate log messages from the Bluetooth Stack via the Bluetooth Configuration Profile. They can be quite helpful when debugging BLE related issues especially with custom hardware involved (even though the logs are a bit cumbersome to use).
I have a use case where my objective-c application needs to immediately use iBeacon after it's been terminated in order to wake the application up from a terminated state, connect to BLE and send a command to the device. I have a larger longer running post found here that you can check out for my code if need be.
The Problem
The problem so far, happens when I run the application, search for previously paired devices and/or scan for peripherals, find my BLE device and connect. Once connected the user pairs the BLE connection so that they can send encrypted characteristic data over BLE connection. Without pairing (aka auth/bond in the device's naming conventions) the user cannot send the data to the device at all. It never makes it there. As soon as you pair you can send the command...
When I terminate the app, in the applicationWillTerminate method, I run through this code...
- (void)applicationWillTerminate:(UIApplication *)application {
NSLog(#"*** Application Will Terminate.");
NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
NSNumber *mode = [userDefaults objectForKey:#"deviceConnectedMode"];
if([mode intValue] == CONNECTED_MODE_INDICATOR) {
[self.bluetoothManager sendCodeToBTDevice:#"magiccommand1"
characteristic:self.bluetoothManager.wipeCharacteristic];
//I have been turning this command on and off in testing to see if I can get it to work better while disconnecting in the device rather than in the app...
//The command magiccommand2 wipes the auth/bond inside of the device
// [self.bluetoothManager sendCodeToBTDevice:#"magiccommand2"
// characteristic:self.bluetoothManager.disconnectCharacteristic];
//Place where I attempt to stop being connected to BT
[self.bluetoothManager disconnectDevice];
[self.beaconManager startMonitoring];
NSLog(#"*** Application terminated from connected mode!");
} else {
NSLog(#"*** DriveCare terminated without violation!");
}
}
What I am trying to accomplish
The magiccommand1 and magiccommand2 commands are just silly test strings (for now, 128 bit tokens later) that the device is listening for over the serial port. Once they receive the commands they react by attempting to wipe the auth/bond on the device and also disconnecting from BLE in the device.
So the only way I can seem to get the app to wake up from a terminated state is with iBeacon. So I am having to do a bunch of seemingly dirty stuff here just to get this round peg in a square hole. In the app's lifecycle it connects and pairs and when I terminate I want it to completely be removed as a connected device from BLE. My hope is that iBeacon will wake up the app, connect back to BLE, shut off iBeacon monitoring and then send a command to the BLE device from a terminated state. This turning on/off or connecting/disconnecting from iBeacon to BLE and back would most likely cause the user to have to re-pair and I don't want this.
More Problems
When I call [self.centralManager cancelPeripheralConnection:self.thePeripheral]; the iOS system level BT manager seems to auto reconnect almost instantly (because of the pairing) so there is no time for the connection to be severed and iBeacon to be picked up again. If I attempt to disconnect from my centralManager instance before sending the disconnect command to my box (as seen above in code commented out) they obviously wont send either. If I just use only that CBCentralManager disconnect method it isn't enough for iBeacon to begin being detected as the iOS system is still paired with the device. Lastly, if I then go into my iOS system BT manager and choose "Forget this device", the iBeacon gets picked up again and my didEnterRegion method fires!
This is a lot of back and forth between iBeacon and BLE and I just wish I didn't even need iBeacon to wake up the app. I have all info.plist background BLE and iBeacon services turned on. If I don't connect to BLE at all and never pair once and connect my device, the local app notifications slide in without problem letting me know that the iBeacon didEnterRegion and didExitRegion methods are being fired without trouble.
What am I doing wrong here?
I figured out this answer! I was sort of on the right path... It's not a great idea to try and disconnect from BT pairing in order to try to get iBeacon delegate methods to fire. It causes a lot of weird dirty code, tightly coupled things that shouldn't be and worse... the dreaded spaghetti code.
Instead my solution was to build a board with 2 Bluetooth chips in it. One as a dedicated iBeacon chip and the other as a permanent connected/paired/auth and bonded chip. This way there does not need to be any timed connection and disconnection events to be monitored (or worse... resolved race conditions). Waiting for a device to disconnect in iOS is not a true disconnect, it is instead when the iOS system thinks it's disconnected (in the phone's side of things). The things going on inside of the peripheral system paint a very different picture...
This 2 chip approach made life so much easier on the development side because now anytime you need the application to wake up to handle something, you can power cycle the iBeacon device and receive the appropriate event.
Side note: When using iBeacon the didEnterRegion method fires almost instantly where as the didExitRegion can take 30 or more seconds sometimes to fire. Therefore if you need immediate beacon detection resolution you should try to make sure the iBeacon is being powered on and not off for this... if even possible.
I want my users to be able to track their heart-rate with my app. So I use CBCentralManager for that. Everything works fine if no other app is connected to the heart-rate sensor yet. The problem I have is if I start f.e. Strava or Endomondo first. Then I just can't find any devices any more. The other way round everything works fine, so I guess I am missing an options somewhere?
What I currently do:
I instantiate my CBCentralManager like so
centralManager = CBCentralManager(delegate: self, queue: DispatchQueue.main)
which will cause the delegate method for connection to be triggered
func centralManagerDidUpdateState(_ central: CBCentralManager) {
let heartRateServiceUUID = CBUUID(string: "180D")
let services = [heartRateServiceUUID]
switch central.state {
case .poweredOn:
centralManager.scanForPeripherals(withServices: services, options: nil)
and from there on no peripheral are found.
But again, when I force quit other apps like Endomondo or Strava and then start my app, everything works fine.
Ok, I just found the solution to my main problem myself. So anybody who might have the same issue:
Once you are connected to a device remember it's UUID
When you want to reconnect to it you don't need to scan, just use centralManager.retrievePeripherals(withIdentifiers: [the id's of the devices you know])
This will give you back a list of CBPeripherals and you simple connect to them like you would have after searching for them.
The only thing that I still don't know:
Even when i uninstall Endomondo, start my app first, they still can discover my heartrate monitor... And I suppose even if they remember the UUID it will be in UserDefaults i suppose, so they can't reconnect using centralManager.retrievePeripherals(...). So I still like to know what I'd need to change in order for that to work...
See Best Practices For Interacting With A Remote Peripheral Device for full details on how to connect to devices you already know about.
The main issue you're encountering is that most BLE devices stop advertising once they have a connection. Since they aren't advertising, you can't see them in a scan. In this particular case, the BLE device is connected to the iPhone you're running on, but that doesn't change anything. It's still not advertising.
To deal with this, you want to ask the iPhone for connected devices that have the service you want, using retrieveConnectedPeripherals(withServices:). This is a very fast, synchronous call, and you generally should do it before calling scanForPeripherals(withServices:options:).
There are several other steps that you generally should do. The precise order and logic depends a little on your situation, but the linked flowchart above walks you through one approach. Basically it will look something like this:
Call retrievePeripherals(withIdentifiers:) to find a peripheral you already know the identifier for. Note that this just tells you the system knows about the peripheral; it doesn't mean it's currently nearby. Calling connect on it may never succeed.
Call retrieveConnectedPeripherals(withServices:) to find a peripheral that is already connected to this iPhone and advertises your service. You still need to call connect on it for your process, but it should succeed.
If all the rest fails, then call scanForPeripherals(withServices:options:).
Update:
It appears that BLE4.0 chipset did only support one connection so when a centralmanager connected to a BLE4.0 device it stopped advertising and established a connected layer.
With BLE4.1 chipset it added support for multi-role connection. It is possible that the heart-rate sensor use newer BLE technique that support more than one connection.
https://e2e.ti.com/blogs_/b/connecting_wirelessly/archive/2016/11/30/bluetooth-low-energy-multi-role-demystified
It is still unclear why your app wont connect if the other apps are connected. Can you post all your code?
My old answer:
"Core bluetooth and Bluetooth Low Energy can only handle one connection for each peripheral which means that if your app(CBCentralManager) establish a connection with a peripheral(UUID) it establish a message layer between the central and peripheral so other apps cant interfere the connection to that peripheral unless you disconnect the first app. This is how Bluetooth Low Energy works."
Apple Guides and Samples:
https://developer.apple.com/library/content/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/AboutCoreBluetooth/Introduction.html#//apple_ref/doc/uid/TP40013257-CH1-SW1
Apple Core Bluetooth API:
https://developer.apple.com/reference/corebluetooth
I wonder about the semantics of CBManager's retrieveConnectedPeripheralsWithServices. Everytime I'm using this I get CBPeripheral instances back with state CBPeripheralStateDisconnected.
It's not a problem to connect again, but isn't this method supposed to return connected peripherals?
Unfortunately, this is intended behaviour. It is a bit counterintuitive I have to admit but the peripheral state is always related to your app. That means if you have connected/paired/bonded the peripheral using another app or via the bluetooth system settings, it will still show as disconnected within your app. If you have connected some peripherals within your app they will show as connected.
In Core Bluetooth, after connecting to a device, I turn off the device and the device is disconnected. But when I turn on the device again, there is no didDiscoverPeripheral called again. How can I reconnect to the device again?
When you disconnect a device with cancelPeripheralConnection the didDisconnectPeripheral delegate method will be invoked. However from iOS 6.0 the device remains connected for about 40-50 seconds (or more), so no didDiscoverPeripheral will be invoked in that timeframe. If you want to "discover" it again just call the retrieveConnectedPeripherals method and you will get the reference in didRetrieveConnectedPeripherals.
However, the best solution is to save the device's UUID and use that to reconnect with the retrievePeripherals method. This will invoke didRetrievePeripherals and you can reconnect with connectPeripheral. This is the fastest way to reconnect to a device, no scanning is required in this case.
When you do a scan with scanForPeripheralsWithServices, it will normally only notify you once for a particular device address. You can change this to report duplicates by specifying the option CBCentralManagerScanOptionAllowDuplicatesKey. Or you can have your app detect that the other device disconnected using a timeout, and restart your scan.
#Andras gave me the right path, but his answer is not complete anymore since iOS7.
The best way to reconnect to a previous device is to use the retrievePeripherals(withIdentifiers:) method.
This method does not call a delegate, but directly returns you a list of Peripherals, corresponding to the list of UUID passed in parameters.
if let peripheral = self.centralManager.retrievePeripherals(withIdentifiers: [uuid]).first {
self.peripheral = peripheral // <-- super important
self.centralManager.connect(peripheral, options: nil)
}
Please check the "super important" line of the above code: The method connect(_:option:) does not retain the peripheral, and if you don't do it yourself, the connection will always fail without any callback since the peripheral objet will be destroyed.
In CoreBluetooth all management is done by application layer.
In your case, what I would do it is to listen for disconnect event than in same event, reconnect the peripheral.
The connection method is an inexpensive one and assure you to reconnect to your device when it is back in range.
Note that if you explicitly disconnect the device, you received the same disconnect event, but you haven't to call the reconnect method.