I’ve played with different ways to install and run Home Assistant. At the moment my home instance is running as a virtual machine inside KVM hypervisor. The physical machine is a refurbished Dell Latitude E6230 running Ubuntu Desktop 22.04. Even though it will be running as a server, I installed the desktop edition for access to tools like Virtual Machine Manager. But there’s a downside to installing the desktop edition for server use: I did not want battery-saving features like suspend and sleep.
When I chose to use an old laptop like a server, I had thought its built-in battery would be useful in case of power failure. But I hadn’t tested that hypothesis until now. Roughly twenty minutes after I unplugged the laptop, it went to sleep. D’oh! The machine still reported 95% of battery capacity, but I couldn’t use that capacity as backup power.
The Ubuntu “Settings” user interface was disappointingly useless for this purpose, with no obvious ability to disable sleep when on battery power. Generally speaking, the revamped “Settings” of Ubuntu 22 has been cleaned up and now has fewer settings cluttering up all those menus. I could see this as a well-meaning effort to make Ubuntu less intimidating to beginners, but right now it’s annoying because I can’t do what I want. To the web search engines!
Looking for command-line tools to change Ubuntu power saving settings brought me to many pages with outdated information that no longer applied to Ubuntu 22. My path to success started with this forum thread on Linux.org. It pointed to this page on linux-tips.us. It has a lot of ads, but it also had applicable information:
systemd targets. The page listed four potentially applicable targets:
systemctl status” I could check which of those were triggered when my laptop went to sleep.
$ systemctl status suspend.target ○ suspend.target - Suspend Loaded: loaded (/lib/systemd/system/suspend.target; static) Active: inactive (dead) Docs: man:systemd.special(7) Jul 21 22:58:32 dellhost systemd: Reached target Suspend. Jul 21 22:58:32 dellhost systemd: Stopped target Suspend. $ systemctl status sleep.target ○ sleep.target Loaded: masked (Reason: Unit sleep.target is masked.) Active: inactive (dead) since Thu 2022-07-21 22:58:32 PDT; 11h ago Jul 21 22:54:41 dellhost systemd: Reached target Sleep. Jul 21 22:58:32 dellhost systemd: Stopped target Sleep. $ systemctl status hibernate.target ○ hibernate.target - System Hibernation Loaded: loaded (/lib/systemd/system/hibernate.target; static) Active: inactive (dead) Docs: man:systemd.special(7) $ systemctl status hybrid-sleep.target ○ hybrid-sleep.target - Hybrid Suspend+Hibernate Loaded: loaded (/lib/systemd/system/hybrid-sleep.target; static) Active: inactive (dead) Docs: man:systemd.special(7)
Looks like my laptop reached the “Sleep” then “Suspend” targets, so I’ll disable those two.
$ sudo systemctl mask sleep.target Created symlink /etc/systemd/system/sleep.target → /dev/null. $ sudo systemctl mask suspend.target Created symlink /etc/systemd/system/suspend.target → /dev/null.
After they were masked, the laptop was willing to use most of its battery capacity instead of just a tiny sliver. This should be good for several hours, but what happens after that? When the battery is almost empty, I want the computer to go into hibernation instead of dying unpredictably and possibly in a bad state. This is why I left
hibernation.target alone, but I wanted to do more for battery health. I didn’t want to drain the battery all the way to near-empty, and this thread on AskUbuntu led me to
/etc/UPower/UPower.conf which dictates what battery levels will trigger hibernation. I raised the levels so the battery shouldn’t be drained much past 15%.
# Defaults: # PercentageLow=20 # PercentageCritical=5 # PercentageAction=2 PercentageLow=25 PercentageCritical=20 PercentageAction=15
The UPower service needs to be restarted to pick up those changes.
$ sudo systemctl restart upower.service
Alas, that did not have the effect I hoped it would. Leaving the cord unplugged, the battery dropped straight past 15% and did not go into hibernation. The percentage dropped faster and faster as it went lower, too. Indication that the battery is not in great shape, or at least mismatched with what its management system thought it should be doing.
$ upower -i /org/freedesktop/UPower/devices/battery_BAT0 native-path: BAT0 vendor: DP-SDI56 model: DELL YJNKK18 serial: 1 power supply: yes updated: Fri 22 Jul 2022 03:31:00 PM PDT (9 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: discharging warning-level: action energy: 3.2079 Wh energy-empty: 0 Wh energy-full: 59.607 Wh energy-full-design: 57.72 Wh energy-rate: 10.1565 W voltage: 9.826 V charge-cycles: N/A time to empty: 19.0 minutes percentage: 5% capacity: 100% technology: lithium-ion icon-name: 'battery-caution-symbolic'
I kept it unplugged until it dropped to 2%, at which point the default
PercentageAction behavior of
PowerOff should have occurred. It did not, so I gave up on this round of testing and plugged the laptop back into its power cord. I’ll have to come back later to figure out why this didn’t work but, hey, at least this old thing was able to run 5 hours and 15 minutes on battery.
And finally: this laptop will be left plugged in most of the time, so it would be nice to limit charging to no more than 80% of capacity to reduce battery wear. I’m OK with 20% reduction in battery runtime. I’m mostly concerned about brief blinks of power of a few minutes. A power failure of 4 hours instead of 5 makes little difference. I have seen “battery charge limit” as an option in the BIOS settings of my newer Dell laptops, but not this old laptop. And unfortunately, it does not appear possible to accomplish this strictly in Ubuntu software without hardware support. That thread did describe an intriguing option, however: dig into the cable to pull out Dell power supply communication wire and hook it up to a switch. When that wire is connected, everything should work as it does today. But when disconnected, some Dell laptops will run on AC power but not charge its battery. I could rig up some sort of external hardware to keep battery level around 75-80%. That would also be a project for another day.