One cycle is a 100% recharge, i.e. in case of a 4500 mAh battery it means feeding it with 4500 mAh. But not necessarily at once, it can be done in parts. If you recharge by 50% (2250 mAh) then it takes doing it twice for the cycle counter to increase by 1 cycle. In case of recharging by 20% (900 mAh) it takes doing it five times for the cycle counter to increase by 1, and so on. Any combinations are possible (e.g. 20% + 40% + 17% + 23%). It simply counts and remembers the mAh’s it gets from the charger and increases the cycle counter by one cycle only when that value sums up to 100% of the battery capacity. At this point it increases the cycle counter and then it starts counting mAh’s anew. It’s very simple and there’s absolutely nothing mysterious about it…
Thanks for the Explanation.
It does make sense.
Works fine on Xperia 10 III, thanks.
It does not work properly on Gemini PDA, at least according to what is visible on the screen
My findings
- current is still 0,
- the connected charger is not signalled (“no)”,
- temperature not displayed at all (on the home screen shows “?”),
- state is still “charging” even if the charger is not connected,
- charging does not stop when the set value is reached,
- does not signal discharge below the set value.
Battery Buddy stopped showing battery health on my 10 III. Now it always reports ‘Unknown’. I’m not sure when it happened, probably after the last update…
EDIT: Oops, it turns out that it wasn’t the latest version. Updating from 4.2.3-1 to 4.2.5-1 fixed it.
Yeah, there were a few mistakes, so I had to make a few releases more 
Worth considering for future versions of Battery Buddy is a different approach to battery saving that e.g. iOS uses. Battery is always charged to 100%, but the current is controlled so that charging ends at the desired time, e.g. very shortly before the user usually wakes up. The program calculates how much time is left until the desired hour and reduces the current automatically so that charging is slow enough to reach 100% only at that time. Of course, this takes monitoring the current that the device consumes in order to increase or decrease the input current so that the RESULTING current (delivered - consumed) equals what’s needed to get the required speed of charging…
Of course in iOS it is quite sophisticated, including learning of user’s habits so that it can be as automatic as possible, but I would love it even in a much simpler form, e.g. where I manually set the destination time and the program would modulate the current / charging speed so that charging reaches 100% at the chosen time (of course, within available current ranges).
This way when I wake up, or when I leave home, I would always have 100% of battery freshly charged, whereas now charging usually ends much sooner and the battery manages to discharge quite noticeably before I even touch it… I guess it would be much more useful, and much more practical when it comes to battery saving too, if such a function allowed me to finish charging as LATE as possible, as this way I would then end the day with MORE power left in the battery, quite possibly enough not to charge it until the next day. And that would be a true battery saving.
@direc85 I’ve just noticed that the Start button to manually start the service depends on the state of the “Start background service at startup” setting on the Settings page. If the setting to automatically start the service at boot is disabled, the “Start” button doesn’t work (even though it looks like an active button and is ‘clickable’ but it has no effect). So in order to manually start the service one has to temporarily enable that setting.
Another thing that I’ve been forgetting to report for a long time is a small glitch in Polish translation: on the main page both “State” and “Health” are translated in Polish as “Stan” (so there are two rows called “Stan”). I’d suggest to change it so that “State” is translated as “Status” and “Health” is either just “Stan” as it is now, or even better “Stan baterii”.
And while we’re at translation, “Maximum Charge Current” is not yet translated. Its Polish translation is: “Maksymalny prąd ładowania”. It would be also great if “Start background service at startup” could be changed (in order to avoid the “uruchom” word being repeated) from “Uruchom proces w tle podczas uruchomienia” to “Uruchom proces w tle podczas startu urządzenia”.
Thank you!
There’s now a new Battery Buddy release available, with a patch release too, to be exact. Battery Buddy 4.3.0 now supports PineTab Pro due to the work done by @nephros! 4.3.1 updates Polish translation as suggested by @wetab73. The source code repository is now up-to-date again (whoops).
I couldn’t replicate the behavior of the start button you described, so debugging that is quite hard… Does someone else have the problem? The start/stop buttons should be independent of the auto-start status, and if they are not, it’s a bug indeed.
I’m not sure what I did, but I guess it took either closing and reopening the application after switching that setting off, or rebooting the device with that setting switched off and then opening the application. Either way, now it is persistent, i.e. the Start button only works if that setting is enabled. Also after updating to 4.3.0.
Thank you for updating the translation! Just one remark, can you please also change the “State” string (currently translated as “Stan”) to “Status”?
Updated to version 4.3.1-1 and in addition to the aforementioned problem with the Start button now also the Max charging current setting stopped working. Despite setting it to e.g. 500 mA, the charging current is still 1400 mA. It used to work OK in previous versions. Actually, I’m not sure if anything works but the GUI. What is the name of the background service so that I can check if it is running at all?
Edit: I downgraded to version 4.2.5-1 and now Max charging current setting works OK again. So there must be something wrong with it in the latest version(s). Sadly, the Start button still only works when the “Start background service at startup” setting is enabled.
It looks like versions 4.3.x are broken indeed for some reason… I had the charge control set in the operating system too, that’s why I didn’t notice it at first. I’ll have a closer look, thanks for the reporting.
The bug was caused by a single missing comma, so it was an easy fix, but hard to spot…
Version 4.3.2-1 has now been released with the fix!
Thank you! The max charging current limit now works OK again.
As for the Start button, please note that it is unable to start the service while the “Start background service at startup” setting is disabled because disabling that setting makes the service unloaded/masked and it can’t be started without loading / unmasking it first.
So it takes changing the onClicked part of the Start button from
onClicked: batteryService.startService()
to something like
onClicked: { batteryService.enableService(); batteryService.startService() }
so that the service first gets unmasked/loaded and only then it is able to start. Or else, systemctl-user status harbour-batterybuddy.service returns: Loaded: masked and Active: failed and that’s why the Start button can’t start it.
The above is obviously just a rough example and it needs some further polish - the batteryService.startService() should be executed only after getting "loaded" state from batteryService.serviceMasked first, or else it happens too early, before the service gets loaded and it takes tapping the Start button twice…
It will also take some changes to handle the state of the service upon reboot, because if the Start button enables and starts the service this way, the service will get automatically restarted upon reboot, even if the “Start background service at startup” setting is disabled (it’ll get automatically re-enabled, too, because it gets its state from checking the state of batteryService.serviceMasked and shows the enabled state if it is “loaded”… kind of closed circle).
Sorry to be such a PITA regarding this, but it is 100% reproducible on both my 10 III and XA2U, so it should be reproducible for you, too… And, as I tried (maybe not very clearly) to describe above, it actually cannot work because disabling the “Start background service at startup” option MASKS the service, so it cannot be started until it gets unmasked (which can be done only by re-enabling the “Start background service at startup” option). The Start button does not attempt to unmask the service first, it just tries to start it, which obviously fails if the service was put into the masked state by disabling the “Start background service at startup” option.
Can you please re-check it, by simply tapping “Stop”, then disabling the “Start background service at startup” option, and then tapping “Start”? The service (which is in masked state) will fail to start. The state of the service in each of those steps can be verified using systemctl-user status harbour-batterybuddy.service…
Maybe switching off the “Start background service at startup” option should just disable the service rather than mask it? A disabled service won’t be started at boot anyway, but it could be started using the Start button. Whereas a masked service needs to be unmasked before it can be started.
I like to report that the “Maximum Charge Current” works on the XZ2 Compact Tama-Port. But the String isn´t translated to German. (I can do that if you provide a Link to translation Network).
But charging shows an negative Current (like -522mA) and discharging a postitive(e.g. 522mA).
And the i have some Questions about the Section “Intervall bei hoher/niedriger Ladung” (Intervall at high/low Charging), are these Time-Values for the “Battery is charged/empty” Notification?
Maybe this Section can be ordered a bit more because its a litte bit confusing for me.
And maybe you can add to the Time Values a “Never” option.
Another Idea ist to Add Battery Wear Leveling (aka. Useable Capacity) from sys/class/power_supply/battery/capacity
Maybe under Temperature on main-page, something like:
Wear Level: 16%
Hi
if i want get battery buddy on a port, what would i need to do ?
is there a cookbook what to look for, what to test before ?
i have installed bb on gs290 but it does not do anything.
Thanks !
Yes! I experienced the same behaviour on a Sony XA2 with SFOS 4.5.0.18 and Battery Buddy 4.3.2-1.
Thank you for confirming it because I was starting to feel really strange seeing how no one else has this. Especially that it just can’t work because the Start button simply can’t start a masked service without unmasking it first…
-
figure out which files exist in
/sys/class/power-supply, and what they do. -
Clone BB, and add the control file paths at the appropriate sections in the code. Note there are two implementations, one for the daemon, and one for the app/ui.
-
Compile, test, tune.
-
Submit PR.
I recently did some work for the Pinetab, maybe the changes can serve as an example:
Parts 1 (and 3) can be very easy or a bit finnicky, depending on kernel driver featurefullness and messy-sity.
OTOH unless there’somerhing weird, 2 is usually all you have to do to make BB do its thing.
Thanks for raising that! There is indeed no “guide” on how to approach adding support to a new device. Pretty much what @nephros said, poke around the proc files, and when you find the correct file, add it to the list
I’ll try to write a short guide-ish for reference at some point.
@wetab73 I don’t have it on my test devices, but I’ll have a deeper look at this. I don’t have time this week, though.
@fingus Great, I’ll add the device to the Openrepos page! About the translation, there’s no translation service set up. You can get the .ts file in the repo, fix it, and paste the fixes here on the forum - if you don’t want to fork, translate and make a pull request. You don’t need SFDK for that, a text editor will do, or you could install Qt Linguist separately and use that