Using Bluetooth low energy in linux command line - linux

I am working on using the Bluetooth low energy modem with Linux. I am using the command line option for that i.e. hcitool . I am able to the find the devices using the command: $ hcitool scan
It is working fine for me, also I am able to broadcast my device using :
sudo hciconfig hci0 leadv
It is also working fine. But I want to add the services and characteristic to the modem device which can be detected by other device. I have tried sdptool add but it is not working for me. Does anyone know how to add the services and characteristics to the peripheral using the command line tools in ubuntu?
Edit: My modem is broadcasting but not able to explore the services and characteristic to the other BLE device. Now I am able to set the name of device using hcio name command
Edit: Now I am able to render the services and characteristic, by simultaneously running sudo hcidump command. But I am not able to track from where I am getting those services and characteristics. One definite observation is those services are rendering from the machine.

SDP is absent in BLE. Broadcast/advertise frame and GATT client/server are used instead.
Several links:
BlueZ gatttool: command line tool to run common GATT procedures
BlueZ GATT's ready profiles
hint: DBUS
GATT and DBUS example
How can I connect to the FitBit Zip over Bluetooth 4.0 LE on Linux with bluez?
Bluetooth Low Energy: listening for notifications/indications in linux
http://comments.gmane.org/gmane.linux.bluez.kernel/29547

I used to broadcast BT services by following this article. This page not only shouws you how to advertise a profile, but also gives you an example on how to implement the HSP profile.
To know the bt class you need to announce, you can check this other page.

Related

Bluetooth dongle BLED112 on Debian 10 is not working

I just randomly found a Bluegiga BLED112 Bluetooth dongle and I tried to connect it to my Debian 10 laptop as a basic dongle for Bluetooth audio outs.
Unfortunately I wasn't able to solve all the issues I had, starting from the fact that the device is not fully listed once used lsusb and just a mere ID number - namely ID 2458:0001 - pops out and bluetooth or bluez helps weren't successful either.
This given, I tried to follow several of the guides you can find online, also by running available scripts, but again nothing worked.
So if it's possible, what should I do in order to run such a dongle for the basic use I mentioned above - i.e. just for connecting my stereo speakers to my computer?
Thanks
The BlueGiga BLED112 is not a regular Bluetooth USB dongle. It gives you a virtual com port that can be used to access an API that in turn acts as a BLE device.
It is ment to be used for development of IOT solutions.
Also it does not support Bluetooth Classic, it only supports Bluetooth Low Energy.

Read battery status bluetooth headset linux

I use Bluetooth headset that use Bluetooth version 4.1. When I connect with android it shows the battery status. But with Linux (Ubuntu 18.04) I cannot get battery status. I tried with bluetoothctl, looking file in /sys/class/power_supply as in other questions, But they didn't help me.
askubuntu.com/questions/53880/is-there-any-way-to-check-the-battery-percentage-of-apple-wireless-peripherals
stackoverflow.com/questions/49078659/check-battery-level-of-connected-bluetooth-device-on-linux
My bluetooth device don't use GATT profile. It uses A2DP sink for streaming audio.
I looked Bluez documentation. They all said is do with GATT profile and get the attributes.
Is there a way to read battery status even with pragmatically in Linux properly? How does android device get the battery status? Is it a weakness of Linux Bluetooth stack?
Since this pull request by Dmitry Sharshakov, PipeWire has support for reporting battery status (with devices that use Apple HFP AT commands). It uses bluez's Battery Provider API, which is still experimental and is only available if bluetoothd is started with the -E flag.
On Arch Linux, it should be enough to run
cp /usr/lib/systemd/system/bluetooth.service /etc/systemd/system/
sed -i -r 's/ExecStart=.+/& -E/' /etc/systemd/system/bluetooth.service
systemctl daemon-reload
systemctl restart bluetooth
And the headset battery level should appear. To get the battery level programatically, you can then use UPower's DBus API.

No GATT characteristics discovered for dual-mode Bluetooth (Smart Ready) device

I'm running some of the Python example code from Bluez using the DBUS interface. I am on Fedora 28, Bluez 5.50. The device I am trying to connect to is a dual-mode Microchip BM78. Both the sample code and bluetoothctl will discover the device, show both the LE and BDEDR services, but neither detect the the GATT characterstics once services are resolved. The GATT characteristics are not resolved, even after the device is paired, trusted and/or connected.
The Bluez DBUS API seems to require that the characterists are first discovered before any attempt to read or write is possible.
I can connect to the device using non-DBUS APIs and access the characteristics just fine.
Is there some way to force characteristic discovery once a service is resolved? Or some way to connect to a known characteristic that has not be discovered using the DBUS interface?

beaglebone black wireless bluetooth AVRCP

