Welcome to Tasker Tip Tuesdays, quick tips to help grow your Tasker knowledge. This week I discuss local built-in variables. If you want to learn a few secret variables within Tasker, you’ll love this useful tip.
Variables are an essential part of programming and automation. Tasker uses global and local variables for a few reasons. They are to be dynamic, to pass data between Tasks, and for flow control. Learn how to use Variables in order to advance your knowledge of Tasker. The sooner the better. Did you know Tasker has a few hidden variables? These are local variables available in all Tasks. Continue reading below.
Local Built-In Variables
As mentioned above, here are some examples of local built-in variables taken from the user guide, variables:
Action Err: “%err”
Is set to an integer if an error occurred when running the last action. The actual number can signify the error which occurred, but is usually 1 for most Tasker actions (notable exception: Run Shell and plugins).
Action Error Description “%errmsg”
A description of the error which last resulted in %err being set. Currently never set by Tasker but possibly by some plugin actions.
Task Priority: “%priority”
The priority of the running task. The priority determines which task executes its next action when several tasks are running together.
Task Queue Time: “%qtime”
How long (seconds) the running task has been running. Note that tasks can be interrupted by higher priority tasks, so this number is not necessarily the total run-time of the task.
Task Caller: “%caller”
A variable array tracing the origin of the current running task. %caller1 gives the origin of the current task, %caller2 the origin of %caller1 etc. Example: if task A uses action Perform Task to start task B, then when task A is run by pressing the Play button in the task edit screen, %caller1 in task B will show task=A, %caller2 will show ui. The format of each entry in the array is callertype(=callername(:subcallername)). Caller types ares detailed below:
- Profile: a profile (when it’s state changes). callername is either enter or exit depending on whether the profile activated or deactivated. subcallername is the name of the profile, if it has one, otherwise anon
- Scene: a scene event, with callername being the scene name. For element events, subcallername is the element name. For action bar button presses, subcallername is the label if one was given. For scene-global events (e.g. Key), subcallername is event type
- Ui: the Play button in the task edit screen in the Tasker UI
- Launch: clicking a child application icon in the launcher
- Notification: a notification action button
- External: an external application
- Task: another task, from a Perform Task action. subcallername is the task name, if it has one, otherwise anon
Now that you know about these variables, let’s see some examples in action to get a better grasp of the subject. Enjoy the video below as I provide examples for each of the above local built-in variables.
If you want yet another of these continue to the user guide Event context section for the Variable Array “%evtprm”, which is passed into the Task of certain Event Context Profiles. Limited info exists in the user guide however try a little tinkering on your own.
Using these local built-in variables, create more complex Tasks. Use them for more robust flow control by reacting differently depending on the Variable. Also use them to pass information between Tasks via a Perform Task Action. In summary, keep this knowledge in the back on your mind for when you should need it.
To catch up on previous posts in this series, visit the Tasker Tip Tuesdays page. As always, enjoy and keep learning! Until the next Tasker Tip Tuesday…