Script to Play a Battery Charge Notification or Warning

[amarok]

By the way, to use this script on a different device, battery_max170xx_battery won’t work. Run upower -i upower -e | grep ‘BAT’` to see the correct native-path for the other device, e.g. battery_BAT0, battery_BAT1, etc., then substitute it.

[Gavaudan]

Why check for fully charged? The battery has to be >= 81% to be fully charged.

[amarok]

I was thinking it was necessary, because the states “charging” and “fully-charged” are both actual possible readings when you run upower -i /org/freedesktop/UPower/devices/battery_max170xx_battery. (As is “discharging.”) Since the conditional argument is checking and matching that reading, I assumed that if it returned “fully-charged,” then the argument would be ignored and the alert would continue to sound, or start sounding again, instead of stopping or staying silent.

I could be wrong, though.

[Gavaudan]

Then maybe what you’d rather want is “not discharging”?

Pseudocode: if ($state != discharging && batteryCharge >= 81)

Edit: now that I take another look, I don’t see why you’d need to worry about the state at all. You could just put a large, overarching if statement “if (battery <= 80)” and not care if it’s greater than that, since it isn’t written to do anything above 80% except to not run. You could then get rid of the last if statement altogether.

[amarok]

@amarok

elif [[ $state == charging && $battery -eq 80 ]]; then

That should work. So the second statement would be:

elif [[ $state != discharging && $battery -ge 80 ]]; then

“Else, if state is “not discharging” AND charge is greater than or equal to 80, then”

And drop the third statement.

Actually, I can’t use that in place of the second statement if I want to keep:
mplayer /home/purism/batalarm.ogg && espeak "80% charge"

But I could replace the third statement.

Testing with the replaced third statement, using bash -x batwarn.sh returns:

purism@pureos:~$ bash -x batwarn.sh
+ export XDG_RUNTIME_DIR=/run/user/1000
+ XDG_RUNTIME_DIR=/run/user/1000
++ upower -i /org/freedesktop/UPower/devices/battery_max170xx_battery
++ grep state
++ awk '{print $2}'
+ state=discharging
++ upower -i /org/freedesktop/UPower/devices/battery_max170xx_battery
++ grep percentage
++ awk '{print $2}'
+ battery=70%
+ battery=70
+ [[ discharging == discharging ]]
+ [[ 70 -le 40 ]]
+ [[ discharging == charging ]]
+ [[ discharging != discharging ]]

EDIT: But of course if one plans to regularly charge all the way to full, then maybe the 80% notification isn’t necessary.

[Quarnero]

4.20V+4%=4.368V and as recently I’ve measured 4.362V on plus and minus poles of the BPP-L503 when (or rather if charged) with some external 4.35V type of universal battery charger. Therefore as mentioned already, as I actually asked before about LiHv batteries (in particular), 4.35V in our usage scenario, allow for a higher cut-off charging voltage (please read below linked article as it explains, in several details, knowledgeable approach from Purism Team, very well thought out development approach, even unique):

@Quarnero

And please note that: “the battery capacity can be increased by about 15%.”

Now and when above understood let us take important things (for example, and as accustomed to the usage of some/any Android based smartphone, how to extended battery life if it charged only up to 81% of its nominal capacity) seriously:

@dos

Then it’s switched to constant voltage and current drops asymptotically until it reaches termination current (IIRC something around 160mA in our case). That’s the typical process of charging Li-ion cells.

This very important post from @dos and in particular this “typical process” refers to the Librem 5 only and as such (with its build-in battery charging components, taking care of all necessary, all well thought out in advance, for customer benefit, as mentioned above) it provides following as well:

@dos

FWIW, charging extra batteries can be easily done via the phone itself. If you use a powerful enough power supply with high enough input current limit, you should be able to take the battery off while keeping the phone fully operational, powered from USB. Then you can just put the other battery in and it should simply start to charge.

Now let me transfer/switch from “termination current” to “cut-off charging voltage” (as correlated and happening within very same time-frame), to the point (or millisecond) when actually red LED light that was on turns off.

@Quarnero

This self regulating of stopping charging (red LED light off) I’m finding as just another Librem 5 great feature (only phone with such capability, if this term as technical correct). Thanks for this to all involved!

Now we might even distinguish Librem 5 (ID 316D) and its belonging BPP-L5 (01,02 or 03) as two different end products where only Librem 5 regulates correctly (that I know of today) its final cut-off voltage (recently I’ve measured 4.137V, not sure yet if that was right after it was fully charged) up to the max. of 4.20V:

@dos

@guru

I should not insert the battery with this voltage. correct?

You can insert it, just keep the modem and GPS off until it goes below 4.2V ( POWER_SUPPLY_VOLTAGE_OCV ).

@guru, thanks a lot for your thread! Thanks actually for your clear awareness, to include @fsflover contribution, about correct voltage output on BPP-L503 + and − poles (just right after red color light turns off, the red one from its RGB LED)!

This correct (maximal value) cut-off voltage number of POWER_SUPPLY_CHARGE_FULL_DESIGN=4199160 aka 4.20V (and below) is firmely written down within Librem 5 Linux phone main driving software, called PureOS, as shown here (from: $ tail -n+0 /sys/class/power_supply/*/uevent):

@Gavaudan

The battery has to be >= 81% to be fully charged.

If I’m allowed to write (perhaps ): not quite, as 95% or even 100% (right after red LED light off) are just about very fine numbers as well (while my above thoughts related to the Librem 5 only). And finally, @Gavaudan, content of this post (message that I wanted to bring over to you) is important, as not that I’ve even tried to clearly rewrite what already noted within this Forum, therefore hope this post helps (somehow), including @amarok “alarm” script contribution here, helpful one (that I’ll test when more time for it), to understand that even when BPP-L503 battery charged up to 100% (no red LED light although original USB Type C 5.0V power supply plugged in) it is well taken care of Librem 5 battery health (cannot happen to be overcharged within Librem 5) and care taken about max. capacity that is actually used from it as well (few % below 4500mAh, when original battery full up to the max. allowed of 4.20V, as officially and already presented).

P.S. I’ve mentioned some external (intelligent) battery charger above, but still none of them is singing one, not based on here contributed Linux script from @amarok. Thanks therefore!

P.P.S. @Gavaudan, I do not drive around some EV, not yet, but if and once this happens I’ll recall about your 81% post for sure. Thanks therefore!

[dos]

@Quarnero

This correct (maximal value) cut-off voltage number of POWER_SUPPLY_CHARGE_FULL_DESIGN=4199160 aka 4.20V (and below)

This is CHARGE, not VOLTAGE, so it says 4200mAh (rough estimate of capacity when charged up to 4.2V instead of 4.35V, just to give the gauge something to work with until it’s calibrated and corrects itself), not 4.20V.

[Quarnero]

Sure and to be precise. Thanks for this reaction/correction (I do learn from you)! I just wanted to bring over my message (somehow), in broader terms where charging needs to be stopped (cut-off voltage at 100% within Librem 5 is just fine as taken care it will not exceed 4.20V), and hope it will be welcomed.

EDIT: Correct output line, visible within my above post upload as well (as not edited), is:
POWER_SUPPLY_VOLTAGE_MAX=4200000

[amarok]

But does always charging to 100% reduce the battery’s lifetime?

[Quarnero]

Already and precisely answered here:

@dos

so it says 4200mAh (rough estimate of capacity when charged up to 4.2V

Meaning that BPP-L503 isn’t charged up to its maximum capacity and therefore already within “green” range, carrying very well out for its prolonged life (extended one).

[Gavaudan]

I may not have been as clear as I could have, It was late last night when I wrote that (although, admittedly, it is early this morning that I write this, so take it with a grain of salt). This is what I had envisioned for you:

if [[ $battery -le 81 ]]; then

    if [[ $state == discharging && $battery -le 40 ]]; then

        mplayer /home/purism/batalarm.ogg && espeak "charge battery"

    elif [[ $state == charging && $battery -eq 80 ]]; then

        mplayer /home/purism/batalarm.ogg && espeak "80% charge" 

fi

[amarok]

Yes, your nested conditionals are better, and more efficient. I’ll use your version. Thanks!

EDIT:
@Gavaudan. It needs an extra fi, though:

if [[ $battery -le 81 ]]; then

    if [[ $state == discharging && $battery -le 40 ]]; then

        mplayer /home/purism/batalarm.ogg -loop 2 && espeak "charge battery"

    elif [[ $state == charging && $battery -eq 80 ]]; then

        mplayer /home/purism/batalarm.ogg -loop 2 && espeak "80% charge" 

        fi

fi

[Gavaudan]

@Quarnero

P.P.S. @Gavaudan, I do not drive around some EV, not yet, but if and once this happens I’ll recall about your 81% post for sure. Thanks therefore!

I’m always happy to help, but I fear you may be giving me a little too much credit here. I was just writing under the naive assumption that “fully charged” means “upower command returned 100%” regardless of the actual capacity of the battery, so if say the battery degrades to 90%, then perhaps upower will return “fully charged” once the battery reaches that percentage (or so I was thinking).

Put another way, I guess you could say I was thinking (perhaps incorrectly) that upower returned usable capacity versus total capacity.

[dos]

@Quarnero

therefore already within “green” range, carrying very well out for its prolonged life (extended one).

I’m not knowledgeable enough to say how does it influence battery wear, but yes, the battery is rated up to 4.35V, and we’re charging it only up to 4.2V, so we’re not using its full capacity anyway.

Note that this isn’t exactly the same as charging at 4.35V and stopping early, as late-stage charging happens with constant voltage and asymptotically decreasing current. I guess it’s very likely that it has a similar effect on battery wear, but I don’t know for sure.

[dos]

@Gavaudan

so if say the battery degrades to 90%, then perhaps upower will return “fully charged” once the battery reaches that percentage (or so I was thinking)

The gauge updates CHARGE_FULL dynamically, so it should reach 100% regardless of battery degradation (although the gauge does it by using a bunch of heuristics as it doesn’t actually know for sure why the charging has stopped, so there may be charging cycles where it doesn’t actually reach 100% anyway).

[Gavaudan]

@amarok

It needs an extra fi

Oops.

Hopefully now it works (literally) harmoniously?

[Quarnero]

@Gavaudan

I’m always happy to help, but I fear you may be giving me a little too much credit here.

Not at all, at least not in my humble opinion. All while I wish myself (and will proof) that any EV (or at least my future one) can handle its batteries (in total) charging like Librem 5 (just don’t know much about EV charging termination current). I meant that your post helped me for real (just trust me), on where might be safe (>= 81%) to stop charging some EV. And sure I’ve noted you are kindly helping to @amarok, noted that slightly disturbing (with good reason) your very focused contribution here.

[Gavaudan]

I gotcha, I just don’t want to come across as more technically-minded than I am if it’s going to mess with your future EV. Software and I get along pretty alright. Hardware… is a bit of a struggle.

[amarok]

Actually, I think this is a better version for getting both the low and the high warning:

#!/bin/bash

# In order for cron to play sound files it needs to export an environment variable:
export XDG_RUNTIME_DIR="/run/user/1000"

state=$(upower -i /org/freedesktop/UPower/devices/battery_BAT0 | grep "state" | awk '{print $2}')
battery=$(upower -i /org/freedesktop/UPower/devices/battery_BAT0 | grep "percentage" | awk '{print $2}')
battery=${battery/\%/}

if [[ $state == discharging && $battery -le 40 ]]; then

    mplayer /home/purism/batalarm.ogg -loop 2 && espeak "charge battery"

elif [[ $state == charging && $battery -eq 90 ]]; then

    mplayer /home/purism/batalarm.ogg -loop 2 && espeak "90% charge"

fi

That lets the low-battery warning keep playing until plugged in, and the 90% charge notification play just once (probably), given that the repetition is every 5 minutes, as specified in the cron job.

When charging, the level would certainly rise fast enough from 90%, so the notification wouldn’t keep sounding. But the -eq (is equal to) could be replaced with -ge (is greater than or equal to) to allow the notification to repeat every 5 minutes if still charging, if desired. The “90% charge” message could also be changed to, e.g. “charge complete” or “disconnect charger.”

[Gavaudan]

Does it charge fast enough that it could possibly go from 89-91 inside 5 minutes? I doubt it, but worth considering.