[4.5.0.16] [XA2] Charging Limits both ways = stop charging when high, don't start charging until low?

ohnonot · 14 February 2023 21:59

In the past I used Battery Buddy and I seem to remember that this worked:

stop charging at say 90%
don’t start charging again - even if I pull the USB cable and reconnect it - until the battery is depleted to, say, 25% or less

I almost never needed Nr. 2. though.

Now I updated to 4.5.0.16 which - I thought - integrates Battery Buddy into its UI settings. Unfortunately I only see a setting for the upper charge limit - I cannot tell the device to not start charging (again) until the battery is depleted somewhat.

I need to connect the device to my computer by USB cable all the time for development (flaky WLAN).

Things I tried:

I tried reinstalling BatteryBuddy and disabled SFOS ageing protection, but it does not seem to change anything - the phone starts charging as soon as I connect it to the computer, until it hits the upper limit.
Uninstalling BatteryBuddy I tried setting both upper and lower charging limits with mcetool (The UI settings reflect this), but the effect seems exactly as with BB.
I can manually disable charging completely with mcetool --set-charging-mode=disable. This works, but whenever I change that to “apply-thresholds” (through the UI or mcetool), the following happens:
- it does not start charging at first
- after I un/plug the cable it starts charging

I’m confused.

tuplasuhveli · 14 February 2023 22:58

I can reproduce this behaviour on my 10 III (4.5.0.16) and I believe your topic is related to this previous thread.@direc85 provides an answer there: this is expected behaviour.

I tried the suggestion to disable the control on either one of them and I chose to disable the control on the Sailfish side (“Charging mode: Normal”). I wasn’t able to successfully apply the lower threshold despite the effort, but maybe someone else has an idea, how to solve this.

ohnonot · 15 February 2023 00:30

Sorry I forgot to mention that I did see that post and that I disabled SFOS’ inbuilt protection when testing with BB. I edited my OP.

I also wonder why mcetool provides both:

--set-charging-enable-limit=<percent>
--set-charging-disable-limit=<percent>

While the UI seems to be providing only one (the upper limit = charging-disable-limit).

mcetool seems to provide the same functionality as BB, however either doesn’t work in this respect.

A first step to untangle this confusion would be to ask @direc85 how mcetool, SFOS builtin and BatteryBuddy relate to each other.
I hope paging him like @ this is enough.
FWIW, I believe that mcetool is the backend to the System settings UI, and BB works independent of both.

direc85 · 15 February 2023 07:11

I’ve used Battery Buddy with 4.5.0 and I haven’t had issues with the limits not working or device not charging. A few users now have issues, though.

Battery ageing protection only controls the upper limit. Battery Buddy controls both. I haven’t checked how SFOS controls the charging - if they control different files they could conflict and confuse each others’ logic.

Rule of thumb applies here: Battery Buddy is a third-party app, and if it causes issues, remove or disable it. You can disable the charger control in it, then it only acts as a monitoring/alerting app. It should then “perform” as if it wasn’t installed at all (save the permissions). If that is not the case, I’m very confused, too.

I’ll have a better look at this, during this week I hope.

ohnonot · 15 February 2023 14:37

Thanks for answering.
Can you tell me (point me to the relevant LOC) how BB applies the limits and modes?
Do you happen to know if SFOS does it the same way or not?

Currently I just wonder why charging isn’t automatically disabled until low threshold is reached, at all, regardless of which utility I use for it.

direc85 · 15 February 2023 16:47

github.com

direc85/harbour-batterybuddy/blob/master/service/src/battery.cpp#L243

      
        
                highNotifyTimer->stop();
                lowNotifyTimer->stop();
                healthNotifyTimer->stop();
            
            
    delete updateTimer;
                delete highNotifyTimer;
                delete lowNotifyTimer;
                delete healthNotifyTimer;
            }
            
            
void Battery::updateData()
            {
                if(chargeFile && chargeFile->open(QIODevice::ReadOnly)) {
                    nextCharge = chargeFile->readLine().trimmed().toInt();
                    if(nextCharge != charge) {
                        charge = nextCharge;
                        logM(QString("Battery: %1%").arg(charge));
                    }
                    chargeFile->close();
                }

ohnonot · 15 February 2023 21:05

Thanks again. So you don’t write to the files in /sys directly but use provided functions/classes/methods or whatever that’s called.
AFAICS one would have to figure out what QIODevice points to? That’s way beyond me.

I still wonder why I’m not seeing the desired behaviour with either BB or mcetool settings (it seems to me that mcetool should be capable of providing the same basic functionality as BB).

So, the fact that my phone does not respect the lower charging limit is independent of which utility I use - I think?

direc85 · 16 February 2023 09:53

The logic is in that function, and the files it uses are in the constructor (line 20). It uses the /sys/ files to read statuses and write to disable/enable charging.

What device are you using? I still haven’t been able to replicate this with X10III or XA2U…

ohnonot · 17 February 2023 13:40

I guess SFOS/BB/mcetool all use the same files under /sys, which makes sense since in my observations the behaviour is independent of the utility I use.

My device is Xperia XA2 - Dual SIM (H4113 iirc). No plus, no ultra.

I can see the control file for XA2 as mentioned here on my own system, but not the other 3 (as expected).

It is currently set to 1 with mcetool.

If BB has good logging I can install it again and see what it has to say when I reproduce the problem (so far I wasn’t able to see anything relevant in systemd’s journal).

direc85 · 17 February 2023 16:17

If it happens without BB, you can have it installed, just disable the charger control in settings.

As you have tweaked the mce, I suggest you undo the changes and try to reproduce the behavior then. The default behavior of BAP is to keep the charge at the limit, that’s best for the battery anyway.

The way BB does it makes the charge stay at ±1% at minimum, unless I implement the other control file use to essentially make the device run off the charger. I don’t think I’ll be doing that anytime soon though. And I still haven’t checkes how BAP controls the charger.

I have an XA2U and it can’t reproduce the behavior either.

direc85 · 17 February 2023 16:20

Wait. Do you want the device to reach 90% charge, then start depleting down to 25% no matter if you reconnect the USB cable, and only start charging at 25% or less is reached? That behavior isn’t supported, and is outside the scope of both BB and BAP.

ohnonot · 18 February 2023 15:20

Yes.
What’s the meaning of the lower limit then? I can’t figure it out.

What’s BAP?

ohnonot · 20 February 2023 19:44

Couldany body shed some light on this for me? I just don’t get it.

Why are there 2 thresholds when only one applies?

wetab73 · 20 February 2023 21:56

I too could swear that it used to work that way. But it does NOT anymore. No matter what the lower setting is, upon reconnecting the USB cable or charger it just starts recharging the battery. For example, if I have the lower limit set to 50% and I connect the charger while the battery level is 55%, in the past it wasn’t recharging the battery until its level dropped to 50%. Whereas now at 4.5.0.18 it starts recharging even if the battery level (55%) is higher than the lower limit (50%).

P.S. The new charging mode in SFOS settings is set to “Normal”…

P.S.2. I believe that the lower limit setting still does work when the phone remains connected after the upper limit is reached and charging ends. In such case, recharging indeed doesn’t restart until the lower limit is reached. But it certainly used to work for removing and reconnecting the cable, too.

wetab73 · 21 February 2023 07:13

A few hours later, it suddenly started respecting the lower limit. It was set in BB to 70% and the battery level was 73%. Disconnecting and reconnecting the USB cable wasn’t restarting the charging, despite multiple attempts. Then out of nowhere it stopped respecting the lower limit again - maybe it happened when I opened the laptop’s lid, i.e. woke it up, so the cable was no longer “charger only” but the phone showed the USB connection mode requester, where I selected the Developer mode…

Then the phone recharged to the upper limit (90%) and now it seems to be respecting the lower limit again, as disconnecting and reconnecting the USB cable again doesn’t restart charging while the battery is currently at 88%.

So, either the logic behind this is so complicated that it is beyond my understanding, or it is simply f***** up on 4.5.0.x

tuplasuhveli · 21 February 2023 12:05

Battery Ageing Protection, the SFOS built-in feature.

If I read @direc85’s post correctly, the lower limit applies only when the USB cable isn’t deattached after the charging has reached the upper limit. The observations @wetab73 made has made me doubt if this really is the case.

Anyhow, I’m a bit curious about this topic too, since the lower limit is called “resume charging limit” in BB and the BB settings page describes the Automatic charging control:

… and enables it [charging] again when the battery has depleted below the resuming percentage.

Maybe the wording could be altered to not cause confusion among users, if the lower limit can’t handle plugging the USB cable on and off?

direc85 · 21 February 2023 13:05

After hitting the upper limit, the charging turns off, and continues when either 1) lower limit is reached or 2) USB cable is reconnected.

I’m quite sure at some point the behavior was such that only 1) but not 2) would continue the charging, but that was a bug in my book, so I made disconnecting the USB cable to reset then the state - hence making either 1) or 2) work.

I hope this clarifies!

I’ll keep the documentation wording in mind too, I’ll soon get back to Battery Buddy improvements again!

wetab73 · 21 February 2023 19:30

So I must have had multiple visual hallucinations today…

wetab73 · 22 February 2023 06:49

OK, so I’ve taken a closer look at it and this is how it works for me:

the phone charges up to the Battery Buddy’s upper limit, charging stops, the battery starts discharging. Disconnecting and reconnecting the USB cable DOES NOT restart charging.
BUT if I now stop and start the Battery Buddy service (which I guess resets some of Battery Buddy’s internal states/values), and then reconnect the cable, charging restarts.

So I would say that it entirely depends on Battery Buddy.

ohnonot · 27 February 2023 12:50

That was not my experience.
For me, the charging always resumes whenever the charger is re-connected, independent of BB.
It can, however, be force-disabled with mcetool.

I did since read up on the topic and realised that

I was confused about the term “charging cycles”, but apparently this is a mostly meaningless approximation - instead of “more charging cycles” with proper charging behavior, one should simply say “increased battery life”.
Li-Ion batteries work in a way that small charging “cycles” are not harmful - what harms the battery is
- too strong charging current/voltage (heat)
- getting too close toeither 0% or 100%
- staying at low percentages for too long

Considering all this, having the battery slow-charge at the PC while USB debugging is not a problem.

It is not possible to change (slightly decrease) the charging voltage on SFOS devices, presume? Or even to find out what it is?