Then I’m guessing you’ll need to make a script that launches on boot, which you can create a Systemd unit for to accomplish and use bash’s watch to check for battery charge change.
Edit:
Combine this:
…with watch…
Welp that didn’t work, set it to every 300s and no sound had come out despite having reached 83% by the time I looked
well, Ithink:
first see whether this line even works/reports something accurate
or rather, this command:
acpi -b | grep -P -o '[0-9]+(?=%)'
If it does, debug further.
If it doesn’t:
make it work 
it doesn’t work for me, because the “acpi” command isn’t recognized …
Perhaps the script was just an example of the approach that can be taken?
Well it worked for me, checked the output against the reported battery percentage and it matched so I doubt that’s the issue at all, thanks anyways. I don’t usually use the shell since I can just programme what I want in C so long as I know what api to work with for it
if you are running the script every 300 seconds, perhaps the condition is never met
(it’s never equal - first it’s lower, on the next check it is already higher …)
if [[ $battery_level -eq $battery_limit ]]; then
use -gt instead, to catch the condition even though it is slightly overshot during the 5 minutes?
1 Like
Didn’t even notice that, I’ll try it then, but 1st is -ge (>=) supported at all?
yes, it is
… and the sound is a very subtle “ding”
Well I actually switched out the sound for the alarm, your tip did the trick though so I at least have a temporary solution until I get round to constructing a proper app that does it all by itself
Good!
I thought I mention the subtle sound, as it is so subtle that it may be missed …
But I do think this is already a proper solution - I’d spend no more time on it.
and credit to @Mirdarthos for it
… but you do like coding in C - a thing which I know next to nothing about 
The eventual solution you will create will have been more work intensive but equally as functional, I’d wager.
anyway
Have fun! 
I will, btw I AM having to modify the shell code a bit to stop it doing it more than once on the same instance of >= 80, for now I’m trying along the lines of reading the last state from file and then writing the current state and checking if the battery level is also above the last state
Edit:
This is the modified state for the peops who can’t be bothered to modify it for themselves:
#!/bin/bash
last_notified_file=./mybatsig_lastnotified.txt
battery_level=$(acpi -b | grep -P -o '[0-9]+(?=%)')
battery_limit=80
if test -f "$last_notified_file"; then
last_notified=$(echo < $last_notified_file)
else
last_notified=0
fi
echo $battery_limit > $last_notified_file
if [[ $battery_level -ge $battery_limit ]]; then
if [[ $battery_level -gt $last_notified ]]; then
notify-send "Battery level reached $battery_limit!"
paplay /usr/share/sounds/freedesktop/stereo/alarm-clock-elapsed.oga
fi
fi
… but the script will still be running every 5 minutes (or whatever interval you set it to run)
even as it is,
it’s hardly to cause an impact on the overall performance of the machine, though …
I didn’t even think of the laptop’s overall performance, I just wanted the notification to come as soon as possible so that if I’m in the middle of something time consuming (such as in the middle of a game’s boss fight) I still have time before it hits max to find a moment to switch off the power supply, having even that little delay could be the difference between 0 dmg to the battery and 0.0…X% dmg to the battery, I’d rather minimise that chance to the extreme since I don’t currently have a job to afford replacing the battery with
… just anecdotal:
Sony Vajo SVE14
my battery (the Laptop it came with) is at least 10 years old
battery is always in, and is almost always on main supply
63 Wh design capacity - it was already down to ~50 Wh when I got the machine ~2015
as of today it is 37 Wh (58%)
I very much doubt that I could have achieved very much of a difference had I done what you try to do (only charge it up to 80% and then cut the power and drain the battery … then charge it up again)
… MANY many more discharge/recharge cycles would have been the result
likely not exactly good for the longevity of the battery
plus the constant attention needed …
In my country I’m required to pay for a TV license (whether I want to or not, whether I use it or not)
~ 20 bucks (18+ Euro) per month
… a new battery every decade is insignificant in comparison to what I have to pay for garbage in a single year … unemployed or not …
I know what you mean but I’ve also seen what happens when you overcharge it, my neighbor before he died left his laptop on permanent charge also, He let all his friend take what they please via his will so I took his laptop to hopefully get it working proper again, opened it up to find the entire keyboard was ruined by the battery’s corrosion so it is better to make the effort than to assume the best, at least if the worst happens then you’ve already done what you could to avoid it.
I recommend you save any temporary file rather to /tmp, because /tmp is a tmpfs
tmpfs (short for Temporary File System) is a temporary file storage paradigm implemented in many Unix-like operating systems. It is intended to appear as a mounted file system, but data is stored in volatile memory instead of a persistent storage device. A similar construction is a RAM disk, which appears as a virtual disk drive and hosts a disk file system.
I’m aware of that, I simply forgot about it and frankly for a temporary solution I’m not too bothered by the persisting file for now, I can fix that when I finally get round to doing a proper app for it, thanks anyways
See if pacman or aur has xfce4-battery-plugin
It will allow you to run a command when battery reaches a certain level.
I run linux mint and synaptic has that plugin and maybe manjaro as well.
Well that solved a secondary issue I was having, getting an alarm to also play on low battery, doesn’t have the option for on high though so only half a solution. The headers included by the mentioned source file were a bust so now I’m looking into using
libupower-glib/upower.h
Which was already on my system, just having issues trying to compile with it, let alone actually use it, I’ll have to look into the docs more to find out what directories are expected to be in the include paths before I seriously try to do anything with it
This topic feels like reinventing the wheel.
A working solution already exist → and linked above
2 Likes
As stated I do NOT want to run multiple programs where 1 is more efficient and should’ve existed already, plus as I’m writing my own cross-platform library that should reverse the paradigm of “native 1st then other platforms” to “all platforms 1st then native extras” and I don’t mean JUST windows, linux & mac, I will need to learn how to do it in C anyways.
I also mean older hardware such as the playstation 1, I’m also aiming to do away with “apps” and encourage building as just libraries, with a launcher app to hook them, if you only need to build library “apps” then it’s just a stone’s throw away from loading in other library “apps” to utilise their functionality since the initialisation/termination functions will always be the same whatever the platform, there won’t be ABI issues either since I’m designing for directory based “apps”, not to say you can’t still design proper apps but why would you when you can just design it as a library to begin with and launch it with the same launcher that launches those kinds of libraries on every platform