Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Annoying battery notifications #2317

Closed
1 task done
JPenuchot opened this issue Apr 2, 2024 · 13 comments · Fixed by #2362
Closed
1 task done

Annoying battery notifications #2317

JPenuchot opened this issue Apr 2, 2024 · 13 comments · Fixed by #2362

Comments

@JPenuchot
Copy link

blueman: 2.4
BlueZ: 5.73
Distribution: Arch Linux
Desktop environment: Sway

Hi,

I'm getting a notification every time my earbuds' batteries drop by 1%. It is getting pretty annoying, how do I disable that?

Regards,
Jules

@cschramm
Copy link
Member

cschramm commented Apr 2, 2024

Right-click, Plugins, ConnectionNotifier

@cschramm cschramm closed this as completed Apr 2, 2024
@ouuan
Copy link

ouuan commented Apr 7, 2024

Right-click, Plugins, ConnectionNotifier

This also disables all connected/disconnected messages, not just battery updates. I would like to see the battery status only once when the device is first connected, but not on subsequent updates (drop by 1%).

@cschramm
Copy link
Member

cschramm commented Apr 8, 2024

To be honest I haven't seen a device that provides battery updates with a 1 % granularity. We can make notifications configurable, of course, but could it be a reasonable tradeoff to only show new values if they are multiples of 10 % or would that still annoy you?

@ouuan
Copy link

ouuan commented Apr 8, 2024

We can make notifications configurable, of course, but could it be a reasonable tradeoff to only show new values if they are multiples of 10 % or would that still annoy you?

10% only sounds acceptable to me.

@4eUeP
Copy link

4eUeP commented Apr 8, 2024

I also find this annoying, especially since my keyboard's battery is "unstable". So I add an option to turn off battery updates: 4eUeP@5a9ac22

We can make notifications configurable
could it be a reasonable tradeoff to only show new values if they are multiples of 10 %

How about showing notifications only when the battery level is lower than a value(e.g., 10%)?

Proposal: a new option, e.g., min-battery-level: Int. Notifications will be shown only if the current battery level is below the setting. 0 means disable battery-updates notifications.

@cschramm cschramm reopened this Apr 9, 2024
@JPenuchot
Copy link
Author

To be honest I haven't seen a device that provides battery updates with a 1 % granularity.

The Galaxy Buds2 Pro do that unfortunately :/

@cschramm
Copy link
Member

Not sure about a minimum battery level. The purpose of the notifications is (or was) to inform about the current level. Most of that should be rather up to a power management tool and in many cases they probably do handle it by now (via UPower).

A "running low" logic in blueman seems a bit pointless in light of power management tools and an arbitrary threshold does not sound like a good idea, e.g. mice typically provide distinct levels like 100 %, 80 %, 50 % and 20 % for which a 10 % threshold would just never trigger.

The applet plugin for battery level notifications used to be separate and I'd say the main purpose was to show the level on connection. We merged it with ConnectionNotifier to show a single notification for the connection that included the battery level. The "depletion" notifications are more or less a leftover and we could also drop them completely. 🤷

@askmeaboutlo0m
Copy link

I have devices that can't decide what their battery level is supposed to be, they flicker back and forth between 100% and 90% several times as their battery depletes. So a change to the threshold to 10% would not fix the notification annoyance.

Turning off the ConnectionNotifier plugin altogether is fine by me, just mentioning this in case it's useful to help with the solution.

@kuraga
Copy link
Contributor

kuraga commented Apr 11, 2024

Now I see these notifications. And there are a lot of them.

