-
-
Notifications
You must be signed in to change notification settings - Fork 724
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
battery: Add {cycles}, {health} format replacements #3130
Conversation
I even did this originally, then got confused when my battery in particular showed 102% and, instead of checking the values I calculate with, just decided to do the stupid thing and do maths the wrong around
was here before, but is an easy fix for a clang-tidy warning
About the remaining
These warnings are (as far as I can tell) all caused by pre-existing code (the one float this PR introduces uses an uppercase
This was far over threshold before, and I would prefer to not refactor (rewrite) that thing. Would it be acceptable to just add to it in this case?
That one I could probably manage, if required. |
Don't worry about clang-tidy, we need to adjust it :) |
Thank you for merging, and maintaining this project in general :)
Done! |
I've updated waybar to 0.10.1, updated config, reloaded ...
"format-alt": "{time} {health} {cycles} {icon}",
... but got this error:
with just |
Did you try each one independently, or both at once? After looking at the code again, it does appear like I did, in fact, never add Edit: Since it's not actually registered, I've commented out |
I've opened #3167 to address |
I tried them independently and both: ..
"format-alt": "{time} {health} {icon}",
..
"format-alt": "{time} {cycles} {icon}",
..
"format-alt": "{time} {health} {cycles} {icon}",
..
Ok then, I've updated config to: "tooltip-format": "{health} {cycles} {capacity}%", There are no errors, but tooltip gives me only Also, I compiled 1.10.2 + fix above. Now it works as I should I do next? |
Btw, tried run $ sudo inxi -B -v8 | grep Battery -A3
Battery:
ID-1: BAT1 charge: 26.0 Wh (100.0%) condition: 26.0/47.5 Wh (54.7%)
volts: 12.4 min: 10.8 model: Sony Corporation type: Li-ion serial: N/A
status: full There is no cycles count but shows the condition, so theoretically |
Well, theoretically, yes. Practically is a different story. I do not know how
|
I have this files, not $ ls -la /sys/class/power_supply/*/*_full{,_design}
-r--r--r-- 1 root root 4096 Apr 24 15:10 /sys/class/power_supply/BAT1/energy_full
-r--r--r-- 1 root root 4096 Apr 24 15:10 /sys/class/power_supply/BAT1/energy_full_design
$ ls -la /sys/class/power_supply/*/cycle_count
-r--r--r-- 1 root root 4096 Apr 24 15:10 /sys/class/power_supply/BAT1/cycle_count
$ cat /sys/class/power_supply/*/*_full{,_design}
26000000
47520000
$ cat /sys/class/power_supply/*/cycle_count
0 |
Thank you. I will implement checking for |
This PR adds the following format replacements to the
battery
module (currently for Linux only):{cycles}
- Displays the amount of charge cycles the selected1 battery has seen.{health}
Displays a percentage representing the selected1 batteries max charge, relative to it'sdesign
(original) max charge.Battery selection1
Currently, both of the new format replacements select the battery candidate with the highest
charge_full_design
. This seemed the most intuitive for{cycles}
, and I have applied the same logic to{health}
to stay consistent with this. Should multiple batteries have the samecharge_full_design
, the "worse" value (i.e. higher cycle count, lower health percentage) is displayed.However, I could also imagine using a
charge_full_design
weighted average of all eligible batteries' percentages for{health}
, so it could represent the health of a full battery array.