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.
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).
Oops.
Hopefully now it works (literally) harmoniously?
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.
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.
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.”
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.
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.
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
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.
FWIW, what used to work under Amber doesn’t seem to be working under Byzantium i.e. a shell script that runs as a cron job that attempts to play a sound. In my case the cron job is not running as user purism but that did previously work.
The shell script works correctly if I create a Terminal from the phone GUI and then run the shell script (which is therefore running “interactively” as purism).
If I ssh in as the other user and run the script “interactively” then it executes without incurring any errors but just doesn’t play any sound! (Doing this works fine on Raspbian although the application there is completely different.)
I haven’t yet worked out whether this simply won’t work under Byzantium or it needs changes. Anyone got something like this working under Byzantium?
Odd… I was already on byzantium when I created this script.
If I ssh in as purism (my only user), the command mplayer /home/purism/batwarn.ogg plays the warning on the L5.
My cron is:
*/5 * * * * ./batwarn.sh
And my currrent script is:
#!/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
fi
# mplayer /home/purism/batalarm.ogg && espeak "charge battery"
#elif [[ $state == charging && $battery -eq 90 ]]; then
# mplayer /home/purism/batalarm.ogg && espeak "90% charge"
It was working before (and recently), but now it seems to not be working.
EDIT: battery_BAT0 should be battery_max170xx_battery for the L5. (See my next comment.)
OK, thanks for the data point. I’m not playing using mplayer and I’m not playing a .ogg file - so those are some differences for me to explore. (I’m playing a .wav file.)
There are a lot of different environments though, separately from the above considerations
e.g. ssh in as purism (if allowed, not allowed on my phone)
ssh in as “another user”
(system or user) cron job as purism
(system or user) cron job as “another user”
service?
autostart?
The ssh was really just for testing. What I need is for it to work in some kind of environment like cron i.e. runs periodically in the background, makes a test of some kind, and conditionally outputs a sound file. (My application here was indeed a battery charge level warning but the scope for extending that to other things is obvious, if it worked at all.)
And, yeah, I’m not sure what would happen if the background script outputs a sound file while I am on the phone. Good problem to have? 
I need to spend some time to work through the options and document the results systematically.
Oops… I see why mine isn’t working. Somehow in making copies across different devices, I ended up with “battery_BAT0” in the L5 script, when it should be battery_max170xx_battery, as in my OP.
I’m charging right now, but I’ll test it later to see if it’s working correctly.
Yes, it is now working again for me.
admin) to running the script as purism. It just seemed as if the former approach, which worked fine under amber, was likely to be more troublesome.admin wasn’t working anyway because admin was not a member of the audio group. Easily fixed of course.XDG_RUNTIME_DIR to run this successfully.For the record, I am using the system crontab file whereas you appear to be using the user crontab file.
What would be the correct entry to run it as system?