Android can do it... how do we do it under Linux?

For Android (which is Linux at its base), you can turn off battery charging with the following commands:

adb shell dumpsys battery set ac 0; dumpsys battery set usb 0;

To turn it back on, you change the '0's to '1's.

How do we do the same under Linux?

In general, no. This can be hardware dependent, so you may be able to to do so depending on your machine.
You may be able to limit the charging threshold. But I know of no terminal command on Linux that can halt or restart charging.

How about a bash script that monitors battery SOC, then activates / deactivates a SmartPlug to turn the A/C to the computer on / off? Would that work?

If so, I'd have to figure out how to stop the computer from entering 'battery mode' (dim screen, etc.), but other than that...

Possibly, if the smart-plug is linux compliant - you may be able to do so.
Is the hardware on the Notebook computer broken, or unable to properly manage the battery?

Apparently NATACPI_ENABLE, TCACPI_ENABLE and TPSMAPI_ENABLE aren't available on this computer.

Because this computer is going to be always plugged-in, I wanted to limit SOC to 60% to extend battery lifespan.

Is it a Lenovo?

You may need to install:

sudo apt install tlp acpi-call-dkms

HP 17-cp1035cl

I already tried installing that. No joy.

Yes, this is where that Hardware compliant problem comes into play.
Does your hardware show having a file or directory in /sys/devices/platform/ directory?
If so, you may be able to quite easily set a Battery charging Threshold there.

I went through all the directories and files under /sys/devices/platform... there's no reference to the battery.

There is under /sys/module/battery/sys/bus/acpi/drivers/battery, but no mention of any charge limit.

I wonder... if I were to change /sys/bus/acpi/drivers/battery/PNP0C0A:00/power_supply/BAT0/charge_full_design to show a lower full charge, if the charger would stop charging when it hit that lower level? Right now it's 3592000.

Or the capacity_level file... right now it says Full.

Or the capacity file... right now it says 100.
Or is that overwritten by the battery management hardware?

Further reading can be found here - Just as an Example:

What you may prefer to do is set a file to limit charging capacity, rather than change a direct system file.
There are probably several different ways to go about achieving the effect. This is not something I have ever done, so I am limited in any helpfulness.

Actually, I'm not even sure how to change that file. I took ownership of it using chown, changed the permissions to read-write, then opened a root gedit, edited it and attempted to save. I get Unexpected error: Error writing to file: No such device.

Figuring that I had permission to save to that file under my account and group, I then did the same without root... same thing.

So I changed the owner and group back to root and the permissions back to read-only while I do research.

So how do I edit /sys/bus/acpi/drivers/battery/PNP0C0A:00/power_supply/BAT0/charge_full_design?

It's just a plain-text file with a single number in it (the battery capacity: 3592000). I'm betting that it compares the number in that file with the number in /sys/bus/acpi/drivers/battery/PNP0C0A:00/power_supply/BAT0/charge_full, then limits charging as the battery ages and the 'charge-full' number drops... so if I edit 'charge_full_design' to be lower, it'll think it's overcharged the battery and cut off charging.

I recommend against ever doing this.
Files in Root need to remain under Root ownership so that Root can access and utilize them.
Instead, elevate your user privileges to SuperUser (SUDO) in order to gain access to write to files in Root.

I tried that, still couldn't write to the file. That's why I tried taking ownership.

Ah... it appears to be a sym-link to somewhere else. Now to find that somewhere else.

These three paths go to the same place:



Makes sense and I probably would have tried the same, if for no other reason than to test if the file change works in principle.

But it was necessary to point out the flaw for the benefit of all readers: Root won't own the file when it needs to access it.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.