%BATT (Battery Level) variable "not valid" in Variable Value State context

[Alex Peters]

I want to create a profile that activates when the battery level goes to or below a value specified in a global variable.

The obvious profile setup:

Not Variable Value %BATT, Maths: Greater Than, %CriticalBatteryLevel

doesn't work:

Error: That built-in variable is not valid here.

 I can get around this limitation by creating four profiles instead of one:

1. on battery level change, set %Batt to %BATT
2. on monitor start, set %Batt to %BATT (so that %Batt is still accurate when Tasker starts)
3. when %Batt is not set, set %Batt to %BATT (so that %Batt is immediately available after setting up the profiles without having to disable/re-enable Tasker or wait for a battery level change)
4. when %Batt <= %CriticalBatteryLevel, do things

In short, I can keep my own copy of the %BATT variable and monitor that.

Why is this necessary though?  The inability to use %BATT in a Variable Value State context seems to be by design, yet the aforementioned set of profiles proves that Tasker is technically capable of doing this.

[Bob Hansen]

If you reverse your variable check so that the %BATT is the second variable, it will work. Like this

Variable Value %CriticalBatteryLevel, Maths: Greater Than, %BATT

[Pent]

Why is this necessary though?  The inability to use %BATT in a Variable Value State context seems to be by design, yet the aforementioned set of profiles proves that Tasker is technically capable of doing this.

It's not by 'design'. It's just that it takes work to monitor extra vars. You have the Battery Level state, I guess I was thinking you wouldn't need to put %BATT in Variable Value.
I appreciate you can't compare to a var there however.

Pent

[Alex Peters]

On Sunday, 7 July 2013 22:55:09 UTC+10, Bob Hansen wrote:

If you reverse your variable check so that the %BATT is the second variable, it will work. Like this

Variable Value %CriticalBatteryLevel, Maths: Greater Than, %BATT

...and three extraneous profiles deleted.  Would never have occurred to me to swap the sides.  Thanks for your lateral thinking!

On Monday, 8 July 2013 05:10:34 UTC+10, Pent wrote:

It's not by 'design'. It's just that it takes work to monitor extra vars.

Okay, only "by design" to the extent that the UI knows to disallow it rather than a force-close happening later because of something being unimplemented. ;)

Given however that everything is fine if %BATT is on the RHS of the expression, is it fair to say that the work is already mostly done and that the inability for %BATT to appear on the LHS is actually a bug?

[Pent]

Given however that everything is fine if %BATT is on the RHS of the expression, is it fair to say that the work is already mostly done and that the inability for %BATT to appear on the LHS is actually a bug?

It's looking increasingly that way :-)

Will take a look.

Pent

[Pent]

p.s. it could be that Tasker happens to be monitoring battery due to something else in your
config data, and that the Variable Value context wouldn't work otherwise.

Pent

[Robert Yung]

I know this thread is super old but so what is the conclusion on this strange behavior: bug or feature? The guide says %BATT is not dynamic but using it as a variable value check target in a state works when the reverse is not allowed.

My previous solution, before I saw this bizarro thread, is this:

event: power level change: set %MyBATT to %BATT

state: check if %MyBATT is > %SpecificBatteryLevel

Is there any advantage for that compared to this?

state: check if %SpecificBatteryLevel < %BATT

It just seems like a bug that while it works, it may get fixed later and so you shouldn't depend on it.

[Duck Redbeard]

How about using State>Power>Battery Level as a battery value.  If %BATT falls between those two values, then the profile would be active.  

[Robert Yung]

On Wednesday, May 23, 2018 at 9:16:17 AM UTC-4, Duck Redbeard wrote:

How about using State>Power>Battery Level as a battery value.  If %BATT falls between those two values, then the profile would be active.  

I don't want to use the battery level context as it doesn't accept using variables to set the thresholds. I have my thresholds dynamically set based on the day of the week and the phone it's on (make's it easier to deploy my code to multiple phones and not have to worry about adjusting values for each later).