Battery events not working on Ubuntu 16.04

[Saboteur777]

Hey,

I am trying to achieve additional powersaving features for my laptop, so I tried to set up tasks based on battery events. But as you can guess, it didn't work.

The history is completely blank:

I have tried both When and When Wizard - what might be the problem? Using a different kernel (yakkety, 4.6.3-040603-generic #201606241434) makes a difference?

[almostearthling]

There are some things that could be inspected:

• all event types (charging, discharging and low) fail?
• are the battery events dispatched by DBUS on your hardware and/or Linux distribution and release?
• in case the previous answer is positive, are these events signaled through the org.freedesktop.UPower bus?

I know it might be quite hard to answer to all these questions: I'll try to see if I can investigate a way to verify this with a simple script, for example. Unfortunately I only have access to two PCs (a laptop and a desktop system) where I develop When, so I try to use generic methods (DBUS, in fact) to catch system events.

I cannot tell whether or not a different kernel could help, however I noticed that DBUS signals sometimes change even across Ubuntu releases, which is a pity - I had to develop a "fallback" mechanism to support different Ubuntu releases OOTB - and this, of course, makes things quite difficult for me when it comes to support things that are hard to verify, for example, inside a VM.

[almostearthling]

Also... Can you tell me what version of Linux (distro and release) are you using? I could try to see if battery events are correctly handled by the OS before investigating your workstation!

[Saboteur777]

• Charging and discharging failed. Low battery - I mainly use my computer on AC, and it takes "ages" to deplete, so I changed percentage-low key in dconf-editor to 95, but nothing happened (low battery tasks didn't trigger).
• I think so, as I am using Ubuntu 16.04 with Unity
• I ran upower --monitor-detail > power.txt, the output is attached. The answer is yes, I think.

power.txt

[almostearthling]

Well, now I have a lot of information indeed. For what I can see the problem is probably that I don't always subscribe for the correct signals under all circumstances, as it really looks that no particular buses or interfaces are used in your setup... I hope I'll get through it soon, and thank you for pointing out the issue!

For now let me change the issue name, for I think it might not be bound to your particular combination of OS and machine.

[Saboteur777]

Thank you, I am glad you got what you needed! :) Keep going, I like your work! ;)

[almostearthling]

I started testing When on Xenial on a laptop, actually a hypervisor works almost fine in terms of passing battery status to guests. And in fact battery events are not noticed by When on Xenial. However the signals appear to be correctly registered at startup in the log files (with log level set to debug):

2016-09-12 23:12:14 INFO: GLOBAL: adding stock signal handler for event 'battery_discharging'
2016-09-12 23:12:14 INFO: DBUS: battery_discharging: signal handler org.freedesktop.UPower:Changed correctly registered
2016-09-12 23:12:14 INFO: MAIN: handler for org.freedesktop.UPower:Changed registered as event 'battery_discharging'
[...]
2016-09-12 23:12:14 INFO: GLOBAL: adding stock signal handler for event 'battery_low'
2016-09-12 23:12:14 INFO: DBUS: battery_low: signal handler org.freedesktop.UPower:Changed correctly registered
2016-09-12 23:12:14 INFO: MAIN: handler for org.freedesktop.UPower:Changed registered as event 'battery_low'
[...]
2016-09-12 23:12:14 INFO: GLOBAL: adding stock signal handler for event 'battery_charge'
2016-09-12 23:12:14 INFO: DBUS: battery_charge: signal handler org.freedesktop.UPower:Changed correctly registered
2016-09-12 23:12:14 INFO: MAIN: handler for org.freedesktop.UPower:Changed registered as event 'battery_charge'

Nevertheless I was curious, and wanted to see what signals are available from the org.freedesktop.UPower system bus: on Trusty When catches the Changed signal

but when it comes to Xenial, D-Feet shows the following signals only:

you can notice that Changed is no more available.

Thus, there are two orders of problems:

1. why does When report that the signals were registered correcly?
2. what can be used as an alternate signal to gather battery related events?

Well, I still haven't got a solution for now, but at least I discovered what happens, as well as another possible issue. I know it's just the beginning, but at least I can start to try to fix something.

[almostearthling]

It almost drove me crazy!

The problem with DBus is that a comprehensive documentation about its basics is quite hard to find. Moreover, there is still old documentation hanging around, which seems to have almost the same dignity as the most recent documentation.

However, let's come to the details: When now listens to other events, both in Trusty and in Xenial. Unfortunately the actual three events that Trusty used to trigger on the three different states that When handles have not been ported to Xenial. Now I have to listen to every change in battery properties (which is notified by different signals in Trusty and Xenial!) and find out the state reading the device properties. Since battery status changes all the time, I had to implement a flag for each different status and three callback functions specifically dedicated to battery: after I did my best to catch DBus signals in a generic fashion, I can't say that this is a solution I like. There must be better ways to do this, but for now I think that it's an acceptable workaround.

Moreover, since even handlers for non-existing signals are correctly registered without complaint from DBus, I forced When to lookup into DBus prior to registering a signal handler, and verify that an interface actually exposes a signal: this happens at startup and should not cause much overhead at runtime, apart from the increased size: the bonus is that laptop battery event registration correctly fails on desktop systems.

Changes might not be very stable for now, but the latest version can be found at commit e261c630a17e10836aece1e0ed99812ec361a755. If you want, you can test this release without having to tinker with an existing PPA setup: you can either perform a manual installation from the current master branch (which I discourage! :smiley:) or you can pick the when-command_0.9.12.beta.4.tar.gz file from release v0.9.12-beta.4, unpack it in a folder under your home directory, for example in ~/Apps, and then replace ~/Apps/When/when-command/share/when-command/when-command.py with the one from the master branch on GitHub. Then, cd to ~/Apps/When and run $PWD/when-command --install. Next time you start When from the dash it will be the newly installed one.

If you want to revert to the PPA version, just run when-command --install from the command line without the $PWD prefix.

In this way you can test the forthcoming release and see if this works for you too... it would be helpful.

[Saboteur777]

Wow, you did it! :heart_eyes: Following your guide I have successfully installed it, and now it is working fine! Thank you! :sunglasses:

[almostearthling]

Great! It's time to repackage, then. Btw I also checked that the low-battery condition is correctly triggered just some seconds before the laptop automatically enters suspended state. If you installed from the PPA, just run when-command --install from a terminal after the update. At next logon you should be able to throw away the folder you installed the pre-release into.

Just let me double-check everything and possibly clean something up, and then I'll package When and create a new release, both here and on Launchpad.

Thank you again!