Jump to content

Automatic suspend or shutdown on low battery


mikestp27

Recommended Posts

Hi, I'm using ARMBIAN Ubuntu 14.04.4 LTS 4.4.3-sunxi  on a Cubietruck board with a battery connected.    How do I setup the system to safely suspend, shutdown or hibernate when the battery power is low?  Thank you very much.

Link to comment
Share on other sites

hi ,

one solution is this:

 

schedule this script every 5,10 minutes

if you want mail alert need install heirloom mailx

touch /root/battery_check.sh
chmod +x /root/battery_check.sh

crontab -e

*/10 * * * * /root/battery_check.sh

prerequisite for mail alert

apt-get install heirloom-mailx

paste this in /root/check_battery.sh

#!/bin/bash

######################################################################################
#   SET MAIL NOTIFICATION
mail_from=mail@domain.it
smtp_server=smtp.server.it
smtp_port=587
auth_username=mail@domain.it
auth_passw=12345678
mail_to=mail2@domain.it

######################################################################################
#
# Battery info
#


/usr/sbin/i2cset -y -f 0 0x34 0x82 0xC3
# read power OPERATING MODE register @01h
POWER_OP_MODE=$(/usr/sbin/i2cget -y -f 0 0x34 0x01)
BAT_EXIST=$(($(($POWER_OP_MODE&0x20))/32))  # divide by 32 is like shifting rigth 5 times
CHARG_IND=$(($(($POWER_OP_MODE&0x40))/64))  # divide by 64 is like shifting rigth 6 times

########################################################################################
#read battery voltage   79h, 78h        0 mV -> 000h,   1.1 mV/bit      FFFh -> 4.5045 V
BAT_VOLT_LSB=$(/usr/sbin/i2cget -y -f 0 0x34 0x79)
BAT_VOLT_MSB=$(/usr/sbin/i2cget -y -f 0 0x34 0x78)

BAT_BIN=$(( $(($BAT_VOLT_MSB << 4)) | $(($(($BAT_VOLT_LSB & 0xF0)) >> 4)) ))
BAT_VOLT=$(echo "($BAT_BIN*1.1)"|bc)

# store maximum battery voltage to compare to
if [ -f "/etc/default/battery" ]; then
        source "/etc/default/battery"
else
        echo "MAX=$BAT_VOLT" > /etc/default/battery
	echo "MIN=3484" >> /etc/default/battery
fi

# integer is enough, cut down the decimals
MAX=${MAX%.*}
BAT_VOLT=${BAT_VOLT%.*}

# mainline kernel shows battery existence even if not exists. this is walkaround 
if [ "$BAT_VOLT" -ge "3200" ]; then


# if we have new max value, alter defaults
if [ "$BAT_VOLT" -gt "$MAX" ]; then 
MAX=$BAT_VOLT
sed -e 's/MAX=.*/MAX='$BAT_VOLT'/g' -i /etc/default/battery
fi

# if we have new min value, alter defaults
if [ "$BAT_VOLT" -lt "$MIN" ]; then
MIN=$BAT_VOLT
sed -e 's/MIN=.*/MIN='$BAT_VOLT'/g' -i /etc/default/battery
fi

# calculate percentage
percent=$(echo "($BAT_VOLT-$MIN)*100/($MAX-$MIN)"|bc)
fi

# define output format
output="Load : $percent%"


if [ "$percent" -gt 20 ]; then 
#echo $percent
exit
fi

# if we have new min value, alter defaults
if [ "$percent" -lt 20 ]; then
#echo $percent
# Alert shutdown mail
mailx -v -r "$mail_from" -s "Cubietruck shutdown" -S smtp="$smtp_server:$smtp_port" -S smtp-use-starttls -S smtp-auth=login -S smtp-auth-user="$auth_username" -S smtp-auth-password=$auth_passw -S ssl-verify=ignore $mail_to
poweroff
fi

Link to comment
Share on other sites

Good morning, 

I'm using the latest vanilla kernel.  

I tested @luca219 script and it's not working...

1. The email is sent properly but the poweroff does not work.  I initially thought the system was rebooting quickly but it's not the case.  The script is ran by root's crontab so it should be able to poweroff.   I edited the script to send a 2nd email after the poweroff and both emails are sent so the script has not crashed and the poweroff came back to the script.

2. Ignoring the poweroff issue for now, I went on and continued to another test... If I drain the battery to under 20%, the script sends an email every 10 minutes as per the cron; if I reconnect the power supply, I still get an email every 10 minutes until battery reaches 20%.  But the problem is the script would trigger a poweroff when the system would reboot when the power comes back.  In other words, the script needs to check if running on battery or power; if running on power, the script should not poweroff.

Thank you.

Link to comment
Share on other sites

I started to look at @Igor suggestion (http://forum.armbian.com/index.php/topic/611-wip-axp209-mainline-sysfs-interface/) and it would certainly be simpler and more portable than I2C commands... However, I discovered a discrepancy between the battery percentage calculated in the script above (@luca219's) and the percentage reported by /etc/update-motd.d/30-sysinfo (which uses @Igor's suggestions).   That puzzle me and I'm not sure which one is right...

Link to comment
Share on other sites

I discovered a discrepancy between the battery percentage calculated in the script above (@luca219's) and the percentage reported by /etc/update-motd.d/30-sysinfo (which uses @Igor's suggestions). That puzzle me and I'm not sure which one is right...

 

That's the problem with numbers, they're most often wrong and people start only to care about it if they get different numbers for the same thing ;)

 

If you read through the thread you cited you might understand what the values are for.

Link to comment
Share on other sites

hi,

the code to detect the battery load is the work of Igor (present in forum), I have only adapted to the  mikestp27

request.
if Igor suggests using the updated one is undoubtedly the most delicious way.

I use old Kernel , I can't test the operation of the new,  for the moment.

Link to comment
Share on other sites

the code to detect the battery load is the work of Igor (present in forum), I have only adapted to the  mikestp27

request.

 

I know. And that there are discrepancies shown might be the result of the motd approach sometimes not showing actual values but ones from the past.

 

I've been just amused by the usual way people deal with numbers. They're blindly trusted regardless of their meaning unless something seems to be totally wrong. As already written: there's an informative thread here in the forums to learn a bit about battery usage and capacity calculation.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines