Tips and tricks for debugging your Tasker creations
I get a lot of questions from people who’ve either recreated something or made something from scratch in Tasker, only to find out that it doesn’t work when they’re done. 98% of the time, it’s one of two things: device/ROM related, or a user error. I literally can’t do anything about the first, and for the second, it’s highly unlikely that I will be able to tell what’s wrong just from vague descriptions of the problem, which often don’t even include what’s actually the problem. Bottom line, if you come across a problem in Tasker, the person most likely to be able to help you is yourself- if you know how to properly debug your creations.
First off, don’t ever add more than a few new things to a Tasker creation without testing that it works. Even if you’re copying something and believe it’s therefore bound to work, or even if you’ve done the same thing a hundred times before, it’s always better to stop, test that it works, and then move on. That way, if something goes wrong, you have already narrowed down the potential problem areas substantially.
Second, always assume it’s your own fault until proven otherwise. User errors can range from completely misunderstanding basic concepts, to simply having a typo somewhere. Just in the last week alone, I’ve had issues I’ve created myself from naming variables differently, switching two fields when configuring an action, and forgetting to add a slash in a file path. All silly mistakes that make you want to slap yourself when you discover them, but just as capable of making sure that nothing works as if everything you did was wrong. If something goes wrong, you therefore need to go over what you’ve done to make sure there’s no silly mistake in there somewhere.
So, how do you test to see that something works? With more complicated creations, you might not be able to test everything until everything is set up, but there are still ways to test pieces of something. The Run Log is a great tool, available from the main menu of Tasker. When enabled, it will list everything that happens when you run something, and if there’s an error, it will show that there is one (but unfortunately not what it is). It’s very useful when you have a long list of actions and the task stops from an error somewhere in the middle, as the Run Log will show you the number of the action that had the error (if you can’t see the information, enable screen rotation and rotate the device).
Another extremely helpful tool is the Flash action. This is a normal Tasker action that shows a quick toast message on the screen, and it’s frankly more useful for debugging than anything else. You can insert this action in various parts of your creation and feed it variables that fail to show what you want, thereby allowing you to pinpoint exactly where it all hits the fan. An example is when using Variable Split to process a bunch of data, as a Flash message can both help you show what’s in the variables before and after you split them, and by doing so help you find where something goes wrong.
Flash messages are also great as substitutes for final actions. If you have a task that processes data and then writes it to a file, creates a calendar entry, sends an SMS, or anything like that, you’re much better off waiting with adding those actions to the very end, using Flash actions in the mean while. If the Flash messages shows the exact thing you wanted to put in your SMS, it’s a fair bet that the SMS will too when you put it in. By doing this, you save yourself from having to send multiple SMS messages, create multiple calendar entries, or whatever it is your creation actually does.
Finally, the ability to disable actions and add in Stop actions can be very helpful. You can disable and enable individual actions by long pressing them to select them, then hitting the power button icon to disable them. This is useful if you have a section of a task that you know works, and don’t want to wait for it to run every time you want to test the rest. Just make sure that you don’t disable something that’s needed for the rest to work! Stop actions are similar, and they simply stop the task from executing. I often use those when some update to Tasker or something else has broken an existing creation, leaving me having to try to find the error without the benefit of testing each part as I add it.
For debugging context/profile level issues, there are also a few things you can do. If you’re having trouble with profiles that have multiple contexts, test each context on its own to see where it fails. It can often be a good idea to not tie profiles directly to the tasks you want them to be tied to right away, but instead just have them tied to tasks with a single Flash action- that way you have a fool proof way of telling whether it triggers. The Run Log can also help show you whether or not things run.
For scenes, one major source of issues is that you have to completely exit Tasker (i.e. click “back” until you’re on the home screen) for a lot of changes to be properly saved. If you test scene related things inside Tasker, you might end up having fixed a problem but haven’t saved it properly yet. When dealing with scenes, I always create a shortcut to launch the scene on the home screen, thus giving me a way to test it where I know there aren’t unsaved changes.
Finally, there’s the issue of Tasker plug-ins. With plug-ins such as AutoRemote and AutoVoice adding so much functionality to Tasker, these plug-ins are starting to have as many support requests as Tasker itself, and there are a handful or very common mistakes. Perhaps the biggest is that people simply didn’t read the Google Play description or any guides linked to from there. Another is when people have come to Tasker specifically to use a plug-in, don’t know how to use Tasker or some of its feature, and blame issues on the developer of the plug-in. When something like AutoVoice uses local variables, it’s perfectly OK for the developer to expect people to know how to use local variables, as that’s a standard feature of Tasker. AutoVoice shouldn’t have to come with a guide on using local variables any more than a trailer should come with a course on how to drive a car. In other words, if you have problems with a plug-in, make sure that it’s not a Tasker-related issue that’s actually the culprit.
I’ve also seem quite a few cases of the exact opposite: people who think they know how a plug-in works because they know how Tasker works. AutoVoice for instance works on a very different principle from Get Voice, utilizing profiles with contexts instead of actions with If conditions to filter results. Another example is AutoNotification, which uses a message/filtered context system to do what Tasker would use linked actions and tasks for. Differences like these might be because of advantages of the alternative methods, or simply because plug-ins have less access to Tasker than Tasker itself has, making workarounds necessary. The point I’m trying to make is that you should always read the documentation for a plug-in to find out how it works, not just assume that it works the way something in Tasker works.
Debugging Tasker is an art, and it can be difficult to learn how to do properly, but it’s just as important as learning how to use Tasker to begin with. Without knowing how to do it, you’ll never be able to create more advanced things in Tasker, as mistakes and errors will always be there. Always.
