I was wondering if there's any way that I can control BLE device pairing specific to my app running on mobile device?
I do not want to write my own bluetooth profile so that only my app can talk to the BLE device instead i want to standard profiles available in BLE device but when it's paired to my phone, only my app should be able to communicate to it and none of the other apps should be able to communicate.
No don't do that.
If you MUST then you should encrypt your data with a key only your app knows.
Bluetooth Low Energy is supposed to be open and free for all.
What is the purpose for you to block others? Preventing them to block your service?
Then use some pre-shared key to verify that it's your app in both sides and close the connection if it's not.
Related
When connection to a custom BLE device from an app (android and ios) I have two options
a) first pair the device on the phone (like a headset or other devices) and then use it from the app to read and write data
b) without pairing on the phone, go inside the app, search for a device with a specific name or address, and just connect to it and read and write data.
when is one preferred over the other one ?
Its just when it needs to interact in the background or am I missing something?
The devices you see in your phones Bluetooth settings are Bluetooth Classic devices. There are some devices using both BLE and Bluetooth Classic which show up in the settings too, but the settings page is only for the Bluetooth Classic part of the device. Headphones for example are streaming music trough the Bluetooth Classic profile A2DP but might offer BLE services for additional features.
You always have to use a special app to communicate with the BLE part of a device. This could be an app provided by a manufacturer or a generic BLE scanner app such as nRF Connect.
As alexander.cpp already told you in his answer pairing (the exchange of keys) and bonding (saving of said keys) is not required for the communication with BLE devices and only needed if the device requires a secured connection.
Bonding (technically correct term for BLE, often called Pairing in non-technical speech) is mostly for security, we can send sensitive information because the receiver is verified and data is transferred in encrypted form.
Prefer to use bonding if the data is sensitive (means users feel uncomfortable if somebody they don't know receive their data). For example, I consider "current temperature = 25" as NOT sensitive. For detailed explanation, find "Bonding with a BLE device" in BLE guide by PunchThrough.
Also this is a good answer to a similar question: https://stackoverflow.com/a/42916081/10380092.
Your second question about background - no, bonding is not related to interaction in background.
I'm trying to establish a connection between my PC running Ubuntu and my iPhone via Bluetooth automatically when it becomes available, after being manually paired beforehand. I've seen this to be possible with certain peripherals, mainly audio. For example, my phone will automatically connect to a Bluetooth speaker when it is turned on and Bluetooth is active on my phone; another example is my phone automatically connects to my car's radio system via Bluetooth when I turn the car on.
I'm not able to connect my phone to my PC without first initiating the connection from the smartphone's Bluetooth menu. I'm thinking that I could possibly write an application for the PC to attempt to connect to the device every few minutes or something, but it seems that the phone needs to be the device to initiate the connection.
The only information that I need for what I'm trying to do ultimately is that the devices can pair successfully. Essentially I'm trying to build a sort of proximity trigger between my phone and my PC without using Wi-Fi and GPS - I can't use these for some specific reasons.
Is there any way to make this happen?
Yes this should be doable as long as you use the Background Processing feature for iOS apps. In the example I'll give below, we'll have the PC be the peripheral and the phone be the central, but you can really have it working either way. You will need to do the following:-
First initial connection needs to be performed in the foreground (this is due to iOS's background limitations).
On the iOS side, you need an application that acts as a central that scans and connects to the remove device (check this example as a starting point).
Upon connection, you need to bond with the PC. Bonding is important as it will prevent you from having to do the pairing again in the future. However, pairing/bonding is managed by the iPhone's OS so you cannot write it in your application, so the workaround is to have an encrypted characteristic on the PC side that will force the iPhone to bond (this is covered later).
On the PC side, you need to have a BlueZ script that acts as a peripheral that is always advertising. You can do this using bluetoothctl (check the examples here and here).
Before you start advertising, you need to have a GATT server on the PC side (to do this, check this example).
When registering characteristics, ensure that one of them has the encrypt-read property (you can find a full list of the properties here).
Now when you attempt to read this characteristic from the iOS side, the two devices should bond (make sure that your PC is bondable which you can do this via these commands).
Once the devices are paired, your iOS app needs to be working in the background constantly scanning and attempting to connect to the same peripheral (have a look at this and this example).
You can find more useful information at the links below:-
Getting started with Bluetooth Low Energy
The Ultimate Guide to CoreBluetooth Development
How to manage Bluetooth devices on Linux using bluetoothctl
I am building an Android app in which I need to connect to an custom device over classic Bluetooth (preferably). My problem is SDK for that device is not created to facilitate the connection. Now I am stuck onto the part where I need to create a Socket which will be opened by the custom device which is acting as a server and other Android devices will act as clients and connect to it.
I am stuck at the part where we need to have identical UUIDs at both client and server for the socket connection to work. I am following the BleutoothChatApp as reference for this but I cannot always make sure that both my app and custom device will have identical UUIDs. Because I may or may not be able to hard code the UUID in custom device.
What can I do in such case.?
Also when I try to use BLE and search for services, I discover only one service which has no description or anything.
What can I do in such cases. What will be the best approach to create a connection to that device.?
You get multiple UUIDs for the same device because the devices offer multiple services. Base UUID for Bluetooth is "00000000-0000-1000-8000-00805F9B34FB".
If you find this UUID in a device, it means it supports Bluetooth Service. Use the UUID for connecting to the device.
I'm not a ble guru, I worked on some modules to expose some simple service with pairing and bla bla :9
One of our customer ask me if it possible to control mcu gpio, with a beacon service running. For what I know beacon standard is only a lighthouse to check the proximity (streaming simple packet uuid, signal strength etc etc), and the only way to do something like this is to expose a new service running concurrently with beacon ( in practice send multi type of packets). I don't want pairing (beacon<->device app) and don't worry about race condition, if multi devices set/reset a gpio, it's not my business.
I found something similar https://community.estimote.com/hc/en-us/articles/217429867-What-is-GPIO-How-to-set-it-up-, what you think about?
There are libraries or eddystone's extensions to do that? Some project on github?
We prefer to work with Nordic ble module, but if you know solution based on other mcu, you are welcome.
Thanks for your help
Standard beacons (iBeacon, Eddystone, AltBeacon) are transmit only devices. They simply send out advertisements at a fixed rate with a unique identifier. Some manufacturers expose proprietary configuration interfaces as read-write Bluetooth LE GATT Services. But there is no standard GATT Service that does this, and the manufacturer-specific schemes are designed specifically to set beacon identifiers and other operating parameters.
I don't think there are beacon-specific libraries or extensions that will help with this, beyond standard Bluetooth LE SDKs for iOS and Android. In order to accomplish this goal with a Nordic BLE module you would need to build your own custom system:
Write custom Nordic firmware (that sits alongside beacon transmission firmware) that exposes a new Bluetooth LE GATT Service. The service would expose a writable GATT Attribute that would control the GPIO pin.
Write custom mobile app code that connects to this GATT Service (CoreBluetooth on iOS and android.bluetooth on Android), and writes to the GATT attribute to control the pin.
One thing you must be careful of is that connecting to to a GATT Service will typically stop a Bluetooth Peripheral from advertising (meaning it won't transmit as a beacon). So you may wish to drop the connection quickly to prevent mobile devices or other Bluetooth Centrals from stoping the beacon transmissions.
For example, if I have a friend over and he wants to show me a video using a given app that runs both on my device and his device. Could that app display a QR code on the screen or something that he could scan and instantly be granted access to my Chromecast device?
As Ali mentioned, Chromecast devices are discovered and apps launched via local network applications. One an app is started, it could easily connect with a cloud service that allows other (non-local) devices to talk w/ your Chromecast via the cloud service. A Chromecast Receiver application is just a HTML5 application (HTML, CSS, and JavaScript). You can really do what ever you want once your application gets launched.
If displaying a QR code that allows some kind of rendezvous with your cloud application is what you want to do, you can certainly do that.
I presume your friend's mobile device is on the same wifi network, right? Currently, a chromecast device has no identity outside of its local wifi network, so if the sender is not on the same network as the receiver, there is no way they can exchange messages. Back to your question, if your friend is on your network, then he could see your device except from those applications for which your device is not whitelisted for. Is that the case you want to handle through, say, a QR code? If so, that is currently not doable either since whitelisting is not just a local setup. Maybe I misunderstood your question?
Based on your questions, you are saying that both you and your friend have the same app. If so, and if your friend connects to your wifi network, then he will see your chromecast (you do not whitelist a device for a phone, you whitelist a device for an app id and as long as your friend has the same app (hence the same app id I resume), your whitelisted device will be discoverable by his phone. On the other hand, if you do not want to give him credentials to get on your network, then you need a cloud backend and a lot of work, since although your chromecast device can send a message to cloud and your cloud service can notify the other user's phone (using, say notification or some other mechanism that you employ in your app), the reverse (i.e. sending a message from your friend's phone to your chromecast (through your cloud service)) is much harder. Your friend's phone can send your phone a message (again via a back end service, a bluetooth communication, NFC, etc and then your phone using your app can send that to the chromecast receiver but I am sure you are getting the idea that it is a lot of work. Signing up on your wifi network can be made easier with a QR code or something so at this pint, that would be the easiest solution.