blueman-applet 15.44.57 DEBUG    Base:67 _properties_changed: /org/bluez/hci0/dev_1C_6E_4C_80_0D_6E {'Percentage': 80} [] <Battery.Battery object at 0x7fc84dca1900 (blueman+bluez+Battery+Battery at 0x55d9e08da160)>
blueman-applet 15.45.07 INFO     Notification:242 do_g_signal: 1
blueman-applet 15.45.07 DEBUG    Notification:246 do_g_signal: The notification expired.
blueman-applet 15.45.17 DEBUG    Base:67 _properties_changed: /org/bluez/hci0/dev_1C_6E_4C_80_0D_6E {'Percentage': 60} [] <Battery.Battery object at 0x7fc84dca1900 (blueman+bluez+Battery+Battery at 0x55d9e08da160)>
blueman-applet 15.45.27 INFO     Notification:242 do_g_signal: 1
blueman-applet 15.45.27 DEBUG    Notification:246 do_g_signal: The notification expired.
blueman-applet 15.45.58 DEBUG    Base:67 _properties_changed: /org/bluez/hci0/dev_1C_6E_4C_80_0D_6E {'Percentage': 80} [] <Battery.Battery object at 0x7fc84dca1900 (blueman+bluez+Battery+Battery at 0x55d9e08da160)>
blueman-applet 15.46.07 INFO     Notification:242 do_g_signal: 1
blueman-applet 15.46.07 DEBUG    Notification:246 do_g_signal: The notification expired.
blueman-applet 15.47.58 DEBUG    Base:67 _properties_changed: /org/bluez/hci0/dev_1C_6E_4C_80_0D_6E {'Percentage': 60} [] <Battery.Battery object at 0x7fc84dca1900 (blueman+bluez+Battery+Battery at 0x55d9e08da160)>
blueman-applet 15.48.07 INFO     Notification:242 do_g_signal: 1
blueman-applet 15.48.07 DEBUG    Notification:246 do_g_signal: The notification expired.
blueman-applet 15.48.18 DEBUG    Base:67 _properties_changed: /org/bluez/hci0/dev_1C_6E_4C_80_0D_6E {'Percentage': 80} [] <Battery.Battery object at 0x7fc84dca1900 (blueman+bluez+Battery+Battery at 0x55d9e08da160)>
blueman-applet 15.48.27 INFO     Notification:242 do_g_signal: 1
blueman-applet 15.48.27 DEBUG    Notification:246 do_g_signal: The notification expired.

@cschramm
Copy link
Member

cschramm commented Apr 12, 2024

Well, ok, I don't see us going down that rabbit hole. So, as we do not want to get into power management applet business, I suggest that we show the battery level on connection only and do not process any updates.

@mar565
Copy link

mar565 commented Apr 27, 2024

I also find this annoying, especially since my keyboard's battery is "unstable". So I add an option to turn off battery updates: 4eUeP@5a9ac22

How can I change this setting? Is there a config somewhere? Also the threshold idea seems the way to go.

@ouuan
Copy link

ouuan commented Apr 27, 2024

How can I change this setting? Is there a config somewhere?

There is a link to the fork, so the config is in that fork and is not merged here. You need to build the fork if you want to use it right now.

Also the threshold idea seems the way to go.

The conversations above have concluded that the threshold idea is not the way to go. Instead, we will "show the battery level on connection only and do not process any updates". Please read them and give your argument if you disagree.

cschramm added a commit to cschramm/blueman that referenced this issue May 9, 2024
From feedback in blueman-project#2317 it became pretty clear that battery data is a mess with devices providing levels like full, medium, low and devices providing fine-grained percent values, flapping values etc. and we do not want to go into power management applet business, so we only show a single battery connection (when the battery interface shows up or - if the interface is already present when the device connects - when the existing interface sends its first property update) and drop the reference to the connection notification to update so that further values do not lead to a notification. (In case people will ask for those notifications we might add them as a separate plugin that's disabled by default.)

Due to the great demand, I plan to backport this for 2.4.2, even though it's technically a regression.

Closes blueman-project#2317
@cschramm
Copy link
Member

Please try #2362

cschramm added a commit to cschramm/blueman that referenced this issue May 10, 2024
Backport of blueman-project#2362 due to the great demand seen in blueman-project#2317. This is technically a regression, but the current behavior seems unacceptable in many cases, so let's pretend that we never intentionally added those additional notifications.

Closes blueman-project#2317
cschramm added a commit that referenced this issue May 15, 2024
From feedback in #2317 it became pretty clear that battery data is a mess with devices providing levels like full, medium, low and devices providing fine-grained percent values, flapping values etc. and we do not want to go into power management applet business, so we only show a single battery connection (when the battery interface shows up or - if the interface is already present when the device connects - when the existing interface sends its first property update) and drop the reference to the connection notification to update so that further values do not lead to a notification. (In case people will ask for those notifications we might add them as a separate plugin that's disabled by default.)

Due to the great demand, I plan to backport this for 2.4.2, even though it's technically a regression.

Closes #2317
infirit pushed a commit to cschramm/blueman that referenced this issue May 15, 2024
Backport of blueman-project#2362 due to the great demand seen in blueman-project#2317. This is technically a regression, but the current behavior seems unacceptable in many cases, so let's pretend that we never intentionally added those additional notifications.

Closes blueman-project#2317
infirit pushed a commit to cschramm/blueman that referenced this issue May 15, 2024
Backport of blueman-project#2362 due to the great demand seen in blueman-project#2317. This is technically a regression, but the current behavior seems unacceptable in many cases, so let's pretend that we never intentionally added those additional notifications.

Closes blueman-project#2317
cschramm added a commit that referenced this issue May 15, 2024
Backport of #2362 due to the great demand seen in #2317. This is technically a regression, but the current behavior seems unacceptable in many cases, so let's pretend that we never intentionally added those additional notifications.

Closes #2317
@cschramm cschramm mentioned this issue May 23, 2024
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants