Battery Level Trigger Slider

Post your feature requets for new triggers, conditions, actions and other improvements.

Moderator: Martin

Locked
User avatar
piz
Posts: 25
Joined: 13 Dec 2017 19:56

Battery Level Trigger Slider

Post by piz » 18 Apr 2019 17:26

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!

User avatar
Desmanto
Posts: 2709
Joined: 21 Jul 2017 17:50

Re: Battery Level Trigger Slider

Post by Desmanto » 20 Apr 2019 17:03

+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"]}
Index of Automagic useful thread List of my other useful posts (and others')
Xiaomi Redmi Note 5 (whyred), AOSP Extended v6.7 build 20200310 Official, Android Pie 9.0, Rooted.

Pepy
Posts: 76
Joined: 31 Oct 2018 10:53
Location: Canada

Re: Battery Level Trigger Slider

Post by Pepy » 26 Apr 2019 08:20

piz wrote:
18 Apr 2019 17:26
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.
Desmanto wrote:
20 Apr 2019 17:03
+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?
Last edited by Pepy on 22 Jun 2019 07:57, edited 1 time in total.
Hope my post was helpful :D
Device: OnePlus 5T running crDroid, rooted with Magisk 8-)

User avatar
Desmanto
Posts: 2709
Joined: 21 Jul 2017 17:50

Re: Battery Level Trigger Slider

Post by Desmanto » 26 Apr 2019 17:09

@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.
Index of Automagic useful thread List of my other useful posts (and others')
Xiaomi Redmi Note 5 (whyred), AOSP Extended v6.7 build 20200310 Official, Android Pie 9.0, Rooted.

Pepy
Posts: 76
Joined: 31 Oct 2018 10:53
Location: Canada

Re: Battery Level Trigger Slider

Post by Pepy » 27 Apr 2019 22:02

@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.
Last edited by Pepy on 22 Jun 2019 08:05, edited 3 times in total.
Hope my post was helpful :D
Device: OnePlus 5T running crDroid, rooted with Magisk 8-)

User avatar
Desmanto
Posts: 2709
Joined: 21 Jul 2017 17:50

Re: Battery Level Trigger Slider

Post by Desmanto » 28 Apr 2019 07:28

{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.
Index of Automagic useful thread List of my other useful posts (and others')
Xiaomi Redmi Note 5 (whyred), AOSP Extended v6.7 build 20200310 Official, Android Pie 9.0, Rooted.

Pepy
Posts: 76
Joined: 31 Oct 2018 10:53
Location: Canada

Re: Battery Level Trigger Slider

Post by Pepy » 22 Jun 2019 08:51

Desmanto wrote:
28 Apr 2019 07:28
{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.
Desmanto wrote:
28 Apr 2019 07:28
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);
Desmanto wrote:
28 Apr 2019 07:28
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.
Desmanto wrote:
28 Apr 2019 07:28
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)?
Last edited by Pepy on 04 Jul 2019 19:32, edited 1 time in total.
Hope my post was helpful :D
Device: OnePlus 5T running crDroid, rooted with Magisk 8-)

User avatar
Desmanto
Posts: 2709
Joined: 21 Jul 2017 17:50

Re: Battery Level Trigger Slider

Post by Desmanto » 23 Jun 2019 16:11

Pepy wrote:
22 Jun 2019 08:51
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.
Pepy wrote:
22 Jun 2019 08:51
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.
Index of Automagic useful thread List of my other useful posts (and others')
Xiaomi Redmi Note 5 (whyred), AOSP Extended v6.7 build 20200310 Official, Android Pie 9.0, Rooted.

Locked