I3status-rust: Bug: BAT0/charge_full can't be read

Created on 21 May 2017  路  16Comments  路  Source: greshake/i3status-rust

My batter doesn't support doing charge_full but BAT0/capacity does work (exactly the same as far as I can tell). How would you feel about me adding an option so that someone can specify the proper endpoint. Alternatively if there are only a few proper endpoints across the majority of devices it can just detect which one works.

bug

All 16 comments

Phew... Capacity actually reports finished battery percentage for me. But, if the battery is on ac and full reports over 100 (since my battery doesn't charge up to full capacity anymore). Can you look for docs or something showing that capacity is actually better to read from? Does your capacity report mAh or a percentage?

I verified that the /capacity does change as the battery goes down so that's a good sign. I couldn't find anything specific about whether one was better than the other though.

I went to the official docs: https://www.kernel.org/doc/Documentation/power/power_supply_class.txt

Attributes/properties detailed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~ ~ ~ ~ ~ ~ ~  Charge/Energy/Capacity - how to not confuse  ~ ~ ~ ~ ~ ~ ~
~                                                                       ~
~ Because both "charge" (脗碌Ah) and "energy" (脗碌Wh) represents "capacity"  ~
~ of battery, this class distinguish these terms. Don't mix them!       ~
~                                                                       ~
~ CHARGE_* attributes represents capacity in 脗碌Ah only.                  ~
~ ENERGY_* attributes represents capacity in 脗碌Wh only.                  ~
~ CAPACITY attribute represents capacity in *percents*, from 0 to 100.  ~
~                                                                       ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
[...]
CAPACITY - capacity in percents.
CAPACITY_ALERT_MIN - minimum capacity alert value in percents.
CAPACITY_ALERT_MAX - maximum capacity alert value in percents.
CAPACITY_LEVEL - capacity level. This corresponds to
POWER_SUPPLY_CAPACITY_LEVEL_*.
[...]
Q: Suppose, my battery monitoring chip/firmware does not provides capacity
   in percents, but provides charge_{now,full,empty}. Should I calculate
   percentage capacity manually, inside the driver, and register CAPACITY
   attribute? The same question about time_to_empty/time_to_full.
A: Most likely, no. This class is designed to export properties which are
   directly measurable by the specific hardware available.

   Inferring not available properties using some heuristics or mathematical
   model is not subject of work for a battery driver. Such functionality
   should be factored out, and in fact, apm_power, the driver to serve
   legacy APM API on top of power supply class, uses a simple heuristic of
   approximating remaining battery capacity based on its charge, current,
   voltage and so on. But full-fledged battery model is likely not subject
   for kernel at all, as it would require floating point calculation to deal
   with things like differential equations and Kalman filters. This is
   better be handled by batteryd/libbattery, yet to be written.

As we can see, we can't reliably read any values from the driver that are not present, instead we're supposed to use a system battery service if a value isn't presented by the driver directly. But, if available, we can certainly use capacity instead of my current calculation as default, and fall back to my old method if capacity isn't calculated by the driver.
We now need to decide where to take advanced values from (e.g. time remaining) or if we should calculate them ourselves.

We can do a crude estimation by calculating CHARGE_NOW / CURRENT_NOW. But that number would be very jumpy, no smoothing out or anything. A system service for time remaining would still be preferred if available.

It looks like that's how most people are solving the problem. There is a package called acpi that might be interesting, I don't know if it calculates the time remaining any better than we could though. I haven't been able to test it cause I'm at work on a Mac but I can maybe give it a try tonight.
https://www.archlinux.org/packages/community/i686/acpi/

Tried acpi, but doesn't report time remaining for me. Seems to use the same kernel interface and doesn't seem to calculate it itself

My batter doesn't support doing charge_full but BAT0/capacity does work

Likewise, for me there exists a energy_full file. Any update on this? :/

@rubdos As far as I know there hasn't been a consensus reached. I ended up just using the custom block. Not an ideal solution but it works for now.

[[block]]
block = "custom"
command = "cat /sys/class/power_supply/BAT0/capacity"
interval = 60

I'm implementing a solution, stand by :)

Not an ideal solution but it works for now.

Thanks @keeslinp, that works for now. Doesn't look great, but at least it works :-)

I'm implementing a solution, stand by :)

That's awesome. Thanks for the work on this bar; so far it's great.

@rubdos Please post the output of ls /sys/class/power_supply/BAT0 (or whatever your battery device is).

Check if it works for you now

rsmet@arch-club ~ % ls /sys/class/power_supply/BAT0
alarm           cycle_count  energy_full_design  model_name  present        subsystem   uevent
capacity        device       energy_now          power       serial_number  technology  voltage_min_design
capacity_level  energy_full  manufacturer        power_now   status         type        voltage_now
rsmet@arch-club ~ % ls /sys/class/power_supply/BAT1
alarm           cycle_count  energy_full_design  model_name  present        subsystem   uevent
capacity        device       energy_now          power       serial_number  technology  voltage_min_design
capacity_level  energy_full  manufacturer        power_now   status         type        voltage_now
rsmet@arch-club ~ %

I'll fetch master and report back.

EDIT: I have a build error in dbus. Weird.

Build error was my problem; had to -Syu base-devel. Seems like my second battery works, but my first one doesn't give a percentage (Is that because it's full?):

[[block]]                                                             
block = "battery"                                                     
interval = 10                                                         
device = 0                                                            

[[block]]                                                             
block = "battery"                                                     
interval = 10                                                         
device = 1

Yea I omitted outputting the battery percentage when full, it just shows a full battery icon in that case. So you guys think I can close this issue? What about @keeslinp ?

You have my blessing; since I got the icons to work it does make sense. Thanks again for your work.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jpeeler picture jpeeler  路  5Comments

Thra11 picture Thra11  路  6Comments

oschoudhury picture oschoudhury  路  6Comments

YodaEmbedding picture YodaEmbedding  路  4Comments

marvin-steinke picture marvin-steinke  路  4Comments