Battery charge limit stops working when set to unsupported value with no feedback to user

[jbiniek]

I noticed that G-Helper will disable battery charge limit when set to anything other than 80% (which is I assume the only value supported by my ProArt P16). This is very unintuitive behaviour, which led me to abandon G-Helper initially because I thought charge limiting just didn't work with it.
It would be very helpful if there was some - any - feedback in the UI when attempting to set an unsupported value. Or even just a general warning/comment in the battery limit area, that only certain limit values are supported on certain models and that it won't work otherwise. This would save a lot of confusion as I suspect I'm not the only one who didn't know how this particular tech worked.

[seerge]

@jbiniek hello,

Actually I was running a questionnaire about this . And for models that people reported - app restricts UI options only to supported levels.

What options do work for you ? Usually it's either 60-80 only or anything working.

[jbiniek]

Thanks! My suggestion was to add a "catch all" solution that would (at the very least) warn users about the limits possibly not working at certain settings. Something like "IF known model THEN restrict UI, ELSE display "Unknown model! Battery limit settings depend on your hardware so please check that your chosen value is working.".

This sort of thing. This is because most people will not know that battery limits have to be supported at hardware level and will blame G-Helper (as did I) if the limits don't work as expected.

[seerge]

@jbiniek there is no feedback from firmware if limit is supported or not. That's why I just manually add models that don't support "any" limit (and only 60-80 range).

Whole thing is very basic. There is a special endpoint exposed by Asus driver, and apps can set a value there. Rest is up to firmware how to handle it :)

[jbiniek]

Sure, it is quite simple but the vast majority of users will not know it. I work in IT and didn't know about it. So this is just a suggestion to make the situation clear to users, rather than letting them blissfully set an unsupported value that will quietly break the limiter (i.e with no feedback from G-Helper).