Script needs to disconnect the device first

[Paralusion]

Great project, thanks for your work.

That being said, the script seems to have an issue that it requires you to disconnect from the Bluetooth device first, then connect through it by launching your using ./bluetooth_battery.py <MAC ID>. Is there a way to automate this process, so that it does not require you to manually disconnect first?

Thanks.

[TheWeirdDev]

I still haven't found a solution for this issue. This is a device specific problem. I don't know why some devices require you to disconnect before running the script. For me, both my headsets work while connected, and i had other users confirming that it works for them too.

[Paralusion]

Alright, I've browsed through some closed issues and I saw that I was not the only one having the issue. As I'm not the only one with the issue there could be made an option for people who do have the issue. This makes people with supported devices have the same old script, while people with devices that are unsupported can also use the script.
You probably can't do much with this, but I use the Skullcandy Crusher wireless.

Thank you.

[TheWeirdDev]

I would like to make that option. The only problem is i don't know how to fix this issue or even know if it's fixable.
I keep this issue open hoping that someone will find a workaround or some Bluetooth expert will explain what is causing the problem.

[Paralusion]

My suggestion on this is to perform a command using bluez to disconnect the device first using the MAC address, then connecting to the Bluetooth again with the same MAC address, but this time with the script. I can look into it later & possibly create something. If I end up successfully creating something, I'll open a pull request.

[mishurov]

@TheWeirdDev probably it is because the RFCOMM HFP socket is already in use by Pipewire or something like that. Also Pipewire has implemented this AT sequence feature https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/504

I've managed to retrieve the battery status with bluez >= 5.56 with 'experimental' enabled without disconnecting the headset. Using dbus

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"

And obviously it can be scripted using a dbus python binding.

[protist]

I have this issue as well (Arch Linux, Soundpeats A6).

@mishurov I tried your command, but it didn't work for me. I'm using bluez 5.62 and activated the experimental mode, but I got the following error.

$ dbus-send --print-reply=literal --system --dest=org.bluez /org/bluez/hci0/dev_E8:AB:FA:51:D9:C9 org.freedesktop.DBus.Properties.Get string:"org.bluez.Battery1" string:"Percentage"
dbus[342079]: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1366.
This is normally a bug in some application using the D-Bus library.

dbus-send: Ran out of memory

[mishurov]

@protist RFCOMM HFP socket is in use by Pulseaudio or Pipewire. When this script tries to connect to the HFP socket, it fails. That is why it needs disconnection. Fairly recent Pipewire versions publish the battery status to dbus themselves, no need in this script. I use Debian Bullseye, manually compiled Pipewire and manually installed BlueZ 5.60. Xfce power manager just shows status or I can retrieve it using dbus commands.

[protist]

Thanks @mishurov. FWIW I'm using the current Pipewire 0.3.38.

I tried messing around with the dbus command, and I've gotten halfway there. Apparently the MAC address should have _ instead of :, but this fails for other reasons.

$ dbus-send --print-reply=literal --system --dest=org.bluez /org/bluez/hci0/dev_E8_AB_FA_51_D9_C9 org.freedesktop.DBus.Properties.Get string:"org.bluez.Battery1" string:"Percentage"
Error org.freedesktop.DBus.Error.InvalidArgs: No such interface 'org.bluez.Battery1'

I really don't know what I'm doing, but from GetAll, I'm not sure if the battery is available or not.

$ dbus-send --print-reply=literal --system --dest=org.bluez /org/bluez/hci0/dev_E8_AB_FA_51_D9_C9 org.freedesktop.DBus.Properties.GetAll string:"org.freedesktop.DBus.Properties"
   array [
   ]

[mishurov]

@protist I pipe it to less and search the service where Battery1 exists with usual vim shortcuts for searching

dbus-send --system --print-reply --dest=org.bluez / org.freedesktop.DBus.ObjectManager.GetManagedObjects | less

[protist]

Thanks again @mishurov. It looks like Battery1 (or anything similar) doesn't exist for me in the output of that command. Perhaps it's specific to my headphones.

EDIT (19 Nov): FWIW I bought a new pair of bluetooth headphones (Srhythm NC25) and these also fail both with this script when connected, and also with the dbus commands.