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.
3 Likes
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
But does always charging to 100% reduce the battery’s lifetime?
1 Like
Already and precisely answered here:
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).
1 Like
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
1 Like
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
2 Likes
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.
2 Likes
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.
2 Likes
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).
3 Likes
Oops.
Hopefully now it works (literally) harmoniously?
2 Likes
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.
1 Like
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.
1 Like
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.”
2 Likes
Does it charge fast enough that it could possibly go from 89-91 inside 5 minutes? I doubt it, but worth considering.
Do you mean charge so quickly that it skips “90” altogether and doesn’t sound at all? Possibly.
If so, what’s the proper way to represent the range “89 to 91” in bash inside that statement?
$battery -ge 89 && $battery -le 91 will return true if the battery is at 89, 90, or 91. This also means you could conceivably get the alert three different times.
If you want to make damn sure it only “dings” one time within that range, you could use a boolean variable initialized to “false” and set it to true the first time it “dings” and back to false when the battery drops back below 89.
Depending on the phone’s charging rate, though, it may or may not be necessary.
1 Like
You should be careful about whether the cron job needs to run as root (preferably not) but if so, what directory it should go in and what permissions it should have.
Also, you don’t need bash in front of the name of a shell script.
1 Like
So, like this?
*/5 * * * * /home/purism/batwarn.sh
or maybe:
./batwarn.sh
Where should root ones go? (Although I don’t plan to run any, but just out of curiosity…)
For the command, yes, but you are missing the sixth field, which gives the user to run the command as.
If the script will run fine as purism then that’s what you should do.
I believe that you should always specify full paths for commands that aren’t in the standard path. You can override the definition of the standard path in the crontab file itself if you want to.
So, in summary, /etc/crontab would contain the following line:
*/5 * * * * purism /home/purism/batwarn.sh
You may, however, be using a private crontab file i.e. a user-specific crontab file, in which case
a) you don’t specify the user (the sixth field), and
b) I don’t know how it defaults PATH and hence it would in some sense be safer to specify a full path in the command. I think PATH always has the same default.
I don’t know about “should” but I would probably put it in root's home directory i.e. /root
1 Like
Not with a cron job you can’t - because there is no shell state preserved between runs every X minutes.
Better to make it a service and then it can loop and sleep, and use boolean variables etc. If sticking with a cron job then state would need to go in a file e.g. in ~purism.