Variables

General

A variable is a named value which changes over time e.g. the level of the battery, the time of day.

When Tasker encounters a variable name in a text, it replaces the name with the current value of the relevant variable before carrying out the action.

The main purposes of variables are:

Global vs. Local Variables

Variables which have an all-lower-case name (e.g. %fruit_bar) are local, meaning that their value is specific to the task or scene in which they are used.

Variables which have one or more capital letters in their name (e.g. %Car, %WIFI) are global, meaning that wherever they are accessed from the same value is returned.

Built-In Variables

The values of built-In variables are updated automatically by Tasker.

Local Built-In Variables
Global Built-In Variables
General Notes

Variables marked dynamic in the list above trigger changes in Variable Value states and Variable Set events whenever their value changes.

Variables marked monitored will cause the relevant monitor to startup to track their state when they are used in contexts or tasks which are used by widgets or enabled profiles. For instance, %CELLID used in a Flash action will cause cell location to be tracked.

Limitation: monitored variables cannot be detected in anonymous shortcuts.

Note On Location Variables

When the relevant provider (Net or GPS) of a location context is active, these variables report the values from the provider, which may be more recent than Tasker has seen if other applications are asking for location.

When the relevant provider is not active, these variables report the last values seen by Tasker, which could be the result of a Get Location action or of monitoring for a Location Context.

That means the the reported fix times could go backwards, if you turn off the location provider between two uses of the variables.

Location variables can also be manually updated by running the Get Location action.

User Variables

The action Variable Set (and several others) can be used to create new variables. Variable names have the following restrictions:

In general, it's best to use local variables wherever possible because:

Note: multiple copies of the same task running at the same time each have their own separate copy of their local variables.

Scene-Local Variables

Each scene has its own set of local variables which it shares with the task that created it; both the scene and task see changes to the variables made by either.

Any task which starts as a result of a scene event (e.g. a tap on an element) also shares the variables of the scene (and thus of the original task which created the scene).

As a consequence, a task started by a scene event (e.g. Tap on an element) which shows a new scene e.g. via the Show Scene action, will result in the second scene sharing the variables of the first scene.

When a task shows a scene that was created by a different task (or a different copy of the same task) and subsequently hidden, the task's variables are copied to the scene variables (overriding values of variables which already exist) but the task does not share the scene variables and cannot see changes to them.

Escaping Variable Names
If you want to prevent a variable name being replaced, put a \ in front of it e.g.
Variable Set, %new, \%old
Will set the value of %new to %old, not the value of %old.

In order to precede a variable name with a \ you can escape the backslash e.g.

Variable Set, %new, \\%old
Will set the value of %new to \ followed by the value of %old.
Variable References
It's possible to indirectly refer to variables by preceeding one or more extra % signs to the start of the variable name. For example:
Variable Set, %colour, red
Variable Set, %varname, colour
Flash %%varname

... will flash red.

Using this notation it's possible to assign variables whose name is not known beforehand:

Read File, variablename.txt, To Var, %varname
Variable Set, %%varname, red

This will set the variable whose name is stored in the file variablename.txt to red.

You can nest references as deeply as you like (e.g. %%%%var) but mental stress and bugs are sure to follow.

If any part of the chain has an invalid variable name then the original reference will be returned. In the first example, if %varname is set to !!!, then %%varname will be flashed instead of red.

Variable Lifetime
The value a global variable holds lasts until Tasker is uninstalled if it is not changed by any task.

Local variables are lost at the end of the task they were created in, or when the parent scene is destroyed in the case of tasks called from scenes.

Uninitialized Variables

User-variables which have not had a value assigned do not have replacements carried out e.g. in the expression I love %fruit, if %fruit is uninitialized, the expression remains as it is, otherwise %fruit is replaced with the value.

Exception: uninitialized variables used in mathematical expressions are replaced with 0.

Variables In Plugins

Plugin developers can tell Tasker to replace variables it finds in plugin strings with their current Tasker value. If you have a plugin which doesn't support this, send the developer this URL
http://tasker.dinglisch.net/plugins.html

which has the relevant details.

Variable Arrays

Tasker supports pseudo-arrays.

They are especially useful when used with the For action, since you can perform a set of actions on each element in turn e.g. list a set of files then test each one.

Examples

If the four variables %arr1, %arr2, %arr3, %arr4 hold respectively a, b, c and d then we have an array with 4 elements. These variables can be used just like any other, however it is also possible to access them in special ways. Here are some examples:

Notes:
Creating An Array
  1. using Variable Split:
    Variable Set %arr a,b,c,d
    Variable Split %arr
    If your data has commas in it, you can separate the values with e.g. @ and specify @ also in the Variable Split action.
  2. by assigning individual elements with Variable Set:
    Variable Set, %arr3, c.
  3. using Array Push to add an initial element
  4. some other actions also create arrays for their results e.g. List Files.
Inserting Elements
Use the Array Push action.

The Fill Spaces parameter might need more explanation. It is only relevant if one or more of the array elements are undefined. As an example, if we have the array elements %arr1 and %arr3 containing apple and banana:

Removing Elements

Use the Array Pop action. Note the difference between Array Pop and Variable Clear: Pop reduces the number of elements in the array, while Clear merely changes elements to undefined.

Example: if we have the array elements %arr1, %arr2, %arr3 containing apple,pear and banana:

Deleting An Array
Use Array Clear.

In most cases you could also use Variable Clear %arr* with Pattern Matching checked, but that would also delete variables called e.g. %arrTOODEETOO so Array Clear is safer.

Sorting
The Array Process action offers various sorting options, amongst other things.
Array Efficiency
Arrays are intended for convenience when processing high-level data, not for e.g. processing astronomical data. Doing thousands of array actions will likely take several seconds (although mostly due to the housekeeping work done by Tasker in-between each action rather than due to the array operations themselves).

In terms of storage efficiency, they are also fairly hopeless. You probably do not want to store tens of thousands of items in an array.