76

How can I check the battery level of a connected bluetooth device? The device shows the battery level on Android so I'm assuming the device supports the GATT-based Battery Service. However, by entering "menu gatt" in bluetoothctl and then listing the GATT attributes of the device with "list-attributes [dev]", nothing shows up.

A similar question was posted to SO but the OP seems to have found a solution that doesn't work for me. When I run "info [dev]" in bluetoothctl I don't see the UUID for Battery Service.

I would prefer a solution that runs on the command line and is distro-agnostic.

Please let me know if this question should be posted on SuperUser instead.

OlivierM
  • 2,092
  • 16
  • 33
Ricardo
  • 915
  • 1
  • 6
  • 11
  • What type of device are we talking about? Battery level can be reported via many different profiles over Bluetooth, not only via LE GATT service... can you use a BLE explore app or the like to browse the GATT services and confirm what it actually supports? – Markus Millfjord Mar 03 '18 at 08:40
  • Can you recommend a BLE explore app? Is there a way to know what type of device is connected from a command line tool (eg bluetoothctl)? – Ricardo Mar 04 '18 at 22:44
  • I check the contents of `/sys/class/power_supply`, as explained in [this other answer](https://askubuntu.com/questions/53880/is-there-any-way-to-check-the-battery-percentage-of-apple-wireless-peripherals). – Damian Nadales Sep 04 '18 at 11:20
  • 2
    @DamianNadales my `/sys/class/power_supply` only contains `AC` and `BAT0`. – Ricardo Sep 04 '18 at 23:01
  • Oh. Then I don't know :/ – Damian Nadales Sep 05 '18 at 05:48
  • @Ricardo when you say "nothing shows up with `list-attributes [dev]`". Do you mean there is not GATT attribute at all? If there are attributes, could you share them? – OlivierM May 27 '19 at 20:25
  • @OlivierM, yes, I mean no GATT attribute at all. – Ricardo May 27 '19 at 20:52
  • Can you tell which device it is? It might not support BLE but only legacy bluetooth... – OlivierM May 27 '19 at 21:01
  • @OlivierM, the device is the [Mpow 059 Bluetooth Headphones](https://www.xmpow.com/mpow-m3-over-ear-bluetooth-headphone.html) – Ricardo May 27 '19 at 21:26
  • I suspect your device does not use BLE for the connection (even if it supports it). Can you start `bluetoothd` in debug mode: `systemctl stop bluetooth.service && sudo ./src/bluetoothd -d -n` – OlivierM May 27 '19 at 21:37
  • @OlivierM, what should I look for? A few of the first and last output lines can be seen [here](https://gist.github.com/rhz/47ae7e325e2fad8fac5af6cd6ea7b6ac). – Ricardo May 27 '19 at 21:55
  • It looks your bluetooth device is only exposed through A2DP (Advanced Audio Distribution Profile). The battery information might be available through this Bluetooth profile. – OlivierM May 28 '19 at 20:55
  • 3
    How does one access the A2DP bluetooth profile? How do I check whether the battery information is available through that profile? – Ricardo May 28 '19 at 22:21
  • @Ricardo Looking at this page https://github.com/wangrunz/BluetoothMonitor#battery-level-for-bluetooth-headsets-support-handsfree-profile it looks like you need to send some AT commands. While it could be feasible in command line using my command https://stackoverflow.com/a/55008142/6267288 - it might be more convenient to do it using a programming language. – OlivierM May 29 '19 at 12:21
  • Thanks @OlivierM! I understand vaguely what has to be done. Concretely I don't know what to do. It seems the author of that app is having issues as well. I hope someone will write an answer to the question with concrete commands to run to obtain the battery level of a bluetooth device like mine. – Ricardo May 30 '19 at 16:15
  • Hey @OlivierM, do you know how you could use `dbus-send` to send those AT commands to the device? – Ricardo Oct 04 '19 at 23:27
  • @Ricardo for BLE device, I am not sure you can do it using `dbus`. – OlivierM Oct 05 '19 at 10:52
  • Why would that be so @OlivierM? Are BLE devices not exposed through the dbus interface? – Ricardo Oct 05 '19 at 20:25
  • It is the GATT layer that is exposed through `dbus`. Not the ATT layer. – OlivierM Oct 05 '19 at 22:06
  • Ok, I understand. Thanks for the clarification @OlivierM. What did you have in mind in your [previous comment](https://stackoverflow.com/questions/49078659/check-battery-level-of-connected-bluetooth-device-on-linux?noredirect=1#comment99324302_49078659) when you said that it could be feasible to send some AT commands using your command in stackoverflow.com/a/55008142/6267288? – Ricardo Oct 05 '19 at 23:43

9 Answers9

22

This might be a bit late to the party but for me this Python project has worked fine:

https://github.com/TheWeirdDev/Bluetooth_Headset_Battery_Level

I only had to change the port in line 57 to 3 for my no-name X5 headset. If it hangs or errors with "connection refused" try a different port.

The Python program uses AT commands via RFCOMM and should work while Pulseaudio is using the A2DP sink (mine reconnects). Python 3 is needed as 2 doesn't have BT-Serial sockets. Windows will probably not work as it lacks bluez. It basically does the same thing as the Pulseaudio hack here: https://stackoverflow.com/a/56390625/920122

If you want to look at the commands as they are exchanged, try my debug fork: https://github.com/clst/Bluetooth_Headset_Battery_Level

clst
  • 336
  • 3
  • 8
  • 1
    Hey @clst, thanks for the answer! It looks promising! You mean the port in line 56 of the original code and 58 in your fork? The one that says `s.connect((BT_ADDRESS, 3))`? I tried with all the numbers from 1 to 11 and didn't work. Should I continue trying with more port numbers? Do you know what's the range of numbers in which the port may lie? – Ricardo Jan 30 '20 at 02:27
  • 2
    I tried again, this time after disconnecting from the device with `bluetoothctl`. **It works!!** `:)` I'm using your fork and port number 3. The only caveat is that I can't use this while listening to music, as I have to disconnect from the device to use the python script. – Ricardo Jan 30 '20 at 02:36
  • 1
    Yeah, those port numbers are device specific and there is no common practice so you would have to try them. If the RFCOMM works while the device is doing other things (like A2DP) is also device specific. Until someone codes a robust auto detect system this is the best we have `:)` – clst Jan 31 '20 at 13:12
  • 1
    Thanks! Donated you a couple of dollars in Bitcoin Cash :) – Lubo Kanev Apr 09 '20 at 08:17
  • I'm sure the original author will appreciate it :) You can try contacting them via github. I am not sure TheWeirdDev knows about this SO question... – clst Apr 11 '20 at 12:21
  • @clst do you know if this approach can be used to get battery level of apple watch and apple pencil over bluetooth as well? – Jack Chen May 08 '20 at 20:45
  • I have no idea. Since this is an Apple proprietary protocol it might. I have no Apple hardware so I can't be much help. – clst May 16 '20 at 00:32
20

This is such a great question, ahead of development and tools that are available at the moment.

The short answer (in October 2018)

you have to write it yourself! It won't be a one liner in the terminal. I am going to write this for myself in Python, but C has a little more documentation, so if you are skilled with C go for it.

The long answer, but it's more a recommended starting point:

  1. Tony D: https://youtu.be/5fQR2PHMDWE?t=4644 managed to use bluetoothctl to read attributes and send data to a bluetooth device. Definitely check the video information, you will find great links and references: https://learn.adafruit.com/introduction-to-bluetooth-low-energy/gatt
  2. Szymon Janc: https://youtu.be/VMDyebKT5c4 developer and contributer to the LINUX Bluetooth Stack

  3. Definitely check out how this question is answered on Mobile devices. For Android it's the BAS (Battery Service): https://android.stackexchange.com/questions/106073/displaying-bluetooth-gadgets-battery-status-on-the-phone

    On Android 8.0.1

VeRo
  • 790
  • 8
  • 24
  • I checked the first video and the guy uses `list-attributes` in `bluetoothctl`, which doesn't show anything in my case. That's why I'm thinking maybe there's a non-GATT way to check the battery status? I checked the other links too, except the talk by Szymon Janc which is a bit too long. Please let me know if you're successful in writing a program that reads the battery level of a BLE device. – Ricardo Oct 23 '18 at 03:06
  • Don't forget to use `sudo` when running `bluetoothctl`. But yeah, there really isn't a comfortable way to do this in Linux, today. That is also the motivation for this python project: https://github.com/peplin/pygatt#motivation I am not going to go further with my research, of this subject due to lack of time. Use the above git project and example code, if you decide to continue this Path of solving this issue. https://github.com/peplin/pygatt#example-use I will probably only be able to help again, next year. Good luck! – VeRo Oct 28 '18 at 16:16
  • Thanks @VeRo for the help! I didn't know I was supposed to run `bluetoothctl` as root (using `sudo`). I tried that and still nothing shows up when I do `list-attributes` after connecting to the device. Not sure what should be done to get the attribute listed there or what can be done if the device doesn't list any gatt attributes. Cheers! – Ricardo Oct 31 '18 at 02:25
  • 2
    Update by (Kernel Developer) `something has to register the battery with the power-supply subsystem using power_supply_register (or the variant prefixed with devm_). For the BT HID devices that happens in drivers/hid/hid-input.c and is based on the HID protocol. Other BT devices do not use HID protocol and need their own handler. AFAIK for other device types the highlevel protocols are implemented in userspace/bluez. That would require something like uinput for power-supply, so that bluez can feed battery information back into the kernel. AFAIK nobody is currently working on that.` – VeRo Feb 03 '20 at 17:08
19

You don't see Battery Level in the list of GATT characteristics since Bluez v5.48 because this specific GATT characteristic was moved into DBUS org.bluez.Battery1 interface.

From the command line:

  1. Connect to your target BLE device with bluetoothctl
  2. And then request DBUS by running: dbus-send --print-reply=literal --system --dest=org.bluez /org/bluez/hci0/dev_<mac_address_of_your_ble_peripheral> org.freedesktop.DBus.Properties.Get string:"org.bluez.Battery1" string:"Percentage"

In my case with my BLE peripheral with the following MAC address C3:41:A6:C8:93:42:

$ dbus-send --print-reply=literal --system --dest=org.bluez \
    /org/bluez/hci0/dev_C3_41_A6_C8_93_42 org.freedesktop.DBus.Properties.Get \
    string:"org.bluez.Battery1" string:"Percentage"
   variant       byte 94

Note: You could potentially scan and connect to your device using Bluez DBUS API.

Martin Tournoij
  • 23,567
  • 24
  • 90
  • 127
OlivierM
  • 2,092
  • 16
  • 33
  • 14
    When following these instructions, I get this error `$ dbus-send --print-reply=literal --system --dest=org.bluez /org/bluez/hci0/dev_E9_09_EF_A6_24_70 org.freedesktop.DBus.Properties.Get string:"org.bluez.Battery1" string:"Percentage" Error org.freedesktop.DBus.Error.InvalidArgs: No such interface 'org.bluez.Battery1'` – Ricardo Mar 11 '19 at 21:06
  • Which 'bluez' version are you using? – OlivierM Mar 13 '19 at 07:41
  • @OlivierM, I'm using bluez 5.50 on archlinux – Ricardo Apr 15 '19 at 01:23
  • 2
    I have just tried 5.50 from the Bluez sources and it also work for me. Are you sure your device expose battery service? Can you run this command: `dbus-send --system --print-reply --dest=org.bluez /org/bluez/hci0/dev_E9_09_EF_A6_24_70 org.freedesktop.DBus.Introspectable.Introspect` – OlivierM Apr 15 '19 at 07:16
  • Hi @OlivierM, I'm sorry I missed your last comment. I tried that command and gave me a long output that's kind of hard to parse. You can see it at https://gist.github.com/rhz/b904398b1526db1c2fe208a61d09e24d. There's no mention of a Battery property for the device. What does that mean? – Ricardo May 27 '19 at 18:59
  • 1
    Hi, I'm having the same problem as @Ricardo, I'm using bluez 5.50-6 on Archlinux and I also don't have the `org.bluez.Battery1` interface; my introspect output is https://gist.github.com/Terseus/d78e6ca711cef914e52bffd757d40c5b – Terseus May 29 '19 at 07:33
  • 1
    @Terseus, same as Ricardo. Your device use A2DP (Advanced Audio Distribution Profile), your batterz information might be accessible through this profile. See my comment: https://stackoverflow.com/questions/49078659/check-battery-level-of-connected-bluetooth-device-on-linux?noredirect=1#comment99304776_49078659 – OlivierM May 29 '19 at 12:17
  • @OlivierM Can please also give the dbus command for `bluez < 5.48` ? – SebMa Feb 01 '20 at 13:46
14

For me running this in terminal worked- upower --dump

Yash Nahta
  • 157
  • 1
  • 6
  • 11
    Thanks Yash for your suggestion. Unfortunately this doesn't work for my setup. Only the laptop's battery `battery_BAT0`, the line power `line_power_AC`, and the mysterious `/org/freedesktop/UPower/devices/DisplayDevice` device show up in the output. – Ricardo Oct 04 '19 at 23:19
  • 1
    Worked perfectly for me! – Luca T Oct 20 '20 at 10:23
3

Here is a way to get battery level via pulseaudio logs with some hack. My bluetooth headset uses proprietary Apple HFP AT commands, HFP/A2DP protocols are handled by pulseaudio directly. It seems the only way to get those values is through pulse.

Vasily Olekhov
  • 81
  • 3
  • Thanks Vasily and sorry for the long delay. Do you know if there is a way to send those AT commands from the command line (using `dbus-send` for instance) to obtain the battery level? – Ricardo Oct 04 '19 at 23:25
  • You can build pulseaudio yourself and apply mentioned patch. You can modify it: for example, replace pa_log_notice with output to some pipe in /tmp and have app that monitors that pipe. I chose this way. Works for me. That code is triggered only once, when device is paired. You can place it on volume change functions. I think there is a way to add dbus listener to specific command in pulseaudio, so that it will trigger PA to send those AT commands, but this is too compilcated for me. – Vasily Olekhov Oct 07 '19 at 04:38
  • I see. Thanks. I would rather not maintain a fork of pulseaudio. – Ricardo Oct 07 '19 at 18:04
3

By default Bluez 'hides' the Battery Service UUID. This is because there is a 'battery plugin' loaded at startup of bluetoothd.

If you don't want the battery plugin to be activated and make the Battery Service UUID visible again to bluetoothctl or any other application, then change the startup command for bluetoothd to be like this: 'bluetoothd -P battery'. That will make sure the battery plugin is not loaded. On a Raspberry Pi the bluetooth.service is located in /lib/systemd/system/bluetooth.service so you need to make the change in that file.

Martijn van Welie
  • 391
  • 1
  • 6
  • Please do not modify packaged unit files (those under `/lib` or `/usr/lib`) directly. Systemd offers the `systemctl edit` interface for modifying units in a way that does not cause issues with package managers. – FallenWarrior May 30 '21 at 05:42
1

(This answer is specific to headphones/headsets)

I'd been using the Python program from clst's answer for some time and although it worked, it required me to connect, then disconnect and run it again. If I understand the problem correctly, that happens because only one program can open a socket to talk to the bluetooth device, so it ends up fighting with PulseAudio over it.

I've recently found out about hsphfpd.

hsphfpd is specification with some prototype implementation used for connecting Bluetooth devices with HSP and HFP profiles on Linux operating system.

Basically, since only one program can communicate with the headset at once and it wouldn't make sense to implement battery level reporting in an audio server, nor implement audio in a power management software, it moves that functionality to an external daemon. That way, PulseAudio and whatever can both use the headset at the same time. There is a version of PulseAudio patched to use hsphfpd. Even though these are both still prototypes, they seem to work very well.

hsphfpd reports battery status (and other stuff) through DBus, so to get it from the command line, you can just do

dbus-send --system --dest=org.hsphfpd --print-reply /org/hsphfpd/hci0/dev_XX_XX_XX_XX_XX_XX/hsp_hs org.freedesktop.DBus.Properties.Get string:org.hsphfpd.Endpoint string:BatteryLevel

or even call it from a program.

Both of these are available in the AUR, if you use Arch Linux.

LHLaurini
  • 822
  • 10
  • 24
  • When running `dbus-send --system --dest=org.hsphfpd --print-reply /org/hsphfpd/hci0/dev_XX_XX_XX_XX_XX_XX/hsp_hs org.freedesktop.DBus.Properties.Get string:org.hsphfpd.Endpoint string:BatteryLevel` I get `method return time=1606703580.141858 sender=:1.3546 -> destination=:1.3550 serial=44 reply_serial=2 variant int16 -1` – Ricardo Nov 30 '20 at 02:34
  • @Ricardo You could try `hfp_hf` or `hfp_ag` instead of `hsp_hs`. If that doesn't work, open `pavucontrol` and switch to either HFP or HSP (even if they say unavailable), then try again. After this, you can switch back to whatever profile you were using, or else you'll be stuck with very low quality audio. If that still doesn't work, try using `QDBusViewer` to inspect the `org.hsphfpd` service and find any alternate paths you may be able to use. Let me know if you manage to make it work. – LHLaurini Nov 30 '20 at 13:37
  • When I use `hfp_hf` I get `variant int16 40`. I guess that 40 means 40% battery left. Not sure how to verify that as the new setup makes the program in the accepted answer not able to connect to the device. Maybe I'll just wait and see if the number goes down with use. Thanks for the help! When using `qdbus --system org.hsphfpd` I see that both `hfp_hf` and `hsp_hs` are available for this device. – Ricardo Dec 01 '20 at 17:24
  • @Ricardo That's correct. As far as I know, hsphfpd uses a similar method from the script from the accepted answer, so the value should be the same. Also, you could also connect to the `PropertiesChanged` signal to be notified when the battery level changes. Note that it only updates if the `Connected` property is `true`. – LHLaurini Dec 01 '20 at 17:36
  • Cool. By charging the headphones the number increased to 60. I think it might only be sensitive to 10% increases and decreases. Thanks a lot! This answer is very useful. – Ricardo Jan 11 '21 at 02:03
0

In the bluez version you are using the Gatt attributes may be experimental.If so you need to enable the experimental characteristics by running the bluetoothd deamon by -E keyword Like "/usr/libexec/bluetooth/bluetoothd -E" this worked for me.

Jayanth Rajan
  • 9
  • 3
  • The bluetoothd deamon is run by systemd when you do "systemctl start bluetooth" right? How can I tell systemd to use the -E parameter? I have bluez version 5.48 – Ricardo Mar 08 '18 at 19:56
  • While executing the 'systemctl start bluetooth' command you are invoking the bluetooth.service ,search for this service in you home directory.Inside the service you can add the -E parameter to the line invoking the bluetoothd.It comes as part of the bluez package.The line would look something like this "ExecStart=/usr/libexec/bluetooth/bluetoothd" add -E parameter to the end of it "ExecStart=/usr/libexec/bluetooth/bluetoothd -E". – Jayanth Rajan Mar 15 '18 at 05:00
  • After adding this keyword when you connect your device using bluetoothctl app it will list the supported services by your bluetooth device.from that you can select-attribute for the "Battery-Level" service and use read command to get the value.There are also ways to get the battery level directly by usinf dbus-send a utilit used to send dbus commands. – Jayanth Rajan Mar 15 '18 at 05:05
  • Thank you very much for your help. I changed the line as you suggested, then did "systemctl deamon-reload" then "systemctl restart bluetooth" (both as root). Then started bluetoothctl, connected the device, "menu gatt", "list-attributes [dev]"... but still nothing. Any ideas what might be going on? – Ricardo Mar 20 '18 at 22:42
  • To which device are you trying to connect – Jayanth Rajan Mar 21 '18 at 08:06
  • I'm connecting to some headphones. Seems like gatttool has been deprecated in bluez: https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=b1eb2c4cd057624312e0412f6c4be000f7fc3617. According to https://wiki.archlinux.org/index.php/bluetooth#Troubleshooting, gatttool has been replaced by btgatt-client. However, I wasn't able to make it work. I tried "btgatt-client -v -d [device address taken from bluetoothctl]" and got "Connecting to device... Failed to connect: Operation not supported". – Ricardo Mar 24 '18 at 06:06
  • If possible could you post the code inside your bluetooth.service.Which bluez versio are you using. – Jayanth Rajan Mar 28 '18 at 07:04
  • And also could you post the info of your device from the bluetoothctl app. – Jayanth Rajan Mar 28 '18 at 07:27
  • Its May be because your speaker don't advertise the battery level through the Gatt services.you can try following command through dbus-send "dbus-send --system --dest=org.bluez --print-reply /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/ org.freedesktop.DBus.Properties.Get string:org.bluez.Battery1 string:Percentage" – Jayanth Rajan Mar 28 '18 at 08:23
  • try like this "dbus-send --system --dest=org.bluez --print-reply /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX org.freedesktop.DBus.Properties.Get string:org.bluez.Battery1 string:Percentage" there was an extra backslash in the earlier comment – Jayanth Rajan Mar 28 '18 at 08:32
  • `dbus-send --system --dest=org.bluez --print-reply /org/bluez/hci0/dev_E9_09_EF_A6_24_70 org.freedesktop.DBus.Properties.Get string:org.bluez.Battery1 string:Percentage` gives me `Error org.freedesktop.DBus.Error.InvalidArgs: No such interface 'org.bluez.Battery1'` – Ricardo Mar 29 '18 at 19:46
  • bluetooth.service: `[Unit] Description=Bluetooth service Documentation=man:bluetoothd(8) ConditionPathIsDirectory=/sys/class/bluetooth [Service] Type=dbus BusName=org.bluez ExecStart=/usr/lib/bluetooth/bluetoothd -E NotifyAccess=main #WatchdogSec=10 #Restart=on-failure CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE LimitNPROC=1 ProtectHome=true ProtectSystem=full [Install] WantedBy=bluetooth.target Alias=dbus-org.bluez.service` – Ricardo Mar 29 '18 at 19:47
  • in bluetoothctl I do `info E9:09:EF:A6:24:70` and I get `Device E9:09:EF:A6:24:70 (public) Name: MPOW-059 Alias: MPOW-059 Class: 0x00240404 Icon: audio-card Paired: yes Trusted: yes Blocked: no Connected: yes LegacyPairing: no` ... – Ricardo Mar 29 '18 at 19:49
  • ... `UUID: Headset (00001108-0000-1000-8000-00805f9b34fb) UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb) UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb) UUID: Advanced Audio Distribu.. (0000110d-0000-1000-8000-00805f9b34fb) UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb) UUID: Handsfree (0000111e-0000-1000-8000-00805f9b34fb)` – Ricardo Mar 29 '18 at 19:50
  • I have bluez version 5.48 – Ricardo Mar 29 '18 at 19:52
  • I am not able to find BatteryService in your UUID info,it may be advertising the battery level in some other way.What i understood is that Gatt characteristics are mainly vendor specific.Is the app you are using to fetch the battery level of your device provided by the manufacture of the headphone or is it a generic one?Could you please provide the Manufacture data or more details about your headphone? – Jayanth Rajan Apr 06 '18 at 09:20
  • The app I'm using to fetch the battery level on my android phone? It's just android itself that tells me the battery level of the bluetooth device on the notification bar. Where can I find more information about the headphones? What I pasted here is all I get from bluetoothctl. Is there any other tool on linux to get information from bluetooth devices? – Ricardo Apr 08 '18 at 21:21
  • I am not able to see the UUID for the battery service in the list of UUIDs you have given here are you sure that your device is advertising the battery level through gatt characteristics even in androif app its internally using ths genric UUID to fetch the battery level which is not present in your advertised UUIDs by your speaker – Jayanth Rajan May 10 '18 at 06:59
  • I'm not sure. How can I be sure? – Ricardo May 12 '18 at 00:01
  • Search for the device mac in your '/' mostprobably it will be inside /var directory and inside the device directory there is an attributes file in that you can check for the UUIDs supported by your device.Check if has the GATT UUID for battery service. – Jayanth Rajan Jun 08 '18 at 04:44
  • 1
    `sudo ls /var/lib/bluetooth/40:xx:xx:xx:xx:xx/E9:xx:xx:xx:xx:xx/` shows there's only the file `info` in it but no file `attributes`. – Ricardo Jun 11 '18 at 01:50
  • could you try these steps,connect to the device(after pairing),tyoe info in bluetoothctl,copy the list of UUIDs you are getting and paste it here.or use the command list-attributes and paste the output here.X180F this is the uuid for battery service please do check whether you can find anything like this in your list of attributes. – Jayanth Rajan Aug 31 '18 at 11:57
  • The command `list-attributes` returns nothing. The command `info E9:09:EF:A6:24:70` gives me the following list of UUIDs: `00001108-0000-1000-8000-00805f9b34fb`, `0000110b-0000-1000-8000-00805f9b34fb`, `0000110c-0000-1000-8000-00805f9b34fb`, `0000110d-0000-1000-8000-00805f9b34fb`, `0000110e-0000-1000-8000-00805f9b34fb`, and `0000111e-0000-1000-8000-00805f9b34fb`. None of them have the substring `X180F`. I can't find anything like that in either the list of attributes or the list of UUIDs in `info`. – Ricardo Sep 04 '18 at 23:22
-4

As said by @OlivierM above, the UUID is filtered by bluetoothd. You could undo that and export the UUID just as any other service characteristics by removing the following from the export_service() function in src/gatt-client.c

if (gatt_db_service_get_claimed(attr))
     return;
br1
  • 367
  • 2
  • 9