Feat: battery info

[kassick]

Show battery percentage when a battery is present in upower

fixes #14

Should work out-of-the-box for mice and keyboards.

Headset battery (currently) requires enabling experimental features in bluez:

1. create a systemd drop-in /etc/systemd/system/bluetooth.service.d/10-experimental.conf with contents

[Service]
ExecStart=
ExecStart=/usr/libexec/bluetooth/bluetoothd -E none

(see #42 (comment) for an explanation of the none argument)

2. systemctl daemon-reload
3. systemctl restart bluetoothd

[kassick]

Related: #14

[bjarosze]

Nice job, thanks!

[bjarosze]

I am testing it right now.
It works fine expect updating battery level.

Steps to reproduce:

1. Connect device
2. I see battery level 100%
3. Using it for some time
4. Battery level is still 100%
5. Disconnect and connect again
6. Battery level is 50%

I don't see this log: this._logger.info(`${_dev.native_path} notified ${pspec.name}, percentage is ${_dev.percentage}`); so I guess event never arrived, but I don't know why.

[kassick]

That's weird. Here it updates as expected -- the event is triggered, the percentage is updated.

I'm testing on ubuntu 21.04 with the pipewire-upstream PPA enabled (libupower-glib==0.99.11-2, upower==0.99.11-2, bluez==5.56-0ubuntu4.2, pipewire==0.3.38-2~ubuntu21.04)

What's the output of upower -d when you observe that the device did not update it's percentage?
Does upower -m --monitor-detail report any change for the target device?

I've been using it with my devices and it usually works fine with headset devices (whose battery reporting is still an experimental feature).

For keyboard and mice, though, the reported values are not that trustworthy -- my mouse's reported battery level has been alternating between 0% and 20% for the past month (I did not charge it in the meanwhile). My keyboard, after the last charge, insisted in reporting 10%, and now it has started reporting 30-ish% (which seems more precise, given the last time I've charged it).

[kassick]

On my machine, upower is generating the events as expected:

▶ journalctl -f --user -g bluet
-- Journal begins at Thu 2021-07-29 10:28:05 -03. --


out 14 09:48:21 11899-nb gnome-shell[70039]: [bluetooth-quick-connect] Menu toggled: true
out 14 09:48:21 11899-nb gnome-shell[70039]: [bluetooth-quick-connect] Disconnecting idle monitor
out 14 09:48:24 11899-nb gnome-shell[70039]: [bluetooth-quick-connect] Menu toggled: false
out 14 09:48:24 11899-nb gnome-shell[70039]: [bluetooth-quick-connect] Connecting idle monitor

---- HERE ----
out 14 09:51:15 11899-nb gnome-shell[70039]: [bluetooth-quick-connect] /org/bluez/hci0/dev_EA_CA_F0_6C_C1_B0 notified percentage, percentage is 5
---- HERE ----

out 14 09:54:00 11899-nb gnome-shell[70039]: [bluetooth-quick-connect] Menu toggled: true
out 14 09:54:00 11899-nb gnome-shell[70039]: [bluetooth-quick-connect] Disconnecting idle monitor
out 14 09:54:06 11899-nb gnome-shell[70039]: [bluetooth-quick-connect] Menu toggled: false
out 14 09:54:06 11899-nb gnome-shell[70039]: [bluetooth-quick-connect] Connecting idle monitor

I'll try to observe on my fedora 34 box to see if the events are being triggered as expected.

If on other versions of upower/bluez we observe the percentage values are changing, but no events arriving at the extension, we can swap the notify signal for a timer

[kassick]

Also:

1. locate the battery device with busctl tree org.freedesktop.UPower
2. verify the output of busctl introspect org.freedesktop.UPower /org/freedesktop/UPower/devices/${DEVICE_ID} , for the correct DEVICE_ID

For my JBL headset, though it has a value for Percentage in dbus, upower -i /org/freedesktop/UPower/devices/${DEVICE_ID} does not show the value

[bjarosze]

Ok, I will merge it and try to find out why on my headphones it doesn't work

[kassick]

I had an issue after upgrading to ubuntu hirsute (bluez 5.61) on my work computer -- running bluez with experimental features would stop my logitech mouse from reconnecting after reboots or hibernation. The same happens with Fedora on the same machine.

The problem seems to be somewhere in the LL Privacy experimental feature.

I worked around the it by running bluetoothd with -E none -- this disables all the experimental features identified by UUIDs, but not the experimental DBus interfaces (battery and advertise monitor). This is not a very robust solution, as it depends on a behaviour of the argument parser that I believe was overlooked by the devs, but currently works for me (bluez 5.62)

One other option is to pass all experimental UUIDs except for 15c0:

ExecStart=/usr/libexec/bluetooth/bluetoothd -E d4992530-b9ec-469f-ab01-6c481c47da1c,671b10b5-42c0-4696-9227-eb28d1b049d6,330859bc-7506-492d-9370-9a6f0614037f,a6695ace-ee7f-4fb9-881a-5fac66c629af

The supported uuids are present in the upstream main.conf file -- currently (5.62), they are:

# d4992530-b9ec-469f-ab01-6c481c47da1c (BlueZ Experimental Debug)
# 671b10b5-42c0-4696-9227-eb28d1b049d6 (BlueZ Experimental Simultaneous Central and Peripheral)
# 15c0a148-c273-11ea-b3de-0242ac130004 (BlueZ Experimental LL privacy)
# 330859bc-7506-492d-9370-9a6f0614037f (BlueZ Experimental Bluetooth Quality Report)
# a6695ace-ee7f-4fb9-881a-5fac66c629af (BlueZ Experimental Offload Codecs)

[bjarosze]

I've checked my headphones (Ticpods 2 pro) with busctl introspect org.freedesktop.UPower and there are no updates on battery at all. It gets updated only if I disconnect and connect it again.

So I guess it's issue with my headphones.

[genodeftest]

@kassick Thank you very much for this change!

1. create a systemd drop-in /etc/systemd/system/bluetooth.service.d/10-experimental.conf with contents

How about using systemctl edit bluetooth.service instead? That works fine for me at least and reduces the risk of doing something wrong with the file (permissions, especially with SELinux or umask) or the filename (protection from common typos).

2. systemctl restart bluetoothd

This should be systemctl restart bluetooth (without trailing letter d), shouldn't it?