Battery Buddy support thread

Doesn’t seem to be general problem as it works for me on 10 III. Both current and charge level limiting.

1 Like

Is the service enabled in the settings page? If it’s disabled, the service can’t be started manually. This should be reflected in the UI better.

1 Like

It should. It refers to the startup of the service, I understand this as being the boot time startup.

Hello everyone!

The code refactoring is done, and I’ve also added initial support for Jolla C2. I’ve prepared a beta release in GitHub first to iron out any bugs. I’m sure there are some bugs left, but for the most part it should work identically with version 4.3.2, some logging and debug print differences aside.

If you find anything, please file a bug in the issue tracker, or just drop a message in this thread. Thank you :slight_smile:

(The service startup switch+button bug is still there, I’ll fix it to the next release.)

3 Likes

Ahoi @direc85:
Very useful app (on supported devices)!
Concerning Volla Quintus:
Battery Buddy works partially on a Volla Quintus: Battery level reading in charging and discharging state works (monitoring and logging). But when I set the charging limit at e.g 80%, thecdevice does not stop charging at 80%, as supposed, but charges full to 100%. Maybe a problem with the permission deamon? Is there anything a normal user and non coder can try to do, to enable charging limits, e.g. stop charging at 80% in this Volla Quintus device?

Still testing on C2 but no issues so far. Thx!

1 Like

Most of what BB does is reading and writing files in sysfs.

You can explore the /sys/class/power_supply tree of your Quintus and see which files control this. (If any, not all devices/kernels/battery drivers support this!)

If you find the right ones, check their permissions, and carefully! try writing to them.

If you find the ones which make it work, report them here or at the github repo.

For reference, you can see the candidates for these files BB tries to use here (the entries in the list are tried in order):

https://raw.githubusercontent.com/direc85/harbour-batterybuddy/v4.4.0-0%2Bbeta1/common/batterybase.h

(Also, here’s how it mangles permissions on the files: https://raw.githubusercontent.com/direc85/harbour-batterybuddy/refs/tags/v4.4.0-0%2Bbeta1/application/service/set-write-permissions.sh)

5 Likes

Thanks Nephros, that is really helpful to start. I will have a look by time and report back!

1 Like

4.4.0 beta2 is now available. It’s mainly a project cleanup release, but also fixes some dependency mishaps. Just barely worth releasing as a beta2 :slight_smile:

I realized (remembered) only after making the release that there are pull requests too… I’ll check them soon!

8 Likes

First, thanks for the app!
I thought of a charging control feature that would be useful, at least for me:
Have a user defined time range- ex, a ‘Night Mode’ between 9PM and 7AM.
The purpose is to reach the Pause Charging% (ex: 80%) at the end of the range (7AM) .
For that, it could lower the charging current, start charging before reaching the Resume % etc. I’d say it should respect the Maximum Charging Current threshold.

2 Likes

I have now noticed that three times phone hasn’t started charging when charger is attached. I reported this first here as I noticed this after the update: [Release notes] Tampella 5.0.0.73 - Early Access - #183 by CLMA31

But as mentioned there, when I manually stopped battery buddy background services the charging started immediately. So could this be bug in battery buddy? Anyone else expressing this?

Hi Matti,

as thanks to @rinigus and @vlagged we now have a very mature community port of Sailfish OS for the Xperia 1 and 5 Mark IV (Nagara platform), would it be possible for you to include Nagara specific charging control files in Battery Buddy? Please, see this post or the information below:

The Xperia 1 and 5 IV specific files are as follows:

  • the charger control file is /sys/class/qcom-battery/charging_enabled (1 or 0)
  • the charging current limitation takes two files: /sys/class/qcom-battery/restrict_cur (max charging current in microamps) and additionally one needs to write 1 to /sys/class/qcom-battery/restrict_chg in order to enable the limit. I used the set-write-permissions.sh script for that (i.e. echo 1 > /sys/class/qcom-battery/restrict_chg) so that it is re-enabled at every reboot as otherwise it gets reverted to 0
  • /sys/class/power_supply/usb/online holds information (0 or 1) whether USB charging takes place.
  • All other files are the same as on some other devices, so Battery Buddy already supports them.

It would be great if you could add it, so that 1 and 5 IV can be supported by Battery Buddy “out of the box” :slight_smile: For my own use, I’ve modified version 4.3.2-1 (which seemed to be the last release - i.e. non-beta - version) and I’ve been successfully using it on my 1 IV for almost a week now, enjoying 100% functionality of your app.

1 Like

Awsome - does the current restriction work for wireless charging too?

I don’t have a wireless charger so I couldn’t test it. Planning to buy one right now :slight_smile:

I cant get battery buddy to install on my new JP2026. Any advise?

Not without knowing more details.

Install direc85’s version from OpenRepos. I didn’t have to do anything else but zypper ref (or pkcon refresh) often helps.

Just says “Ongelma latauksessa” when trying to install. I have allowed the not-trusted applications. Which is the correct version? I tried both 4.3.2-1.armv and i486.

Well then you only have aarch64 left to try! :wink:

2 Likes

Argh. I’m such an idiot I missed the third one (facepalm) Thanks. Works perfect now :slight_smile: