I'm writing a suite of Bluetooth Low-Energy app for iOS 7.
When the app launches, there's a fair chance the peripheral I'm interested in is still connected to the iOS device, and to avoid scanning for the peripheral it would be great to connect immediately. retrieveConnectedPeripheralsWithServices: looks perfect for this, and indeed seems to work as advertised: I get a list of CBPeripherals which are connected to the device via some backgrounded app.
So far so good, but here's the issue:
There's information in the AdvertisementData which I want, but I don't know how to get the AdvertisementData when going this route.
As far as I can see, advertisementData is only available as a result of scanning.
So my question is this:
* Given a CBPeripheral returned by retrieveConnectedPeripheralsWithServices:, how can I get the associated advertisementData for that peripheral ?
One workaround would take advantage of the fact that the device was likely connected to another of the apps in my own suite, so I could persist the advertisement data myself in storage shared between the apps, but this is neither clean nor ideal, because there's a chance the device was connected to someone else's app, and so I'd have no insight into the advertisement data in that scenario, and would need to resort to a scan.
Unfortunately, the advertisement data is available only if you scan. It is not possible to retrieve it from Core Bluetooth or any other framework in any other way. You should revise your design if the advertisement is so important and rather go along the scanning route.
Related
I'm making an iOS app that uses Core Bluetooth and periodically checks to see if the peripherals are still around. My problem is that when I shut off the advertising device (even shut off the bluetooth entirely), my central device still returns the CBPeripheral object when I call retrievePeripheralsWithIdentifiers. I need it to accurately NOT return this the peripheral once it is no longer advertising. Thanks in advance!
retrievePeripheralsWithIdentifiers looks into the Core Bluetooth database to see if it can find an peripheral with the specified identifier, regardless of whether advertisements from that peripheral are currently visible. This allows you to issue a connect to a peripheral that has been seen before and may be seen again (The "lock" scenario described in the Core Bluetooth Programming Guide is one example where you could use this).
To see if a peripheral is advertising or not you need to call scanForPeripheralsWithServices, specifying YES for CBCentralManagerScanOptionAllowDuplicatesKey and keep your own table of visible peripherals, ageing them out when you haven't seen an advertisement for some period.
I have a fitness app that is already in the app store and now I want to implement a bluetooth device that users can purchase if they wish. This is my first time dealing with bluetooth and after reading "Core Bluetooth Programming Guide", I have the following questions.
My app contains information that my bluetooth device requires simply to display the data. If I'm not mistaken, this makes the app the "Peripheral" because it has the data. The bluetooth device wants the data from the app so that makes the bluetooth device the "Central". Am I correct about this?
Finally, here is where I get confused. The bluetooth device has a button that I want when pressed to trigger the app to get the app to send new values to the bluetooth device. Is this possible? The reason I ask because in this scenario, would this now mean that the bluetooth device is the peripheral and the app is the central? If yes, will I have to break the current connection between the two in order to switch their roles (manager, and peripheral)?
Thank you in advance, really appreciate it!
Ted
As you have control over coding the app and coding the device, you can make it work either way around (Assuming the device is to be used specifically with your app and nothing else).
Both central and peripheral have methods to read and write data from/to the peripheral.
Without more information on the data and how often it's updated, it's difficult to suggest the best way to do it.
You say your device will have a button that will tell the app to send data over to it, well the app won't need to send anything it simply keeps values up to date then your button would tell your device to read the latest value.
Or (Again without knowing the purpose this may not suit) you do away with the button completely and your device subscribes to a characteristic in the app and is notified every time the value is changed by the app.
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'm looking for a way to be able to track another BTLE-enabled iOS device using mine, while within range. Basically, one device would have to log it's geolocation info, and then send it periodically to the other device, using BTLE.
How would I be able to do this? In general, I haven't been able to find much info on how to send and receive messages via BTLE, so any help in that category would be great. I've seen this answer already, but it didn't help me much, and I'm wondering if anything has changed since then.
If not possible through Apple's built-in framework, do you know of any external ones that would allow for this?
Long, long, long, longgg story short, but here ya go:
On one iOS device, adopt both the CBCentralManager and CBPeripheralManager. The CBCentralManager is responsible for connecting to external peripherals and maintaining that connection. The CBPeripheralManager will be what you'll use to read/write from the iOS device that your using a peripheral.
On the other iOS device, adopt just the CBPeripheralManager. You'll need add all the services and characteristics into the CBPeripheralManager that are stated in the GATT profile. Check out developer.bluetooth.org. These services and characteristics are necessary in order to connect from one device to the other.
In addition to just the gatt characteristics and services, you'll need to add in a custom service with a characteristic that you store your location data.
Check out the docs but for CBPeripheralManager in particularly you'll need to utilize
-(void) peripheralManager:(BLEPeripheralManager*)mgr requiresResponseToWriteRequests:(NSArray*)requests;
and
-(void) peripheralManager:(BLEPeripheralManager*)mgr requiresResponseToReadRequest:(CBATTRequest*)request;
in order to pass the location data between devices..Sorry for the brief overview, but there's just way too much to write up quickly.
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.