The previous four parts of this guide have been thorough, but this is Tasker – thorough only covers a small corner. Sometimes things aren’t as simple as they seem, and other times things are actually simpler than they seem. This part will be dedicated to various tips and tricks for using Tasker, things that aren’t as obvious as they perhaps should be. I’ve tried to think of as many as I can, but there might be a second tips and tricks in the future if I think of more.
Time in seconds
Dealing with time can be annoying, as hours and minutes don’t exactly work that well with withnormal math. That creates something of a problem when a lot of Tasker actions/creations require you to find out when something occurs in terms of time from or until now, or between two points in time. Examples are the Calendar Insert action, which requires you to input the date and time in minutes from now, or my sleep mode profile, which tells me the time I slept.
The solution is to use the smallest measurement of time we use normally: Seconds. Referring to all time as seconds allows you to apply normal math to time, like finding out how much time has passed since two dates weeks from one another by using simple subtraction.
This, of course, requires that all time is converted to seconds. Actual measurements for time, such as minutes, hours, days, weeks, or months, can easily be converted with multiplication or division. There are 60 seconds in a minute, so 1000 seconds is 1000/60 minutes, and so on.
Calendar dates, on the other hand, is another matter. After all, “how many seconds is today’s date” makes no sense in a traditional conversation. Luckily though, Tasker has a built in system that makes that statement make sense, by using its own chronology that started in January, 1970. All dates since then can then be expressed as a (large) number of seconds elapses since then.
This number can then be accessed in two ways. The built-in variable %TIMES gives you the current date/time in seconds, similar to how %TIME and %DATE does it for actual time/date. You can also use the Variable Convert action, which I’ll talk more about below, to convert times and dates into this format. You then have the tools needed to apply math to time. The result will be in seconds, which you can convert to minutes, hours, days, weeks, etc, by dividing by 60, then 60 again, then 24, and so on to move through the formats.
To take a concrete example, I mentioned my sleep mode profile. When that one is activated, it writes %TIMES to a user-created variable, %smactivation. When it’s deactivated, it does a simple (%TIMES-%smactivation)/3600, giving me %smduration. Dividing by 3600 is the same as dividing by 60 and then 60 again, converting seconds into hours. As such, %smduration is the total time (in hours) that the profile was active. Note that the result doesn’t convert decimals into minutes, meaning that it gives me 8.5 hours, not 8 hours 30 minutes. I could easily make it give me hours and minutes, but I understand either format just fine.
Variable Convert is an action everyone should be aware of. It can convert the contents of a variable into another format, given of course that it supports that particular conversion type. You have everyday things like feet to metres, more specialized things like hex to decimal, and the conversion I talked about above: Time in seconds. The latter is perhaps the most important conversion available in Variable Convert, and it even has four different conversion functions associated with it.
Date Time to Seconds is the conversion function you have to use to convert into time in seconds. The Tasker user guide, available through that question mark in the bottom corner of the Variable Convert configuration screen, has an overview of what format the time and date has to be in to be compatible with Variable Convert, with perhaps the most straight forward being YYYYMMDD HH.MM. The date can be in there on its own, in which case the time is assumed to be 00.00, but converting just time requires you to specify a date, even if it’s today.
Sometimes you’ll find yourself with a date that’s in another format than what Variable Convert wants, for instance if you pull data from a calendar online or similar source. This is where your skills in using Variable Split, Variable Section, and in some cases, math, comes in.
As an example, let’s say that you have a %date in the format DDMMYYYY and want it to be in the format YYYYMMDD. A pretty simple way to do that would then be:
1. Variable Section
From 1, Length 2
Store result in %dd
2. Variable Section
From 3, Length 2
Store result in %mm
3. Variable Section
From 5, Length 4
Store result in %yyyy
4. Variable Set
%newdate to %yyyy%mm%dd
%newdate can then be used in Variable Convert.
Note that some of Variable Convert’s accepted formats depend on the date format setting in your system settings. It’s important to remember that you have the tools to do practically anything to the value of a variable, and so the order of a date isn’t an impossible task. It is however also important to remember to check what input an action like Variable Converts accept, and not just input anything thinking that it’s capable of ectracting the same information from something as you can.
Time in seconds to date time
The other three time/date related functions deal with converting back to a human readable format. The only difference between them is how much information the resulting variable contains. The image below shows the difference between the Date Time, Medium Date Time, and Long Date Time options.
A very typical use for this would be to return a human readable date after you’ve done some calculations with time in seconds. You could for instance make a task where you input a number of days from today, and then it returns what date that corresponds to. It would be as simple as adding X*24*60*60 (where X is the number of days, and the calculations turn that into seconds) to %TIMES, and running the resulting variable through Variable Convert.
Variable Randomize is the alpha and omega for making any part of Tasker random, but it’s not the most intuitive action out there. Looking at the options, you’ll see some fairly simple options for Name, Min, and Max. Simply put, it gives the Name variable a value between Min and Max. Sounds simple enough, but how on Earth do you use that to for instance read a random file, or random line in a text file?
Well, it’s all about using Variable Randomize to give you that random number, and then use that number elsewhere. Many settings for other actions in Tasker allow you to use variables as the setting instead of a static value, and the key is to use these two features together. For instance, the Read Line option allows you to read a line from a text file. That line is specified by the option Line in the Read Line action. By first doing a variable randomize, and then using the created variable in the Line field, you end up reading a random line! This can be used in so many places, down to reading different files by giving the files names with numbers.
It doesn’t stop there though. The Min and Max fields in the Variable Randomize action itself can be replaced with variables, which means that you can control the range of the randomize action remotely. An example of this in practice can be found in my random dinner picker, where the task looks like this:
1. Read File:
To Var: %dinnertext
2. Variable Split:
3. Variable Set:
4. Variable Randomize:
5. Variable Set:
The task starts out by reading the content of a text file, and splitting it by |.
| has been intentionally added at the end of each line in the text file with the specific purpose of acting as a splitter. Splitting by it therefore gives us one variable for each line in the text file.
Action 3 sets %dinnerrandom to %dinnertext(#). By adding (#) to the end of a base variable (aka an array) with lots of children (%dinnertext1, %dinnertext2 etc), you’re actually asking Tasker to insert the number of child variables in place of the variable. If the text file contains 5 lines, you get variables %dinnertext1-5, and %dinnertext(#) will be 5. This is a quick and dirty way of counting how many lines there are in the file, by counting how many variables were created when splitting.
Action 4 does a Variable Randomize from 1 to %dinnerrandom. In other words, a range equal to the number of lines in the original text file. This gives us a random number that is guaranteed to be within the right range for the text file, even if the text file has been externally edited, since the range is determined by first reading the text file!
Action 5 uses this randomly generated number to pick the corresponding child variable, and transfers that into a global variable. This variable can then be used in a Say action, Notification action, etc.
By doing it this way, the task is completely independent of text file changes. You don’t need to update the task for every time you update the text file, as the task will count the number of entries itself, and pick a random number from that range. This saves you from having to change the Max field in Variable Randomize every time the number of lines in the text file changes.
Both If conditions and variable manipulation allows for applying math to the situation. I mentioned a few uses for this above, with converting different measurements for time. The good news is that the approach is pretty straight forward: Use Tasker variables with numerical values in place of actual numbers (much like you use unknowns in math), and then use normal mathematical rules. The bad news is that you still need to know math to be able to do this, which in many cases can be a bigger challenge than anything else in Tasker. If you don’t know when to put something in parenthesis in math, Tasker won’t understand what you’re trying to do either.
Math can in some cases also be used as a replacement for Variable Split/Variable Section, but you have to be careful when doing so. If you have a time in the format HHMM, like 1435, you can actually make that compatible with Variable Convert by dividing by 100. This gives you 14.35, which is a decimal number from a math perspective, but a time with a period as the separator between hours and minutes from a Variable Convert perspective. The reason why I say you have to be careful is that doing the same thing to a time with a zero at the beginning or end, like 0930, will result in 9.3, as you don’t store unnecessary zeros when doing math. Variable Convert won’t understand what 9.3 means in terms of time. You can run after it with If conditions for variable length and throw zeros at the end after the fact, but it quickly escalates into dozens of actions to cover all possibilities.
Something as simple as counting something has a lot of uses in Tasker. You can for instance count incoming SMS, emails, the number of hours you’ve been at work, slept, or driven in your car. You can use this information in feedback to the user (notifications, Says), widgets, or to control/trigger actions and contexts.
Variable Add is a very useful tool in these cases. It adds a specified numerical value to a variable every time the action is run, essentially making the variable a counter. If you tie this to a Event context, like Received Text, you have a system that adds to a variable every time something happens.
When doing this, it’s important to remember to reset the variable, as well as when to do it. Never confuse such a counter with an app’s internal counter, as they don’t have to be the same. For instance, I can add a profile that counts how many SMS I’ve received by adding 1 to a variable every time I receive an SMS. If I then go into the SMS app and read SMS, the SMS app’s internal unread counter will reset, but the Tasker counter won’t. To reset the Tasker counter, I could for instance create a profile that sets the counter variable to 0 whenever the SMS app is opened, which then assumes that I opened the app to read the messages. If I leave the app without reading all the messages however, the counter will be off the mark again.
Normally this isn’t a big problem, at least not if you keep up to date with reading all messages. Using Tasker like this isn’t as accurate as reading an app’s internal counter, but on the other hand, you can count pretty much anything that happens on your phone. You can also combine different counters, like combining missed calls, SMS, and emails into a single new events counter.
The Test action is semi-hidden away in the Misc category. Test here refers to testing the value of something, like a variable, static data, or a file. There’s a long list of test types you can choose from, ranging from the length of a variable to the modification date for a file.
I don’t find myself using this action a lot, and when I do, it’s normally the Variable Length test type I use. This counts the number of characters in a variable, which can have uses in for instance Variable Section. The Test action is one of those actions you should know of and be familiar with so that you know to look there if you ever need one of its tools, just like Variable Convert.
Don’t be afraid to use multiple task and profiles to accomplish something
One thing that has surprised me from watching help requests for Tasker is how a lot of people feel a need to cram as much functionality into as few tasks and profiles as possible. It seems to come from wanting to keep Tasker organized and running smoothly, but often comes at the expense of actual functionality.
I’ll use my sleep mode profile as an example once again. 98% of the time I trigger it by plugging in my charger, which Tasker can read using a power state context. Despite this, the profile isn’t triggered by that context. It’s triggered by a variable context, %Sleepmode, which in turn is set by a separate profile with the power state context. This means that plugging in the charge makes one profile set a variable, which in turn enables another profile. So, why use twice as many profiles as what’s seemingly necessary?
The answer is simple: To make the main profile controllable with different methods. My Tasker based voice assistant, Nelly, also has the ability to set %Sleepmode, based on voice input containing “goodnight” and “good morning.” If the main profile had been tied to AC charging directly, I wouldn’t have been able to also control it using Nelly. I’ve mentioned the advantages of turning contexts into variables before, and this is exactly that.
I should also remind everyone that adding multiple contexts to a profile makes the relationship between them AND, not OR. All the contexts have to be met, not either one or the other. There is no way to make this relationship OR, as there frankly is no reason to. Profiles tie contexts together with tasks, and the same task can be used by multiple profiles. You can therefore have two separate profiles, each with different contexts, tied to the same task, and still only have to edit one task. It might clutter up your Tasker a bit, but practically speaking, it makes no difference.
Don’t confuse the lack of an OR relationship between different contexts with the relationship between several possible configurations of the same context, however. You can for instance have a single WiFi Connected context react to multiple different networks by using a slash in the configuration fields, like SSID. If you want a profile to be active both when connected to a WiFi network called Home and one called Work, you put Home/Work into the SSID field.
Tasks can also be split into pieces, by using the Perform Task action to run other tasks as part of a task. This both helps keeps things organized and makes it possible to share action groups between tasks.
An example is my widget update task. It contains actions that together pull in the necessary information and use it to update my Make Your Clock Widget widget. Updating the widget is something I need to do in multiple situations, including when the device boots, and when one of the values (of which there are several) used in the widget changes. Instead of inserting the same actions in all the different tasks, they’re all located in a separate task, which the other tasks can then call on using a single action. It saves you time both with initial setup and when you need to edit the actions.
Speaking of editing actions, I have several rather complicated single actions in my Tasker. By complicated, I mean that there are many fields that are filled in, often with a lot of information, and perhaps even an If condition that adds even more. If you need the same action in multiple places you can of course copy and paste it, but you might also consider giving those actions their own separate tasks, and using Perform Task to refer to them. That way, you only have to edit those complicated actions in one place to have the changes apply to everywhere it’s used. Heck, it doesn’t even have to be a complicated action, just something that’s used in enough places to make any edits a pain, unless you can edit it in just one place.
Back-to-back calendar events can overlap in Tasker
The ability to have profiles be active when calendar events are is great, but there’s a “trap” with that system that is very easy to be caught in. If you have two calendar events that are back to back, say from 9.00-10.00 and 10.00-11.00, you would perhaps assume that the first one would become inactive at the same time the second becomes active. That’s not the case. A calendar event lasting until 10.00 actually lasts until the time is no longer 10.00, which is at 10.01.00. From 10.00.00 to 10.00.59, both the above events are active, which causes the collision.
To avoid this, back-to-back events have to be set up so that one event ends a minute before the other begins, in this case 9.59. The event will then stop being active at 9.59.59, and the second event will become active at 10.00.00.
There are a few handfuls of apps that are integrated with Tasker, on top of whatever Tasker can get from the system. That still leaves a lot of apps and services that Tasker doesn’t have direct access to. The Notification event context can often help in such situations, allowing Tasker to react to notifications created by other apps, assuming Tasker has accessibility access (a setting in the main system settings). You can filter by what app sent the notification and the title of the notification, but unfortunately not the description. The notification title will also be stored in the built-in variable %NTITLE, allowing you to use it in Tasker.
The usefulness of the title field depends on the app, and even the OS version. The Gingerbread Gmail app creates a different notification title than the ICS Gmail app, and neither really contain the info one would likely need (such as message subject, which is stored in the notification description). This means you can create profiles that act on notifications from Gmail, but forget about filtering them based on subject (K-9 mail is however an alternative email app that has the needed Tasker integration). Like I said, the usefulness of the notification title depends on the app and OS version.
Furthermore, Tasker is only able to see the notification when it appears. There’s no State equivalent for ongoing notifications, which would be useful for long app installs, file uploads, syncs, and other processes that use ongoing notifications while active. Similarly, there’s no Even action for when a notification disappears. Blame Android.
Even with these restrictions, the Notification event is great. I personally use it to customize Gmail email notifications based on location (visual at home, strong vibrations outside), and you can imagine similar uses with other apps.
Delaying a profile’s activation/deactivation
Sometimes you may not want your profile to activate or deactivate the very moment the context is met. A typical example would be if you have a WiFi Connected profile that you don’t want to deactivate if you move out of range for a few seconds, or perhaps you want your meeting profile to deactivate a few minutes after the calendar event context is over, giving you time to exit before sounds start coming. Delaying a task is simple with the Wait action, but dealing with profiles like this is a bit trickier – but not much.
Let’s assume you want to create a profile that is active when connected to a WiFi network, but you want to make it so that the profile doesn’t deactivate until the device has been disconnected for 5 minutes without having reconnected in the mean while.
To do this, you want to make the actual trigger for the profile its own profile, with both an enter task and a named exit task. The enter task does a Set Variable %Wifiactive to 1, as well as a Stop action with the exit task’s name. The Exit task first does a Wait for 5 minutes, and then a Set Variable %Wifiactive to 0. You then create your original profile and use the Variable Value state context for %Wifiactive equals 1.
What this does is to make your original profile triggered indirectly, by a variable set by another profile. That other profile contains the original context, but it’s that profile’s tasks that control the other profile. That way you can use the standard Wait action to actually delay the deactivation of the main profile by 5 minutes. If the device reconnects in those 5 minutes, the enter task’s Stop action will stop the exit task, which is important to avoid the Exit task completing and disabling the other profile despite the reconnection.
There are probably hundreds of tips and tricks that help with using Tasker, and these are just the ones that came to mind. If you have any to add, feel free to do so in the comments below.