Guide to charge limiting your Fairphone 5
-
I AM NOT RESPONSIBLE FOR ANY DAMAGE WHATSOEVER TO THE EXTENT LAW PERMITS.
EDIT: there is a edge case that lets the battery continue charging it seems easy to fix so I'll do so tomorrow, for now just use slow chargers. (or make sure to unplug/replug the phone after it stops charging from there it will work fine)
I'll start by saying I have no idea if this works for Focal but I haven't tried so it may work.
also this is a proof of concept you may want to refine this by using a udev rule or whatever else this is just how I got it working the first time so its a known good.essentially there is something called user_fcc my take is that the fcc part is "full charge capacity" you can essentially tell the device that it actually has a smaller/bigger battery with this, I did tests on this however and either its using different units then charge_full (which is how you get the battery capacity) or its something else entirely, the point is that if set to 0 battery stops charging if set to big number like 10^6 battery charges again.
so... heres my setup I did for the proof of concept.
first start by running:
sudo mount -o remount,rw /this is to remount read-only root as read/write.
make a file and name it charge-control.sh and put it in the /usr/bin directory (
/usr/bin/charge-control.sh)
change THRESHOLD to whatever percent you want to stop charging at, I put it on 80%#!/usr/bin/env bash # Path to capacity file (adjust if needed) CAP_FILE="/sys/class/power_supply/battery/capacity" UFCC_FILE="/sys/class/power_supply/battery/user_fcc" FULL_CAP_FILE="/sys/class/power_supply/battery/charge_full" # Threshold to compare against (integer 0-100) THRESHOLD=80 # Commands to run ON_GE="echo 0 > ${UFCC_FILE}" #echo Battery >= threshold: do X here ON_LT="echo `cat ${FULL_CAP_FILE}` > ${UFCC_FILE}" #echo Battery < threshold: do Y here # Trim whitespace and ensure integer capacity=$(tr -d ' \t\n\r' < "$CAP_FILE") if ! [[ $capacity =~ ^[0-9]+$ ]]; then echo "Error: capacity value is not an integer: '$capacity'" >&2 exit 3 fi # Compare as integers if (( capacity >= THRESHOLD )); then eval "$ON_GE" else eval "$ON_LT" fi exit 0make sure you set executable permissions
sudo chmod +x /usr/bin/charge-control.shnow we make a system service to start this script, make a file called charge-control.service at /etc/systemd/system (
/etc/systemd/system/charge-control.service)
and put this into it[Unit] Description=Battery charge control script [Service] Type=oneshot ExecStart=/usr/bin/charge_control.sh User=rootnow we create a timer to run this every minute because we want it to enable/disable battery charging without us running the service manually.
so create a file named charge-control.timer in the same directory (/etc/systemd/system/charge-control.timer)
and put this into it[Unit] Description=Run charge_control every 1 minute [Timer] OnBootSec=1min OnUnitActiveSec=1min Persistent=false [Install] WantedBy=timers.targetthen enable the timer by running these commands:
sudo systemctl daemon-reload sudo systemctl enable --now charge_control.timeryou may also check that it is working with these commands if you want
sudo systemctl status charge_control.timer sudo systemctl list-timers --all | grep charge_control sudo journalctl -u charge_control.servicehope this helps y'all manage you're battery health better.
-
thanks, may I ask why you are remounting the root fs r/w ? It's possible to create a systemd unit without it.
-
@gpatel-fr don't want the bash script in the user directory.
this is because I mess with the user directory a lot, I didn't change it for the guide because this is a proof of concept and if I have a known good I will use it.I opened an Issue on this for indicator-upower fork, paulcarroty (the developer) is aware.
and I am mostly counting on him to make this into something useful because he already has an app for it. -
I have looked at the kernel sources, the 'user_fcc' is a limit value for the charging current (in micro amperes). If you set it at 0, well, current_now goes to 0 (logical) and the battery charging indicator disappears. If you set it to infinity, well, the result is unclear to me. It would seem logical that the maximum amount that can be tolerated by the battery is set if user_fcc is higher.
Since the user_fcc value is aimed at setting an artificial low value when people are connecting a high powered charged (fast charger), I'd be wary of setting a very high value myself. It could work or maybe have unfortunate consequences. Setting it to 0 seems safe though. -
Interesting, this general approach should work (at least extremely similar if not exactly the same) on most devices, as this is very close to how I manage charge level on Arch on my thinkpad laptop. The exact sysfs path is different, (it's got BAT0 in there somewhere, iirc), but the fact that it's THAT close between an AMD64 machine and the fairphone means it may be scriptable to search and locate the appropriate sysfs files on multiple devices.
This sounds like something that could be integrated into the Lorimi settings UI pretty easily as well, i'll have to see about trying to write a patch for that, get my hands dirty etc.
-
@gpatel-fr thanks a lot! after classes I'll make it safe by reading the maximum first from wherever thats stored.
EDIT: at least on FP5 it seems to draw the same amount if I set it to a large value then if I restart (resets it) so FP5 should be safe currently, again will make it safe though I do not like to trust developers edge case fallbacks to not blow up my phone.
-
@TheTrench said in Guide to charge limiting your Fairphone 5:
ld work (at least extremely similar if not exactly the same) on most devices, as this is very close to how I manage charge level on Arch on my thinkpad laptop. The exact sysfs path is different, (it's got BAT0 in the
i'd need to do some testing yes, but this could be implemented as a sort of universal way to charge limit UT devices, if its that wide-spread I might just add this feature in lomiri system settings under battery because this has actually come up during a devsync.
-
@ChromiumOS-Guy I'm pretty sure it is, I think that it might even vary more by kernel version than device, meaning that you may want to switch on kernel version before device information, if you even need to check different locations. I would expect devices like the PinePhone to possibly be quite different since they don't use Hallium, iirc, but even thats a guess based on my experiences with the sysfs on various laptops.
I believe the kernel docs specify where to look generally, so 4.19 kernels should be (somewhat) consistent. (however most of my knowledge is based on the 6.1, 6.6, and 6.12 LTS kernels, take my recollections with a grain of salt)
That said, this is if you're accessing this sort of stuff through the sysfs, instead of using direct system calls, that may be rather different for all I know.
-
oh, btw, theres an existing systemd service I use on Arch and Debian to manage this nowadays, might be worth examining if it already works for the most part and forking that if necessary.
-
@ChromiumOS-Guy said in Guide to charge limiting your Fairphone 5:
on FP5 it seems to draw the same amount if I set it to a large value then if I restart
well, my main concern is what could happen for people following your advice with a more powerful (fast) charger.
If I understand correctly, the kernel limits to 6 amperes whatever, from kernel-fairphone-qcm6490/drivers/power/supply/qti_battery_charger.c;#ifdef CHARGE_MODE_FCC_SUPPORT
#define SLOW_MODE_FCC 1000000 // 2A
#define NORMAL_MODE_FCC 6000000 // 6A
static int battery_psy_set_charge_current_by_chgmode(struct battery_chg_dev *bcdev, int val)
{
int rc = 0;
u32 fcc_ua = ((val == SLOW_MODE_FCC) ? SLOW_MODE_FCC : NORMAL_MODE_FCC);
rc = write_property_id(bcdev, &bcdev->psy_list[PSY_TYPE_BATTERY], BATT_CHGMODE_FCC, fcc_ua);I don't know if the FP5 battery can support 6 amps without problems.
If I would use your system, I'd try to keep safe and set user_fcc to 1000000 (notice how the comment seems wrong, how can 1000000 mean 2 amp and 6000000 6 amp ?)
Re: different kernels, well, if I understand correctly, if the battery driver supports it, you'll find the appropriate values in the /sys/class/power_supply/ that are referred everywhere on the web: charge_control_start_threshold and charge_control_end_threshold, there should be no need for a script that will wake up the Cpu every minute (hardly a good thing to save power).
It don't concern FP5 (although the kernel is recent enough... I wonder if the kernel in Android 14 has a more recent driver that supports this feature or if there is some script to support it, but what's sure is that control up to 80% charge is supported on Android and FP5).