Package Details: batteryinfo 1.2.1-1

Git Clone URL: (read-only)
Package Base: batteryinfo
Description: A simple battery status and information tool for Linux systems.
Upstream URL:
Licenses: GPL3
Submitter: c0d3st0rm
Maintainer: c0d3st0rm
Last Packager: c0d3st0rm
Votes: 2
Popularity: 0.000029
First Submitted: 2016-08-05 18:03
Last Updated: 2016-08-16 16:48

Dependencies (1)

Required by (0)

Sources (1)

Latest Comments

c0d3st0rm commented on 2016-08-08 20:54

One thing to note while testing remaining battery life (and the reason why I haven't released an update yet), is that the projected values are not very accurate at all on my system, and should be halved at least for an accurate estimate, which is strange as the value should be logically accurate, but I'll do a bit more looking into it in the meantime. As far as I recall, the current method is how the ACPI specification recommends you calculate remaining battery life. Systems such as Windows, however, are able to notably achieve a more accurate estimate because they average out the results over a period of time.

jasch commented on 2016-08-07 20:12

I'd do it with the normal scientific approach: measure a few times so random fluctuations get cancelled out.
I thought about basically running a python script that creates a certain load and logs the load averages and battery information.
measure it for different load intervals. 1 second, 10 seconds, 1 minute and so on.

I should be able to get a correction/estimation from the load averages. But I don't think so, a load average over 10 seconds and even 1 second would kind of be needed for it.

Another attempt could be to average over a 100 ms timespan in your program. that's a short enough delay for the user to not notice it. and maybe remove spikes.

c0d3st0rm commented on 2016-08-07 20:04

Indeed, strange for it to give you your full (design) charge. What driver does it use? Perhaps for compatibility, that value should be capped at 100% with a command line option to remove that cap.

I think a hashing routine performed on randomised data every X microseconds would work well, although it'd have to be one which doesn't do *too* much processing - MD5 maybe? This would have to be, however: A) ran quite often (every bootup/once per reboot?) and B) with absolutely nothing else which could cause the battery usage to temporarily fluctuate.

Also, load can differ greatly with things such as having an advanced window manager, having servers and daemons running in the background (assuming their processes aren't sleeping), etc.

jasch commented on 2016-08-07 16:06

Fully charged now:

$ cat /sys/class/power_supply/BAT0/uevent

$ batteryinfo ct
battery: 0
charge: 103.91%
max_charge: 96.24%

$ acpi -bi
Battery 0: Full, 100%
Battery 0: design capacity 6800 mAh, last full capacity 6544 mAh = 96%

This appears to be a problem not in your program but in the source.

jasch commented on 2016-08-07 15:19

Yeah, you can not really average without storage. What would be possible too is to take the load average over 1 minute and over 5 minutes and try to correct the value a bit. If both 1min and 5min are roughly the same you have a continuous load and the calculation is probably accurate.
If the 1min average is higher than the 5min average this might indicate a short spike. It might be possible to calculate a correction to the remaining time with thoes two values.
I'm gonna look further into that. But it will probably need some time, gotta figure out how to create a reliable load that is reproducable to check stuff.

c0d3st0rm commented on 2016-08-07 14:53

That's certainly very interesting - my testing has never resulted in a value above 100%. Can you post the contents of your uevent file with your device at full charge?

Your second edit is exactly what I was thinking about - battery drain can vary dramatically depending on the device, what it's processing, whether it's powering/charging something over USB or not, etc - because of this, the reading would only be accurate if the system's activity (and assumedly therefore power consumption) stayed consistent. However, it should be a useful feature anyway, just marked at "estimated battery life at current discharge rate". Averaging it out, however, would need to store data in either memory (daemon) or on disk (cache). And yes, that would be an ideal way to implement it :)

jasch commented on 2016-08-07 14:35

The way you handle charge and max charge makes sense, but it appears to not be working as expected. You said that charge would range from 0-100%, but i get this output for a fully charged battery and connected to the charger:

$ batteryinfo ct
battery: 0
charge: 103.91%
max_charge: 96.24%

As with the remaining time indicator:
what you could do is take the current charge (/sys/class/power_supply/<your_battery>/charge_now) and divide it by the current current (.../current_now) (see example below). This seems to give you about the same time in hours that acpi gives you in regard to the remaining time.
This also makes sense from a physics point of view: The charge is basically how much current the source can deliver for how long. This is usually indicated in Ampere*hour. The current is how much ampere is used right now. If you divide the charge by the current you get the time how long the source will be able to continue to supply the demand.
No daemon needed :)

echo "scale=2;$(cat /sys/class/power_supply/BAT0/charge_now)/$(cat /sys/classpower_supply/BAT0/current_now)" | bc

EDIT: I'd write you a pull request, but my understanding of C is very close to zero. So you gonna have to do it.

EDIT2: The problem with this approach is that it can fluctuate a lot. What may be an option is to calculate it a few times and give an average.

EDIT3: I also figured out how to calculate an ETA for the battery being fully charged:

$ echo "scale=2;($(cat /sys/class/power_supply/BAT0/charge_full)-$(cat sys/class/power_supply/BAT0/charge_now))/$(cat /sys/class/power_supply/BAT0/current_now)" | bc


c0d3st0rm commented on 2016-08-07 11:20

Hey jasch,

Thanks for the feedback! I've implemented the -a/--all flag in the upstream git repo.

And on the subject of your charge being higher, that's a detail I forgot to explicitly mention anywhere, which on afterthought would be rather confusing - that value (charge) will always range from 0-100%, independently of your max_charge; max_charge tells you how much charge your battery can store (in relation to what it was designed to store), while charge is a percentage showing how much of that remains, if that makes sense. I'll update the man page soon to mention that - I didn't realize that the names of the output parameters seem confusing because I already knew what they meant, so overlooked that fact.

I've thought about that, and it seems like a worthwhile feature, however that would either require the program to run in the background as a daemon, periodically recording the current battery charge (and other factors such as cpu load), or for it to record that data somewhere in a file every time it's run. It could be implemented as an extension/optional feature (either enable at build time or through a command line flag) though, if people would find that useful.

jasch commented on 2016-08-07 09:44

I like it, especially the fact that you can output it in json.
Two things I noticed:
- it might be convenient to have a --all flag, which would basically be the same as 'batteryinfo nctvCTmMeshHrpog'. But that's mostly me being lazy.
- I had it that my current charge was higher than my total (maximum) charge. It was like this:

$ batteryinfo ct
battery: 0
charge: 97.98%
max_charge: 96.24%

I don't know if this is a problem with batteryinfo or a problem with something else. Just wanted to let you know!

EDIT: another thing that might be interesting would be a "battery time remaining" indicator as is provided with something like 'acpi -b'. But that's just a thought.