I am working on a project with the beagle bone black wireless, where I need to be able to send music control commands to a phone. Note, I don't want to stream music to my beaglebone. I have spent about a week looking online, and found very little about this.
The OS for the beaglebone is Debian Jessie. I can get things like hci0tool, Bluetoothctl, hciconfig to work. I can detect and pair to a device. It seems though that my connection only lasts for the pairing process, and fails every time afterwards.
My current process is executing:
sudo su
bluetoothctl
power on
agent on
default-agent
scan on
I get the mac address
scan off
pair <MAC Address>
trust <MAC Address>
connect <MAC Address>
As of now pairing and trust succeed, though the connection ends after pairing finishes. And I have no idea of where to start for sending a command to a phone.
Connect call on Device1 interface will tries to connect all the profiles supported between the device and adapter. This happens by negotiating or exchanging the supported profiles.
Connection may not be possible when Adapter doesn't support the minimal requirement of profiles which is needed by the Device. In this case, you may need A2DP provider in adapter end to get connection successful. Yes, this is contradictory to this statement.
If you don't want to connect with all the profiles between Device and Adapter, then you can use ConnectProfile method in Device1 interface.
But bluetoothctl doesn't provide commands to achieve neither ConnectProfile nor you AVRCP commands.
You need to use D-Bus calls to get the communication with Bluetoothd. If your application is command line/shell based, you can use dbus-send/gdbus commands to address the D-Bus interface.
Although bluez-tools implements media control AVRCP commands, it doesn't provide any utility which uses it. Either you can compile bluez-tools as library and develop application using the media control API or use dbus-send/gdbus.
I have started with some samples using GDBUS, but not yet for AVRCP controls. See here : https://gist.github.com/parthitce
and Documentation here: https://www.linumiz.com/category/blog/

How to implement Bluetooth LE with Bluez in Linux

I'm working on setting up two Linux systems for a BLE demo. Obviously one system will be the peripheral and one will be the central devices. I have several questions surrounding both of these configurations.
Environment
2x Ubuntu 14.04 systems
2x Pluggable USB-BT4LE dongles (http://plugable.com/products/usb-bt4le)
Peripheral Device Setup
The first order of business is getting the peripheral system setup and advertising with a GATT server configured. At this time, it does not seem possible to configure a GATT server from the command line. So, while it is a simple task bringing a USB dongle up and advertising it, this does not allow the creation of custom services and characteristics. The only example of a GATT server I could find was the gatt-example.c file in the Bluez package. So I downloaded and built the latest bluez-5.23 source. (http://www.linuxfromscratch.org/blfs/view/svn/general/bluez.html). Additionally configured using the --enable-maintainer-mode flag to force build the gatt-example.c plugin into bluetoothd. And I validated post-build from the ~/bluez-5.23/plugins directory that there was a bluetoothd-gat-example.o file. Which tells me that the gatt-example was at least successfully built.
I then modified the configuration file to enable LE and the attribute server.
$ sudo vi /etc/bluetooth/main.conf
EnableLE = true // Enable Low Energy support. Default is false.
AttributeServer = true // Enable the GATT attribute server. Default is false.
Then simply reboot or restart the bluetooth daemon...
Central Device Setup
As the central device does not need any special plugins built like the peripheral, I just installed bluez using apt-get. This appears to have installed v4.101 according to bluetoothd -v.
Session Setup
The connection process then should be fairly simple. I setup the peripheral to advertise and then connect with the central device:
Peripheral:
$ sudo hciconfig hci0 up // Make sure the interface is up
$ sudo hciconfig hci0 leadv // Set the interface to advertise
Central:
$ sudo hcitool -i hci0 lescan // Scan for nearby devices advertising
LE Scan ...
00:02:72:C9:5E:0F (unknown) // Not sure why two of the same MAC are found?
00:02:72:C9:5E:0F (unknown) // but I know this is my device...
$ sudo gatttool -i hci0 -b 00:02:72:C9:5E:0F -m 48 --interactive // Connect interactively
[ ][00:02:72:C9:5E:0F][LE]> connect
[CON][00:02:72:C9:5E:0F][LE]> primary
attr handle: 0x0001, end grp handle: 0x0008 uuid: 00001800-0000-1000-8000-00805f9b34fb
attr handle: 0x0010, end grp handle: 0x0010 uuid: 00001801-0000-1000-8000-00805f9b34fb
[CON][00:02:72:C9:5E:0F][LE]> characteristics
handle: 0x0004, char properties: 0x02, char value handle: 0x0006, uuid: 00002a00-0000-1000-8000-00805f9b34fb
handle: 0x0007, char properties: 0x02, char value handle: 0x0008, uuid: 00002a01-0000-1000-8000-00805f9b34fb
And we see not one of the services or characteristics from the gatt-example are available.
Questions
--Peripheral Device
How would I go about creating my own custom GATT server? Can it be a stand-alone C application or does it need to be built into bluetoothd as a plugin like the gatt-example? The answer to this question (Creating a Gatt Server?) implies you do the following: "start by initializing the GATT library and additional modules" and then "register your GATT database". But there isn't a single example of how to implement those generic statements and the link provided is simply a URL to the Bluetooth website.
The GATT specifications (https://developer.bluetooth.org/gatt/Pages/default.aspx) provide numerous "adopted" services and characteristics that are downloadable in XML format. But there is no instructions for how to use them?!
How do a validate my GATT server is running?
--Central Device
Why is my central device not seeing the services and characteristics from the GATT server running on the peripheral?
I can provide any additional information necessary. Thanks.
To create a GATT server into a separate process you have (at least) two cases:
Bluez v4.x: your GATT service must be a Bluez plugin
Bluez v5.x: your GATT service should use the new GATT DBus API (but it is recommended to use at least Bluez v5.39 (from April 2016). Otherwise it is safer (in term of Bluez GATT Server API) to use the Bluez v4.x plugin approach.
If your Central Device does not see the newly exported GATT service is probably an issue on the periphal rather than to be an issue on the Central Device.
When you will need to implement the GATT client on the Central Device you still have two cases:
Bluez v4.x: Bluez does not expose the GATT API. Either you use a shell script to launch gatttool commands, or you use a GATT library such as gattlib to interact with the BLE device
Bluez v5.x: Same thing, if you cannot migrate to Bluez v5.39 then it is better to use Bluez v4.x methodology.

Resources