Battery Level Trigger Slider

[piz]

Hi,

Please add a numeric display (or even a numeric entry field) corresponding to the slider for the battery level setting in the Battery Level trigger. It would be better than having to count those nanosteps on the slider to set a specific level.

Thanks!

[Desmanto]

+1 for this. Additional request is to add the support of global variable here, especially with nested map. So I can use {global_battery["battery_saver_level"]}

[Pepy]

Hi,

Please add a numeric display (or even a numeric entry field) corresponding to the slider for the battery level setting in the Battery Level trigger. It would be better than having to count those nanosteps on the slider to set a specific level.

Thanks!

Yes, this should definitely be a thing, not just for the trigger but for the condition as well. This will make it much less of a hassle to select a specific value.

+1 for this. Additional request is to add the support of global variable here, especially with nested map. So I can use {global_battery["battery_saver_level"]}

Why the need to save the battery saver trigger level as a global variable when you can just retrieve from the value of the setting low_power_trigger_level using the Init Variable Set System Settings action?

[Desmanto]

@Pepy : The glovar used so we can determine our own battery level to check. Example at my previous phone, doing TWRP backup can cost 10-15% battery. To make it safe, I use 3x of the limit, at 50%. But at my current phone, it takes only 2-4%. I can use much lower limit, at 10%; but of course I set to higher, 30%. This way, the flow ensure my phone has enough battery before performing the backup.

We can't use other variable in trigger except glovar, since it is the starting point of the flow.

[Pepy]

@Desmantos
Doesn't the Battery Level trigger/condition already provide you with the current battery level? In the example you mentioned, if the flow checks that your battery level is high enough before performing a backup in TWRP, can you not use this battery level provided by the element? Why is a global variable necessary for something like this?
Also, I'm curious as to how you would even perform a backup via TWRP in a flow in the first place since as far as I know, flows cannot run while the service is not active such as when the device is powered off.

[Desmanto]

{battery_level} only provided after the flow is executing. if we put {battery_level} at the trigger, it won't work, as it is not glovar.

Sorry, battey saver level and TWRP flow actually are different, I shouldn't give the examples to compare them. Let just imagine another situation, where we work for normal and overtime. During normal, we set the battey saver will trigger after 30%. But if we work overtime, we want it triggered at 50% (so we can use the phone longer). It is impossible we change the flow everytime we have normal time and overtime. So better put variable to it and use another flow to change the variable as needed (triggered based on calendar or other things).

For TWRP, yes, the condition is actually checked after the flow executed, so yeah, I give wrong example, my bad. TWRP support openrecovery script. My flow will check if the battery level is enough, then it will write the script in the /cache/recovery, reboot to TWRP. After booting to TWRP, it will check if the openrecovery script exists. If yes, execute it. My script include reboot after the backup finish, so it will automatically reboot when finish, showing the result of the backup. Today, sunday, is the scheduled time that the flow will be triggered.

[Pepy]

{battery_level} only provided after the flow is executing. if we put {battery_level} at the trigger, it won't work, as it is not glovar.

I finally understand what you mean by that.

Sorry, battey saver level and TWRP flow actually are different, I shouldn't give the examples to compare them. Let just imagine another situation, where we work for normal and overtime. During normal, we set the battey saver will trigger after 30%. But if we work overtime, we want it triggered at 50% (so we can use the phone longer). It is impossible we change the flow everytime we have normal time and overtime. So better put variable to it and use another flow to change the variable as needed (triggered based on calendar or other things).

So you're saying you have one flow for setting or updating the global variable and another that includes the code to make TWRP perform a backup?
As for the example, wouldn't it be better to have a map variable instead to store the various percentages (eg. 20%, 50%, etc.) at which you want Battery Saver mode to trigger? This is what I would do, for example, rather than have a separate flow for updating the variable's value depending on certain conditions:

Code: Select all

global_battery_saver_trigger_level = newMapFromValues("casual", 20, "work", 50, "pre-backup", 30);

For TWRP, yes, the condition is actually checked after the flow executed, so yeah, I give wrong example, my bad.

Nah, it makes sense to me now why you would check the level within the trigger; I just didn't quite understand why you would want to store the trigger level for Battery Saver mode in a global variable when you can retrieve it via the Init Variable System Setting action.

TWRP support openrecovery script. My flow will check if the battery level is enough, then it will write the script in the /cache/recovery, reboot to TWRP. After booting to TWRP, it will check if the openrecovery script exists. If yes, execute it. My script include reboot after the backup finish, so it will automatically reboot when finish, showing the result of the backup. Today, sunday, is the scheduled time that the flow will be triggered.

I've been completely unaware of TWRP having this functionality so thank you for telling me this! I've found the guide for the available commands and will be looking into this soon as I've been thinking of creating a flow that would automatically download the necessary files and reboot to TWRP to install/flash the ROM update, GApps and Magisk (to retain root) zip files when I get a notification for a new update

However, I am unsure about what you mean by "showing the result of the backup". Are you saying that somewhere in the script or flow, you somehow store information on the state of the backup (whether it was successful or not)?

[Desmanto]

So you're saying you have one flow for setting or updating the global variable and another that includes the code to make TWRP perform a backup?
As for the example, wouldn't it be better to have a map variable instead to store the various percentages (eg. 20%, 50%, etc.) at which you want Battery Saver mode to trigger? This is what I would do, rather than have yet another flow for updating the variable's value depending on certain conditions:

Code: Select all

global_battery_saver_trigger_level = newMapFromValues("casual", 20, "work", 50, "pre-backup"=30, etc.);

Yes, the glovar map support is my request. It can be {global_battery["battery_saver_level"]}, where the key "battery_saver_level" is set by some other flow. Or using {global_battery[profile]}, where the global_battery is a map, {profile} is the current profile and it will match to the percentage of the value. Either way, this require glovar support in the battery level Trigger, which is not supported yet right now.

I've been completely unaware of TWRP having this functionality so thank you for telling me this! I've found the guide for the available commands and will be looking into this soon as I've been thinking of creating a flow that would automatically download the necessary files and reboot to TWRP to install/flash the ROM update, GApps and Magisk (to retain root) zip files when I get a notification for a new update

However, I am unsure about what you mean by "showing the result of the backup". Are you saying that somewhere in the script or flow, you somehow store information on the state of the backup (whether it was successful or not)?

Yes again, result of the TWRP backup is to show the time, size, percentage battery used, temperature increase and some other info. It is just to indicate the backup has been successful. SInce this is once in a week, I prefer to have the notification for it. Where as my dailiy automagic backup only show notification when it errors.

I would against fully automated ROM/magisk/twrp/gapps update. There are so many ROMs, and update out there; you don't know that once in a while, a buggy update will destroy your phone. Just like previous magisk 18.0 which cause bootstuck in several user's phone. I know it is not intentional, but damage has been done. That's why I would always prefer semi manual update, even for the backup case. Except that is your secondary phone, where you don't mind the data is gone or having down time for several days when the update messed up.