bug: clamp battery health values over 100

[CharaVerKys]

my battery have energy design > than actual full energy
just clamp value to 100, where health: goto's label

// also i personally not like one char var names, but who care

[tshakalekholoane]

I am not sure clamping the value is the answer if our assumptions are wrong to begin with. Do you mind attaching screenshots showing the output of the related files so that we can look into this further?

[CharaVerKys]

I am not sure clamping the value is the answer if our assumptions are wrong to begin with.

my battery design is 29, actual is 30
info from upower
there literally nothing to be wrong to begin with

wait....
that actual error with print > instead of <
idk how that happened, and i didnt re-read what i wrote

i not mind to screenshot, i even deleted packet after learning how units works, i was on avoiding systemd configs, cuz never required to actually deal with units, and always wrote my script in bashrc,
but now im actually need to run command before login, on root lvl

var health_ = x * 100 / y 
if(health_ > 100){health_ = 100;} // actually possible in real world
fmt.Println(health_)

[pepa65]

So you're saying that /sys/class/power_supply/BAT?/charge_full_design is smaller than /sys/class/power_supply/BAT1/charge_full?

That would mean that the driver is very broken...

[CharaVerKys]

no it just means that battery manufactured with well quality
yes i saying exactly that, let me boot laptop

[CharaVerKys]

and yes, forehead, i charget up to 100% just to check that, from now on i plan to never hit 100

charaverk | ~ ~$ upower -e
/org/freedesktop/UPower/devices/battery_BAT0  
/org/freedesktop/UPower/devices/line_power_AC0
/org/freedesktop/UPower/devices/DisplayDevice
charaverk | ~ ~$ cat /org/freedesktop/UPower/devices/battery_BAT0/^C
charaverk | ~ ~$ cat /sys/class/power_supply/BAT0/energy_
energy_full         energy_full_design  energy_now
charaverk | ~ ~$ cat /sys/class/power_supply/BAT0/energy_full
30754000
charaverk | ~ ~$ cat /sys/class/power_supply/BAT0/energy_full_design 
29970000
charaverk | ~ ~$ upower -i /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          BAT0
  vendor:               ASUSTeK
  model:                ASUS Battery
  power supply:         yes
  updated:              Tue 02 Sep 2025 06:35:18 PM MSK (22 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       none
    energy:              9.856 Wh
    energy-empty:        0 Wh
    energy-full:         30.754 Wh
    energy-full-design:  29.97 Wh
    voltage-min-design:  7.4 V
    capacity-level:      Normal
    energy-rate:         3.278 W
    voltage:             7.175 V
    charge-cycles:       1
    time to empty:       3.0 hours
    percentage:          32%
    capacity:            100%
    technology:          lithium-ion

upower know that it is possible so they clamp
it is really very minor bug, i mainly just hit issue to complain about short names :)

[tshakalekholoane]

That would mean that the driver is very broken...

This is what I thought. Unless we've been wrong about what the variables mean? I understand upower does this, but it still doesn't make it right does it? What are your thoughts on how we should address this @pepa65?

it is really very minor bug, i mainly just hit issue to complain about short names :)

It's fine to have a preference for longer names, some people don't. Personally, I don't have a preference, I just follow what seems to be the norm in most Go code e.g., from the standard library.

func MaxBytesReader(w ResponseWriter, r io.ReadCloser, n int64) io.ReadCloser

[pepa65]

I think keep the current math, but if it turns up higher than 100%, just cap it to a 100.

[tshakalekholoane]

Let’s go with that then.

Thank you for filing the issue @CharaVerKys. Feel free to submit the fix if you’re open to that.