A month and a half ago, I posted a guide to AutoVoice. At that point I didn’t think I was going to end up using it myself, but I was wrong. AutoVoice is becoming more popular every minute, and has even gotten several new features since the original guide, so I thought I would take the experience I’ve had with AutoVoice since then and write a more comprehensive, updated guide for AutoVoice, and make it part of the Beginner’s Guide in the process.

Note: AutoVoice is a plug-in app for Tasker. This means that in order to be able to use it, you absolutely have to know how to use Tasker. I say this because with the increasing popularity of AutoVoice recently, a lot of people are looking into Tasker for the first time specifically for using AutoVoice, and I cannot stress enough that you need to know Tasker before you can start using AutoVoice. This guide deals with AutoVoice itself, and won’t explain every term and concept that’s a standard part of Tasker. For a guide to the basics of Tasker, follow this link. Trust me when I say there are no shortcuts here, and you cannot expect to start creating amazing home automation systems and voice assistants right away if you’ve never touched Tasker before, because Tasker itself is a bigger part of an AutoVoice setup than AutoVoice is.

Note 2: This guide is being released simultaneously as a major AutoVoice update, and covers the new version. It’s important that you update in order to see all the features referred to here.

What is AutoVoice?

AutoVoice is designed to allow you to use voice recognition to transfer spoken commands into Tasker, where you can then use those commands for various things. Tasker does come with a similar feature out of the box, called Get Voice. Get Voice is an action that pops up a voice input box, waits for you to speak, stores the result in the variable %VOICE, and that’s it. To actually use the information in that variable, you need to use complex systems of if/then conditions and sometimes also split and process the data in the variable before it’s of any use to you. It works, it’s just that it’s one of so many features that only the basic functionality is in place.

AutoVoice, on the other hand, is a standalone app whose only purpose is to give users as many features related to voice control in Tasker as possible. The basic concept of how it works is different and easier to manage, you have more variables to access the information (making data processing easier/less likely to be needed), Bluetooth headset support, direct shortcut support, a separate log system, a feature for chaining commands together, and much more. Bottom line, if you took Get Voice and expanded it, you’d get AutoVoice.

How AutoVoice works: Action/profile relationship

One of the fundamental differences between Get Voice and AutoVoice is what it does with the data after you speak into the microphone. Get Voice is basically designed to be part of a task, where you use the Get Voice action to input data at some point in the task, and you then normally use that data later in the same task. In many ways, Get Voice is the voice equivalent of popping up a keyboard to ask you to input something.

AutoVoice on the other hand is designed more with voice assistant functionality in mind. It assumes that you’re not using it to just input some text somewhere instead of using a keyboard, but instead that you’re using it to give voice commands to your phone. Because of this, each response to a specific command is its own profile in Tasker. These profiles consists of a standard Tasker task that contains everything you want to happen when a specific command is recognized, as well as the AutoVoice Recognized context which makes sure the profile runs when specific words or phrases are detected in the voice input. The AutoVoice Recognized context has a so-called command filter, which is a field where you specify the word or phrase that should trigger that profile. If the command filter is “hello”, the profile will trigger when the word “hello” is used in a voice command.

Triggering the voice input box that you speak to is done completely separately from these profiles, either using a Tasker action, a direct shortcut (part of the Android shortcut system and available in launchers and similar apps), or a direct response to clicking a Bluetooth headset button (the options for this can be found in the main AutoVoice app, and are named “AutoRecognize BT”). This way you have a standard way (or ways) of triggering the voice input box, and then however many AutoVoice Recognized profiles you have will all be able to trigger based on what you say.

Example

As an example, let’s say you want to create a task that runs when you tell AutoVoice “hello”. You would then start by creating a new profile, and selecting the AutoVoice Recognized context from the State-Plugin section. AutoVoice Recognized is simply the context that’s used for making profiles active when AutoVoice hears a specific phrase. In the configuration screen for this, you should first enable Event Behavior. This option should basically be enabled on every single profile, as it makes it so that the profile acts as an Event profile as per standard Tasker behavior. Next, you would go into Command Filter, enter “hello”, and save out of everything. For the task attached to this context, you would put in everything you’d want Tasker to do when you tell AutoVoice “hello”. For the sake of the example, let’s say you put in a Say action with “hello to you too”.

Now you have a profile that responds to any mention of “hello” when you use voice commands. This includes “hello”, “hello how are you”, and “I just wanted to say hello to you”; in other words, the command filter just has to be part of the spoken phrase.

Finally you need to set up a way to trigger voice recognition. As mentioned earlier, you have three options: Tasker action, direct shortcut, and Bluetooth headset buttons. The Tasker action is called Autovoice Recognize (not to be confused with the AutoVoice Recognizedcontext) and can be found in the Plugin section of the action library. Simply running a task with that action in it will pop open a speech input box so you can start giving voice commands, and the same goes for the other two methods of invoking this speech box. The trick is to use these options to give you easy ways of activating the box to start giving voice commands. I have a shortcut on my lock screen, an AutoRemote command, and an anywhere-accessible touch screen gesture using GMD GestureControl which I can use to trigger it on my phone.

Accessing voice data in the task

The above example used a static response that simply triggered on a keyword, but a lot of the time you’ll want to use whatever you say as part of the task. A simple example would be a task that responds to “Call me [Name]”, where it would respond with “I will call you [Name]”. In that case you’ll need to actually get your hands on the name that was spoken, and AutoVoice gives you several options to do that.

The first is with the variable %avcomm, which contains the entire command that was recognized. If you say “Hello how are you today”, %avcomm will contain “Hello how are you today”.

The second variable you can use is %avcommnofilter. This is essentially the variable from above minus the command filter that was specified. If you say “Hello how are you today” and the command filter is “hello”, %avcommnofilter will contain “how are you today”.

The third option is an array, so knowledge of how to use arrays is useful. Each word you speak will be given a separate variable as part of an array, %avword. This means that if you say “Hello how are you today”, %avword1 will be “Hello”, %avword2 will be “how”, %avword3 will be “are”, %avword4 will be “you”, and %avword5 will be “today”. This array adapts to however many words the command consists of.

The final option is to use regex to create your own variables based on the input command. This is done by replacing dynamic parts of the command filter with (?<variablename>.+), and will create %variablename with a value of whatever it replaced. As an example, a regex command filter “say hello to (?<name>.+)” and a spoken command “say hello to Bob” will create %name with the value “Bob”. This gets increasingly useful the more integrated the information you need is, for instance if you have a command filter along the lines of “”turn (?<room>.+) lights to (?<level>.+) percent”. You can of course combine this with other regex features like wildcards to tailor what it triggers on.

To properly go through how to use this method in various situations for anyone who’s not familiar with regex would require a regex guide in itself, and I won’t do that. An alternative to this method that doesn’t require regex knowledge is available here. The regex method is cleaner, the alternative is easier to understand, so I’ll leave it at that.

As you can see, all of these variables are local variables, hence the lower case letters. That means they’re only available in the entry task for any profile triggered by the command, and not anywhere else. You can of course use standard Tasker methods for copying them into global variables if you need to store the information or use it elsewhere.

Command ID system

One of AutoVoice’s big advantages over Get Voice is the command ID system. This system allows you to better control when AutoVoice profiles can trigger, by making them dependent on certain command IDs.

A command ID is simply a number that you can specify in order to link profiles together. You can set the current command ID either using the Set Last Command ID action in a task and then running it, or by using the Command Id field in a AutoVoice Recognized context and make that profile activate. You can then specify the same number under “Last Command Id” in an AutoVoice Recognized context in order to limit that context to only become active if the given command ID is set.

Example: Command ID with context

Let’s say you create a profile that sends an email based on your voice command. You want to make sure it gets things right, so you first have it read it back to you and ask you if that’s what you want to do. You then create profiles for “yes” and “no”, and everything works fine.

A bit later on you create a similar profile for Twitter, and you add new profiles that use “yes” and “no” as the trigger. The first time you use it, you discover that when you say “yes”, it triggers both the yes-profile for Twitter and the one for email! If you say no, it triggers both no-profiles!

To fix this, you set up the “yes” and “no” profiles for email to have 1 in the Last Command Id field. You then go into the first email profile (the one that asks you for confirmation) and set the Command Id field to 1. Next up, you do the same with the Twitter profiles, but use the number 2 instead.

This will limit the yes/no profiles so that they can only run after their “parent profiles”.

Example 2: Command ID with action

The above example was for using a context for setting the command ID. However, you can also do it with an action, which can be useful in a lot of cases.

One example is if you want to have different variations of a profile trigger based on how you initiated the voice input box. Let’s say you have a profile for starting AutoVoice Recognize with a Bluetooth headset button, as well as a home screen shortcut to a task that starts it directly. When you use the home screen shortcut, you want it to respond to you using discrete Flash messages on the screen, but when you use the Bluetooth headset, you want it to respond using voice with the Say action.

You could then use the AutoVoice Set Cmd Id action to set a command ID as part of the task that initiates the voice box, using different IDs for the Bluetooth profile and the home screen shortcut task. You can then make two separate profiles, one for the Flash response and one for the Say response, and simply use the respective command ID to limit when they can run. That way you can have two separate versions of the same profile, both with the same command filter, and control which one triggers based on how you initiated voice input.

A more advanced example is to use AutoRemote to initiate voice input on your device from your PC, and then use the same method to decide whether something is done locally (when the voice input box is triggered locally) or remotely (when it’s triggered from AutoRemote). One way of using this would be to have a Google search feature that would search on your Android device if the voice recognition was initiated there, or on your PC if it was initiated from there.

Please also read this post about a certain situation where the Set Cmd Id action is a fix for an issue with context-set command IDs.

Rec Failed and No Match

AutoVoice comes with two contexts that are important to know how to use: AutoVoice Rec Failed and AutoVoice No Match.

AutoVoice Rec Failed is a context that will make a profile activate when the voice recognition failed. This means it failed to find any language in what you were saying, or it didn’t hear you say anything at all. Do not confuse this with misinterpreting what you said, as then the recognition didn’t fail, it simply didn’t recognize it correctly. The purpose of this is to create profiles that for instance asks you to repeat if the recognition fails. Command IDs are supported for this context.

AutoVoice No Match is however a context that allows you to create a profile that triggers when it did detect some language in what you said, but couldn’t find a profile that matched anything. An example would be if you said “hello” to trigger a profile with command filter “hello”, but it heard it as “hell of”. This feature is new to AutoVoice and is what a lot of people thought the above feature was for. It does not support command IDs a the time of this writing, but you can find an option in AutoVoice’s advanced settings section to set the time that AutoVoice will wait for a profile to activate before deciding nothing was matched.

Bluetooth headset support

AutoVoice supports Bluetooth headsets, which is another bonus over Get Voice. You will find Bluetooth related options all throughout AutoVoice, and most of them are fairly self explanatory. When configuring the AutoVoice Recognize action, you can device whether or not it will use the headset. To use the headset’s buttons to trigger Tasker tasks, use the AutoVoice BT Pressed contexts that come with AutoVoice to create standard profiles that are triggered when the buttons are pressed.

Please note that Bluetooth headsets are often very different, and you have no guarantee that a particular headset will work with the button contexts. You basically just have to try.

AutoVoice Continuous

AutoVoice Continuous allows you to start a background process that will listen for voice commands continuously. This means that when it’s active, you should be able to just start speaking without triggering the voice input box first.

To use it, you use the AutoVoice Continuous action in the plugin category. You basically run that action with the check mark checked to start it, and again with it unchecked to stop it. A toggleable task works well here.

This feature has been improved a lot recently, but it’s still to be considered a work in progress. It lacks some important features, and it might not work well or at all on some devices, Android versions, ROMs, etc. It also drains the battery quite quickly, and is best used connected to a charger.

Useful tips

This section will cover things that are important to know to use AutoVoice, but hard to fit into their own sections

Direct home screen shortcut

The latest version of AutoVoice has support for adding a direct shortcut to initiating voice recognition, using the standard Android shortcut system compatible with most launchers. The advantage of this is that it’s often a lot faster than doing it via a task, but the disadvantage is that you can’t do things like set a command ID with an action when you do it.

Limiting how many suggested interpretations are used

Voice recognition involves a bit of guess work on the server side, using common phrases and language models to try to interpret what you said. Normally the Google systsem that AutoVoice uses to convert voice into text will return several possible results, up to five possible results. AutoVoice profiles will trigger on any of these suggestions. A single profile will only trigger on one result, but other profiles can trigger on the same or a different result. Sometimes this can cause issues because secondary interpretations trigger profiles you didn’t intend.

As an example, I had a profile that triggered on the word “goodbye”, and another that triggered on “goodnight”. One time both profiles triggered when I said “goodbye”, because even though the first suggested interpretation was indeed correct, one of the other four suggestions was “goodnight”. Because of this, both profiles triggered.

If you have issues with this happening, you can change how many suggested interpretations are considered in the options for each AutoVoice Recognized context. The option is called Precision.

It should also be noted that even though multiple suggestions can trigger a profile, only the one that actually triggers it will populate the AutoVoice variables.

Trigger multiple profiles with the same command: Home automation example

The key to being able to use dynamic commands in AutoVoice is to pick your command filters carefully. If you can use simpler command filters without the risk of accidentally triggering the profiles, do it. This allows you to dynamically trigger multiple profiles with one command by simply working multiple command filters into the command.

An example is Doug Gregory‘s now famous AutoVoice home automation video, seen below:

This video makes it seem as though the phone is a genius, understanding everything he says no matter how he phrases it, even allowing for multiple tasks per command. It looks difficult to set up, but it actually uses very simple logic.

The system assumes that the user is not brain dead. If you mention a specific lamp, it’s extremely likely that you want to do the exact opposite of what’s currently happening. For instance, if the lamp is on, it’s fairly likely that you’ll tell the system to turn it off, as few people would stand there saying “turn on the lamp” when it’s already on. As such, it doesn’t actually need to pay attention to whether or not you say “on”, “off”, or any synonyms (kill, disable, enable, activate). It only needs to toggle the lamp whenever a reference to it is being made.

So, let’s say you want to control the “bar lights”. All you then do is create an AutoVoice Recognized profile, and specify “bar lights” in the Command Filter field. This is then tied to an action to toggle the bar lights using whatever home automation system is being used.

The result is that the bar lights will seem to react to extremely dynamic commands, like “I don’t want to see the bar lights anymore, please make them go away”. In reality, it simply picks up “bar lights”, and sends a command to toggle those. Unless you do something like tell it to turn them on when they’re actually on, or for instance mention that you need to buy new bar lights, it will seem like the system is more intelligent than it is.

By creating profiles like that for more appliances, you can mention multiple in one sentence and have them trigger. If you create similar profiles for the kitchen and living room lights, you could for instance say “turn off the bar lights and the living room lights, and turn on the kitchen lights”, and all three individual profiles would trigger, send toggle commands, and it would look like magic.

Of course, there are examples in the video that are a bit more complicated, like telling the system he’s home or to shut down. Those are then essentially standalone profiles with tasks that do everything in one go, rather than activate lots of individual profiles. By simply using Off commands rather than Toggle commands, it’s then possible to make sure that it all turns off regardless of current configuration, instead of essentially just inverting it.

Multi-context profiles as an alternative to command IDs

At the end of the day, AutoVoice Recognized context are just contexts like anything else. That means that you can use multiple contexts in a single profile, and by doing so, control which profiles trigger. An example would be to pair an AutoVoice Recognized context with a standard WiFi Connected context in order to limit where that profile can become active.

An example would be to set up several profiles that all trigger on the word “leaving”, but have other contexts as well. One could have a WiFi Connected context for your home WiFi network, and shut down your home automation system when run- allowing you to say “I’m leaving” when you leave the house. Then you could make one that had your office WiFi as a second context, and saying “I’m leaving” there would then disable office mode, text your wife, or something like that.

Event behavior should practically always be checked

Tasker doesn’t allow plug-ins to add Event contexts, so the workaround is to make a context that activates and deactivates quickly. That is what the event behavior option does. There might be cases where you wouldn’t check it, which is why it’s an option at all, but for 99.9% of cases it should be checked.

Do note that since this turns the profile into a state context that quickly activates and deactivates, you may need to disable the restore settings option for the profile (by long pressing on the profile name and then clicking the settings icon) to prevent it from instantly reverting some settings.

This behavior also means that exit tasks currently don’t really have any business being in AutoVoice profiles. If you need to make a profile that can be activated or deactivated with voice, you need to create a toggleable task or use some other method for making that happen.

Read the Google Play description

I’ve been amazed many times at how some people never bother reading the description of an app, and I’ve seen people get angry at the developer for not properly informing about something that is written extremely clearly in the app description. As such, I find myself having to point out that reading the Google Play description really is something you should do.

Frequently Asked Questions

This is a collection of the most frequently asked questions and problems that both myself and the AutoVoice developer has come across.

How do I change the recognition language?

AutoVoice uses Google’s services for voice recognition, so to change the language, go into the Google Search app, then into the settings for it, Voice, and then Language.

AutoVoice has taken over my phone dialer, how do I fix it?

Some Bluetooth headsets have their buttons mapped to dial back the last number. If you then choose to always use AutoVoice for this, you’re not telling the device to use AutoVoice for that button, you’re telling it to use AutoVoice as the dialer!

To fix it, head into system settings, Application Manager, then find AutoVoice. Click the Clear defaults-button, and it’s fixed!

AutoVoice doesn’t work with my Bluetooth headset!

Send the developer that specific headset model for free, and he might be able to add support for it. Seriously, some things you can’t guess your way to adding support for.

I tried changing settings with AutoVoice but it doesn’t work!

See the section called “Event behavior should practically always be checked” further up.

How can I make AutoVoice work offline?

Ask Google, utoVoice uses its voice recognition system.

AutoVoice doesn’t understand what I’m saying!

Try changing the language as described above. For English there are multiple variants supported, so try them all if you’re having problems.

I get connection errors even though I’m connected to the net!

This is a known issue with some versions of the Google search app, which also affects AutoVoice. Google will need to fix it.

AutoVoice cuts off my commands!

From the Google Play description:

This version is limited to commands with 4 characters. If you want to unlock complete commands, you can do it in-app or buy the separate unlock key here: http://goo.gl/g8cKH

Dear developer, how do I make a task that does X, Y, and Z?

The AutoVoice developer is responsible for AutoVoice, not Tasker. This is a distinction I see a lot of people missing completely. Like I said at the beginning, you need to know how to use Tasker in order to use AutoVoice. At the end of the day, most of AutoVoice’s functionality relates to triggering profiles, and what the tasks for those profiles do is in most cases a matter of using Tasker, not AutoVoice.

So, on behalf of everyone who wants the dev to be able to work on adding more features to the app instead of answering support requests for something that’s not actually related to AutoVoice, please make sure that if you do contact him directly, it’s actually about AutoVoice and not Tasker.

Remember, it’s not the responsibility of a cup holder manufacturer to help you troubleshoot problems with the car the cup holder is attached to.

Usage examples

Below is a few videos showing my own use of AutoVoice in various situations, to give you an idea of what you can use AutoVoice for. The reason why I’m not going through each of these in detail is that the AutoVoice part of these examples is pretty much the same for each, and nothing out of the ordinary. What separates them is what the task does once the profile triggers, and that’s all Tasker, not AutoVoice.

I cannot emphasize this distinction enough, as even though AutoVoice opens up for creating a lot of new and interesting Tasker profiles, most of the job in creating something useful with AutoVoice is knowing what to do with the Tasker part of the equation.

]]>https://www.pocketables.com/2013/06/beginners-guide-to-tasker-part-8-autovoice.html/feed2177921Beginner’s guide to Tasker, part 0: How to go about learning Taskerhttps://www.pocketables.com/2013/06/beginners-guide-to-tasker-part-0-tips-and-tricks-for-learning-tasker.html
https://www.pocketables.com/2013/06/beginners-guide-to-tasker-part-0-tips-and-tricks-for-learning-tasker.html#commentsMon, 17 Jun 2013 20:04:02 +0000http://www.pocketables.com/?p=77664Pocketables has turned into a major hub for Tasker content over the last year, and there are currently more than

Pocketables has turned into a major hub for Tasker content over the last year, and there are currently more than a hundred Tasker articles on the site, including a huge beginner’s guide. With that many articles covering all sorts of topics in a sometimes less than organized manner, I thought I would dedicate a post to talking about how one would even go about learning Tasker to begin with, place it numerically before the first part of the beginner’s guide that talks about actual Tasker functionality.

What is Tasker?

Tasker is an automation app for Android. It’s similar to apps like on{x} and Locale, but quite frankly, those apps are toys in comparison to Tasker. The basic concept with Tasker is “if X happens, do Y,” where the ridiculous number of Xs and Ys available making it as complex as it is. An example of a relatively simple Tasker setup is “if the phone is put upside down while ringing, mute the sound,” but the sky is the limit for how complex something can be. In fact, through features such as scene (interface) creation and app exports, Tasker is capable of producing fully functional, standalone Android apps.

Why should I learn Tasker?

Learning Tasker is guaranteed to revolutionize how you use you Android device. Android and its apps, like other OSes and basically any consumer product in general, are essentially all about making compromises so that the end result works well for as many people as possible. Tasker gives you the ability to custom tailor your device the way you want it, so that you’re not forced to use some lowest common denominator product.

I personally have replaced a lot of actual apps with Tasker creations I have made myself, and custom made those to fit my exact needs. I have a custom voice assistant, custom UI for controlling both my phone and my apartment, custom todo list app, custom smartwatch software, and so much more. Tasker is all about allowing you to do whatever you want, and not have to rely on someone making it for you or settling for apps that have half the features you actually want.

At this point, I don’t even consider my phone to be running Android, I consider it to be running Tasker. Tasker is to Android what Android is to a feature phone from 2001, it’s as simple as that.

How long will it take me to learn Tasker?

That depends on what your goal is. If your goal is to set up a single simple profile that combines one “if X happens” with one “then do Y”, that might not take you more than five minutes. If your goal is to go all out and learn how to do practically anything you want with Tasker, including creating your own apps, we’re talking months to years. Tasker shares a lot of similarities with programming, in that you can produce a “hello world” fairly quickly, but it will take a while until you can replicate Photoshop. It’s a continuous journey of getting better every time you use it, and while the more advanced stuff won’t be available to you straight away, a lot will.

Can anyone learn Tasker?

Like I mentioned above, Tasker shares some similarities with programming, but that’s by no means a prerequisite for learning it. Having an analytical mind that thrives on logical thinking will however help you a lot, and it doesn’t hurt if you’re creative either. The more experience you have with using software of any kind, the easier it will also be to use Tasker, because this is not an app that comes with a user manual, and so you have to be able to use common sense and just try to see what happens a lot of the time. Because of that, impatient people who expect everything to be handed to them should stay as far away from Tasker as possible.

One of the most common complaints I see with Tasker goes something like this: “I bought Tasker to do a single thing, but I can’t figure out how to do that single thing. There should be better documentation for how to do that single thing, as it’s such a simple thing that Tasker complicates.”

This is a typical complaint from someone who has misunderstood what Tasker is. Tasker can do simple things, but it can do a thousand different simple things. It’s a shell provided for the user to add content, it isn’t that content out of the box, since that would have been a seriously epic mess of pre-made profiles to cover 1000 variations of “a simple thing.” Tasker requires that you set up what you need to do from scratch, and the concept of “scratch” is very different from what you normally get with mobile apps. You don’t get a panel of settings that control Tasker’s car mode, you need to actually create that car mode by finding a way of telling Tasker when you’re in your car and what to do when you’re there. If Android apps were LEGOs, Tasker would be a giant box of different parts for creating anything, rather than a small box of the specific parts and instructions needed to build something specific.

Bottom line, learning Tasker takes time. If you’re not willing to put in that time, you shouldn’t get the app. It’s that simple. Buying the app doesn’t entitle you to have someone program it for you, and user error isn’t an application bug.

Where do I start?

The first part og the beginner’s guide to deal with actual Tasker functionality can be found here. An overview of all important Tasker articles on the site, including the rest of the beginner’s guide, can be found in our Tasker content portal.

The first thing you should do is read the first part of the beginner’s guide, and then actually look around the app to make sure you know what everything in the guide refers to in the app. Make sure you pay extra attention to the list of terms, as knowing what basic terms in Tasker refers to is vital. I often see people who use the wrong terms for things in Tasker, and not only does that make it impossible for them to find information they need on their own, but it also makes it so people have to guess what they’re talking about.

I would also strongly suggest that you don’t jump straight to any other part of the beginner’s guide after part 1, but instead play with Tasker and explore on your own. Exploring Tasker and simply looking at what’s available in terms of contexts and actions is vital for realizing what you can do with it. Simply playing with setting up simple profiles is a key part of the process. “I wonder what this does, let’s find out” is going to get you a lot further in the Tasker world than “where’s the documentation for all of this?!”, even though there is basic documentation of Tasker features both in the app and on the Tasker website.

Once you feel you have the hang of it, you can take on one part of the guide at a time. Each subsequent part of the guide deals with a very specific topic, and so treating them as chapters in a textbook is a good idea. Look at what’s there, then practice it yourself. There are tons of examples in those articles, but make sure you actually treat them as examples, not recipes. Some of them are outdated, incomplete, or have other issues that makes them usable as examples, but that’s about it.

The other articles on the content portal page are far less organized, and there’s really no “read this then that” system to it. Some of them require only very basic Tasker knowledge to understand, while others are more complicated. You can check out the list of articles and see if something looks interested, have a quick peak at it, and see if you’ve gotten to the point you need to be with your own “Tasker education” to actually get a use from it. There are also other places where you can read about Tasker, such as the official Google Group, but often those places have more help requests than actual examples and other things.

Bottom line, take it slow, and proceed at your own pace. Think of the beginner’s guide and the other articles as resources that you can use when you feel you’re ready for it, rather than material you have to digest before ever doing anything in Tasker yourself. I know it’s easy to be overwhelmed with all the features, but taking it slow is key. It can be very tempting to try to skip a few steps when you see Tasker creations from more experiences users online, but you really just have to think of those kinds of creations as the end goal.

I need help!

The vast possibilities of Tasker makes it a very attractive app to get a for a lot of people, but unfortunately a lot of those should be classified under the “impatient” category of people who should stay far away from Tasker. Asking for help is of course always an option, but more and more people treat the various Tasker help forums as places they can essentially ask people to do the job for them, and that’s not how it should be. I talk more about this issue and pitfalls of actually getting that kind of help in this post. Recipes and downloadable profiles sound great in theory, but often lead to more issues than they solve, which is why I tend to shy away from them.

Asking for help with Tasker really should be a last resort. Searching for information yourself and trying out different things should be your first priorities when you’re stuck, and I’ve even written a post with some tips and tricks for finding your own mistakes. I make a lot of mistakes with Tasker myself, and I can normally figure out what’s wrong by simply assuming that I did something wrong rather than assuming something’s broken or give up.

That being said, there’s a massive Tasker community out there that is willing to help anyone who has problems. All I ask is that you treat that as the privilege it is, not as a matter of course. You can also leave a comment on any article written by me on this site, and I will definitely read it. I normally reply to all intelligent questions, though I have been known to “forget” to reply to questions from people who went straight for the “help me” option.

Final thoughts

A lot of people come to Tasker thinking it’s like any other app, where you can essentially become an expert at it in no time at all. Unfortunately, it’s not that easy. Learning Tasker is an investment, requiring time, patience, and the willingness to learn how to do something yourself. It’s not for everyone, but for those who do stick with it, it’s well worth it.

]]>https://www.pocketables.com/2013/06/beginners-guide-to-tasker-part-0-tips-and-tricks-for-learning-tasker.html/feed2377664Beginner’s guide to Tasker, part 1.5: Tasker basics (New UI)https://www.pocketables.com/2013/05/beginners-guide-to-tasker-part-1-5-tasker-basics-new-ui.html
https://www.pocketables.com/2013/05/beginners-guide-to-tasker-part-1-5-tasker-basics-new-ui.html#commentsWed, 15 May 2013 08:54:27 +0000http://www.pocketables.com/?p=76068Back in 2012, I wrote a beginner’s guide to Tasker that currently consists of 7 parts. With the UI overhaul

Back in 2012, I wrote a beginner’s guide to Tasker that currently consists of 7 parts. With the UI overhaul that Tasker got a couple of months ago, however, a lot of the references, screenshots, and videos from that guide are now hard to follow, since it’s in many ways a new app. The basic concepts still apply, but it looks and is organized differently. Since this first part of the guide is many Tasker user’s first stop after getting the app, I wanted to post an updated version.

This article contains the same information as the original, just based around the new UI. Since the old UI is still being used on older versions of Android, I’m leaving the original article as it is, and just adding this one on top. So, if you’re using Tasker with the new UI, read this one, and if you’re using Tasker with the old UI (i.e. on an Android version lower than 4.0), read the original version of this article. If you’re not sure which version you’re using, look at the screenshots and see which matches what you have.

A part 0 has been added to the guide, talking about what Tasker is and how you can go about learning it. It’s available here. This part of the guide therefore jumps straight into talking about how Tasker itself works.

Tasks, profiles, projects, contexts, scenes, variables, and actions

These seven terms are important to understand in order to use Tasker. When reading through the over 100 (and counting) Tasker articles on the site, as well as the rest of the guide, these terms will be used to refer to very specific things, so common mistakes like confusing “task” and “action” can throw someone completely off.

Actions

An action is the most basic part of Tasker, a thing that the app does. Switching off WiFi is an action, going back to the home screen is an action, starting Angry Birds is an action, turning down the media volume is an action. Tasker have over 200 basic actions, and most of them have configuration options that make them capable of doing different things, like how the Media Controls action has five different options for which button it should emulate. Linking actions together allows you to do some truly amazing things with Tasker, things that go far beyond changing a setting or two when you leave the house.

Tasks

Actions are grouped in tasks. A task can have a single action, or it can have hundreds, it all depends on what that task needs to achieve. Tasks can also be triggered with actions, so that a task can have several actions that run individual tasks, each with their own actions. This way you can group actions together into more meaningful tasks, and it allows you to reference a set of actions from different tasks. For instance, you might have a set of actions that set screen brightness, volume, WiFi settings, and so on a certain way. If you need to use those settings in more than one task, you can turn them into a task of their own, and then simply run that task from within the other tasks, instead of having to copy each individual action.

Tasks can be triggered either by contexts, or directly using shortcuts, widgets, and other methods, like through third party apps.

Contexts and profiles

A context is a trigger. An incoming notification, the opening of an app, or connecting to a certain WiFi network are all examples of contexts which can be used to trigger a task. If you want the GPS to turn on when you leave the house, you could for instance use not being connected to your home WiFi as the context, and have that trigger a task with an action that turns on GPS.

Unlike tasks, contexts can’t “live on their own.” They’re always the first part of a profile, and a profile consists of up to four contexts and one or two tasks. A profile is what links tasks and contexts together, deciding which task should run when the context triggers.

There are two types of contexts, state contexts and event contexts.

A state context makes a profile be active as long as the context is, so if the context is being connected to a specific WiFi network, the profile will be active for as long as the device is connected. State contexts have two types of tasks, enter tasks and exit tasks. An enter task is the default, and runs when the profile becomes active. An exit task on the other hand runs when the profile is deactivated.

It’s important to understand that Tasker doesn’t enforce anything you specify in the enter task while the profile is active. By that I mean that if you change the screen brightness in your enter task, and then change it to something else using the system settings, Tasker won’t change it back until the profile has been deactivated and then reactivated. Think of it as a door that rings a bell when it opens; it will ring that bell every time it opens, but leaving the door open won’t make the bell ring continuously.

Another important thing to know about state contexts is that some settings will automatically be reverted when the profile is deactivated. So if you change the brightness in your enter task, it will change it back when the profile exits, without you having to tell it that. You can disable this by long pressing on the profile name, clicking the settings button that appears on top, and then uncheck “Restore Settings”. Not all settings are automatically restored, however, and it’s mostly limited to system settings like brightness.

Event contexts on the other hand is never continuously active. It makes the task attached to it run once, and then it’s done. An example of an event context is Received text, which is when you receive an SMS. Receiving an SMS is something that happens instantaneous, meaning it’s not something that becomes active and then later becomes inactive, which is what makes it an event (there’s no practical difference between when you start receicing an SMS message and you’re finished receiving it). Profiles with event contexts don’t have exit tasks, and they don’t restore settings.

In cases where there are multiple contexts in a single profile, the relationship between them is AND (e.g. context 1 and context 2), meaning that both contexts have to be fulfilled in order for the profile to trigger. If a mix of event and state contexts are used, the profile will follow event profile rules. An example is a combination of a WiFi state context and a Received Text context, which when combined, creates the trigger “when I receive a text message while I’m connected to this WiFi network”. If you then specify your work WiFi network in the WiFi Connected context, you suddenly have a profile that triggers when you get SMS messages at work, but not anywhere else!

To add multiple contexts to a profile, you first create your profile with a single context, then long press on that context in the profile list (tap the profile name to expand it if the context and task is not visible), and select Add. To add an exit task to a profile, or to turn an enter task into an exit task, long press on the task in the same manner.

You can have multiple state contexts in a profile, but only one event context. This is logical, because since event contexts are instantaneous, it’s practically impossible that two of them happen at the exact same moment.

Variables

A variable is like a virtual text file within Tasker, or like a variable (X, Y, A, B) in math. A variable is represented by a % symbol followed by a name, like for instance %Variable1. Variables are used to get access to system information, transfer information between parts of Tasker, and even work as settings and options. The variable %DATE will for instance always be the current date, so if you were to tell Tasker to create a notification with the text %DATE, then %DATE would be replaced by the actual date when the notification appears. Variables are key to advanced Tasker use, and is a huge topic to cover in itself. I go through it in other parts of this guide, starting with part 2.

Scenes

A scene is essentially a customized user interface. You can user Tasker’s scene functionality to create menus, pop-ups, settings boxes, and much more. This is a very useful and complex feature that I also cover in greater detail in a later part of this guide.

Projects

A project is the final grouping in Tasker. Think of it as a folder capable of holding all of the above, so that you can keep everything related to a specific Tasker system in one place. The more complex Tasker setups often use multiple profiles, multiple tasks, and even multiple scenes all working together. You can group all of those together in a single project to stay organized, and projects are also vital when using Tasker’s app export capability, since they allow you to export a whole range of tasks, scenes and profiles as one single app.

The Tasker screen

Tasker has a beginner mode that is designed to make the app easier to use for beginners, by disabling certain features. It’s a good idea, but unfortunately you won’t find many people referencing this version of the UI when you read about Tasker online, so I recommend disabling it. You do this in Tasker’s main preferences.

As such, I’ll be basing this guide on the normal Tasker look, not beginner mode. Since this article is a rewrite of a guide for the pre-ICS version of Tasker, it also goes without saying that this and any future versions of the guide based on the new UI will be based on the ICS+ design. More specifically, the theme I use is the Light theme, which is selectable in the UI section of Tasker’s preferences.

Knowing the difference between the various terms I explained above is half the battle when it comes to understanding how the UI works. The image above should help explain what everything is, but it’s worth mentioning that holding down or single tapping on parts of the UI is the way to access a lot of features. It’s the way to import and export items, add more contexts to a profile, switch out tasks, turn enter tasks into exit tasks (or vice versa), and so on. Also, to delete items, you grab the right part of the screen besides their name (where the enable/disable toggle is for profiles) and drag them down to the trash can that appears. This is also how you sort items and transfer them to other projects: drag and drop.

What Tasker requires to work

When Tasker is active, there will be a persistent notification icon present in your notification bar. This is to make sure the system will never close Tasker, as Tasker obviously needs to run at all times to work. You can also look at this notification in the notification drop-down to see which state profiles are currently active. To prevent a profile’s status to show here, long press its name in Tasker, go into its settings, and disable the Show in Notification Pulldown option.

Some features in Tasker, specifically the ability to read notifications from other apps, require that Tasker has accessibility access. This is a system-level access that you have to manually give to Tasker by going to the device’s main system settings, accessibility section. This, along with Tasker’s long list of required permissions, might sound scary because of Google’s way of phrasing its warnings, but every permission Tasker requires is there for a very good reason, and it’s not malicious.

Tasker also requires device administrator privileges for certain features, like manipulating the status of the lock code. This also has to be enabled manually, and if you do enable it, you will have to manually disable it to uninstall Tasker. This is another system level Android thing that you can read more about here.

There are dozens of plug-ins for Tasker, giving Tasker lots of new abilities. These plug-ins are available in the Play Store, and install as normal apps. Tasker shares the plug-in system with another automation app, Locale, and so many Tasker-compatible plug-ins are listed as Locale plug-ins. Furthermore, some apps have Tasker compatibility built in, meaning that installing the main app also unlocks the plug-in components in Tasker. The plug-ins can be accessed from either the third party or plug-in parts of Tasker (in the list of other actions/contexts) depending on whether the plug-in was built into Tasker or got installed on the side. If the accompanying app is installed, there’s no practical difference between actions listed in the third party section and those listed in the plug-in section, other than the name of the category they’re listed in.

Being rooted is not required for Tasker, but it does give it more abilities. The availability of certain actions and contexts is dependent on the device and software version/ROM, and being rooted can unlock features that are otherwise unavailable on a certain device. Tasker can also use root to kill apps, manipulate files, and so on. The plug-in Secure Settings allows you do access a lot of otherwise blocked features via root, and is a valuable tool.

Please note that Tasker taps into so many features that differences between devices and ROMs is sometimes a problem. You might read about an awesome Tasker creation online, go to replicate it, and find that some part of it isn’t working. This doesn’t mean Tasker is broken, or that you did anything wrong, it likely means that the feature you’re trying to use doesn’t work properly on your device or ROM. In those cases it’s more productive to complain to your device or ROM creator, not the Tasker dev, or the person whose creation you’re trying to copy. The truth is that you’re much better off by reading about how things can be done in Tasker, and then explore that on your own, than to try to copy someone else’s creation step by step. That’s because that will teach you why something works, and in the process help you understand why something doesn’t work, and maybe even how to fix it.

Creating your first profile

The best way to learn Tasker is to tinker with it and explore, like I just said. The configuration for each context, each action is different, and so it’s hard to generalize. The image below explains some of the buttons and options that are fairly common in the configuration screen for actions, while skipping those that are more unique to that particular task. Each action and context has different options however, and with the amount of contexts and actions in Tasker, not to mention plug-ins, explaining each and every one is impossible. The harsh truth is that if you expect there to be a 20 page user’s guide to every single option in Tasker, you’re better off just uninstalling the app right away.

There is however some documentation for more or less all the features and settings in Tasker, though often it’s just very quick explanations.

I simply cannot emphasize enough how important self study is for using Tasker. This article, the more than 100 others I’ve written, and posts and articles from people around the web are great resources, but at the end of the day, you’re the person who needs to set up Tasker the way you want it. Is it worth the hassle? Oh, definitely!

The video below shows the creation of a simple state profile with an enter task and (later) an exit task. My advise is to play around with the various contexts and actions and see what happens.

So where do you go from here? The banner below links to our Tasker portal page, which has a boatload of articles that you can look at. It also has links to the other parts of the beginner’s guide. So far only this first part is available in a version for the new UI though, so I advise playing around with basic features in Tasker before reading further. While there are some notable changes to the UI in the new version, Tasker hasn’t really changed, so the top priority of any new Tasker user should be to understand the basics, in order to be able to understand information written for the old UI.

If you ever need to import anything into Tasker, please see this video for instructions.

]]>https://www.pocketables.com/2013/05/beginners-guide-to-tasker-part-1-5-tasker-basics-new-ui.html/feed1476068Beginner’s guide to Tasker, part 7: Variable arrayshttps://www.pocketables.com/2012/10/beginners-guide-to-tasker-part-7-variable-arrays.html
https://www.pocketables.com/2012/10/beginners-guide-to-tasker-part-7-variable-arrays.html#commentsWed, 24 Oct 2012 15:11:28 +0000http://www.pocketables.com/?p=58603Back in part 4 of the guide, I briefly mentioned variable arrays. I said then that I wasn’t going to

Back in part 4 of the guide, I briefly mentioned variable arrays. I said then that I wasn’t going to go into more detail, as it would only complicate things. Now that we’re a few iterations of the guide further along, however, it’s time to dwell into this yet unexplored part of Tasker variables.

What’s an array?

Arrays are common in many areas, from mathematics to programming. In Tasker, an array can be described as a base variable which have several child variables. When you use Variable Split on the variable %Hello, you end up with a bunch of child variables like %Hello1, %Hello2, %Hello3, etc. %Hello is then an array with several elements, each element being a variable in itself.

So far nothing new, perhaps with the exception of the terminology – we’ve been using child variables throughout the guide. Each element in an array is a variable, so it can be used as a variable, which is how we’ve been using arrays for so long without calling them that. However, what makes arrays special is what you can do with them in addition to what you can do with normal variables. Because variables in an array is arranged in a way that can very easily be referenced, we suddenly have a whole new set of tools that we can use to manipulate the variables on an array level, rather than treat them as individual variables.

To use arrays, you need to get out of the mindset as variables as single entities. When referring to an array, it’s common to either refer to them by their base variable (like %Hello) or in the format %Hello(). The former is accepted as the input into several array-specific action settings in Tasker, some of which we’ll look at later. %Hello() on the other hand will list the value of each variable in the array, separated by a comma.

If you were to split %ingredients = sugar.milk.flour by the period, you’d end up with the array %ingredients containing %ingredients1 = sugar, %ingredients2 = milk, and %ingredients3 = flour. Adding a Flash action for %ingredients would then flash sugar.milk.flour, because the value of the single variable %ingredients is still sugar.milk.flour. Flashing %ingredients() however would tell Tasker to take the value of each child variable and separate them with a comma, so you’d get sugar,milk,flour. If you were to clear the variable %ingredients and repeat the flashes, you’d get an empty %ingredients on the first, and the same sugar,milk,flour on the second. This is because the array remains even though you cleared the variable that created it in the first place. If you similarly were to clear the array %ingredients, the first flash would be unaffected, while the second would just flash empty variables.

This can be a bit confusing, because %ingredients can refer to the single variable %ingredients or the array %ingredients. Perhaps the most common mistake when dealing with arrays is to refer to one when you mean the other, causing whatever you do to be based off a single variable instead of an array, or vice versa.

Referring to arrays

Since arrays are numbered lists of variables, you get some new ways to refer to them. The list of these ways are available in the official user guide, so I’ll just quote them here:

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:

%arr(#)The number of defined array elements (4 in this case)

%arr(#>)The index of the first defined array element, or 0 if none are defined (1).

%arr(#<)The index of the last defined array element, or 0 if none are defined (4)

%arr(#?b/c)A comma-separated list of the array indices (lowest to highest) with matching values, or 0 if none match (2,3 in the example)

%arr(>)The contents of the first defined array element (a)

%arr(<)The contents of the last defined array element (d)

%arr() or %arr(:)All of the array elements separated by commas (a,b,c,d)

%arr(2) or just %arr2The content of the element with index 2 (b)

%arr(2:4)Contents of defined elements with indices 2 to 4 (b,c,d)

%arr(:3)All the defined elements with indices up to 3 (a,b,c)

%arr(3:)All the defined elements with indices starting from 3 (c,d)

%arr(1:2)All the defined elements with indices from 1 to 2 (a,b)

Keen eyes might recognize the first of these, %arr(#). That’s because we used it in an example in part 5 of the guide, to count the number of lines in a text files. What really happened was that we read a text file into an array, each line being a new variable in the array. Using (#) behind the base variable then makes Tasker count the number of variables in that array, which in turn is the number of lines.

You will of course also recognize %arr() here, which is the same as what we just talked about above. These methods listed above show us different ways of referring to arrays, allowing us to for instance refer to the last element in an array without knowing what number that is.

One method that is missing here (because it’s not exclusive to arrays) is the format %arr(%variable). Assuming you have a %variable with a numerical value, you can refer to the array element in that spot in the array by using this format.

How arrays are created

As for how you make arrays, I already covered Variable Split. I’ll once again quote the official user guide on this, since it has it pretty much nailed down:

using Variable Split:Variable Set %arr a,b,c,dVariable Split %arrIf your data has commas in it, you can separate the values with e.g. @ and specify @ also in the Variable Split action.

some other actions also create arrays for their results e.g. List Files

Variable Split is perhaps the most common source for arrays, although some other actions, like List Files mentioned here, can also create them. Other than that, you can also create them manually with Variable Set or Variable Push.

For loops

The For and End For actions are found together with If, Else, and End If actions in Tasker. Like If/End If, For/End For creates a group inside the task, where nested actions are visible nested in that group. The initial For action can be a bit confusing, but once you get a hang of it, it’s actually very powerful. It asks you for a variable, as well as a comma separated list of items. For each item in the list, the For action will run the actions in the For group with the current item as the value of the specified variable. For instance:

For, Variable: %itemtoflash, Items: hello,world,how,are,you

Flash: %itemtoflash

End For

This would loop the group, in this case the lonely Flash action, one time for each item in the list, in this case 5 times. Each time, the variable %itemtoflash will be updated with the next item in the list, starting with “hello”, ending with “you.” 5 flash messages appear, each with one of the items from the list.

The benefit of this system is that you can specify a set of actions and then run a whole bunch of values through it without needing to duplicate the actions for each time. It takes some getting used to, as you for instance need to make sure that if you save something with each, that file name has to be unique for each item.

Example: Todo list V2

Recently I decided to redo my entire todo list system (which is described in part 3 of the guide) to give it better performance and more features. The system I came up with uses arrays at its core, and is quite a bit more effective than the old one. I also added a new generic todo list that doesn’t trigger any alarms, along with redoing my three situation-specific lists. I’m going to cover the generic list here as the trio adds a bit of complexity to it all.

The first todo list system I created in Tasker used methods that weren’t ideal. Adding to the list was done by saving to a text file, a file that was read into a single variable and showed in a text field. The benefit of this was that the list would be formatted for reading in the text file directly, each line being separated by a line shift, and with no use for a more direct splitter. The downside was that the entire list became a single entity, making single selection impossible and whatnot.

The new list is based around arrays. Each list is still stored in a text file, but the text file is more of a backup feature than it is the main storage for the items. Instead, the items are stored in a global array, which is directly compatible with the text file by writing %Array() to the text file (writing the value of each array element, separated by a comma), and reading it back into a variable which you then split by the comma (reverting it back into array form).

The array can then be used as the source for a menu scene element, which most people are familiar with through the Menu alert action, which automatically populates a scene with such an element for you. You can use that element on its own as well, and by using an array as the source, it creates a menu list where each array element is an item in the list. The items in the list can both be selected and tapped, which means that we suddenly have the tools needed to make the todo list a bit more like a third party todo list app – i.e. each item can be selected.

Trigger task

There’s quite a bit that’s needed to make this work, starting with the trigger task. It looks like this:

Variable Set %Gtselectedd to 0 (resets a variable used later. Double D is not a typo)

Array Pop %Gentodo, Position 1, If %Gentodo doesn’t match ++ (removes the first entry in the list if it’s blank. I frankly don’t remember the circumstance where that was needed, but I’m sure I had a reason for it when I did it)

Show Scene Generic Todo

The scene: Menu element

The menu element is the heart of the scene, covering most of it. Source is here set to Variable Array, and Variable is then %Gentodo. Note that since source is an array, variable refers to the base variable of the array in order to also know what the array is. Had it asked for a variable, %Gentodo would have been treated as just that single variable. Selection Mode is set to Multiple, since I wanted to be able to select multiple items.

Note that menu scene elements have internal scenes. The Item Layout option has a scene besides it that can be clicked and edited. It determines how each item looks, and it’s pre-populated with a dynamic text field and a dynamic icon field. Those will be populated with data from the menu element’s source, but you can still use this to choose how it will end up looking. You can also add more to it yourself. My generic todo list has a static image of a holo themed pin in front of the text field, which ends up looking like a bullet point when the menu element is fully populated. Aside from having a few predetermined elements, this internal scene is the same as the scenes you’re used to.

The Item Tap tab task for the menu scene element contains the following:

Variable Set %Gtselected to %select_indices

Variable Split %Gtselected, Splitter: ,

Variable Set %Gtselectedd to %Gtselected(#)

%select_indices is an automatically generated variable (one of four, the other three being %select_labels, %tap_label, and %tap_index) that is populated when you interact with the menu scene element. It contains a comma separated list of the item number of the selected items, starting at 0 (this will be changed later). So, if you select items 1, 3, 5 on the list, %select_indices will show 0,2,4.

%Gtselected(#) counts the number of items in the array %Gtselected, which is then put into %Gtselectedd. In short, %Gtselectedd shows the number of selected items.

So, by the time you’ve selected something in the menu scene element, you have an array with the numbers for those items as well as a variable with the number of items selected. That brings us to the delete function.

Warning: There’s currently a bug where %select_indices doesn’t clear itself if you deselect the last item. As such, there’s no system here to handle that situation. Basically, as it is now, you have to refresh the entire scene to properly deselect the last item.

The scene: Delete button

The delete (X) button in my scene has two functions: simply cancel out of the scene, and delete items. The first is handled by a simple Destroy Scene in the Tap tab task. Deleting items is more complicated, and is triggered by holding down on the button. The actions in the Long Tap tab task are as follows:

So, lots of nested stuff here. The first If simple makes sure that there are selected items before you try to run some delete task on them. Keen eyes may have noticed that while we reset %Gtselectedd in the launch task, there’s no Variable Clear for %Gtselected. That means that the last values in the %Gtselected array persists, however, because the entire delete task is nested in an If for %Gtselectedd (which is reset every time), we won’t ever get a situation where we accidentally delete last time’s selected items. On top of that, it effectively disables the Long Tap task if nothing is selected.

The Menu action that sits as the first action in the If group must not be confused with the menu scene element that I’ve referred to so many times. This action simple creates a new pop-up box using the standard menu action, in this case with Yes and No items in order to create a simple confirm dialog. Clicking Yes sets a variable that the following If group is dependent on. That variable is also reset at the end of the task, so that it’s always 0 unless you click Yes to confirm deletion.

Next we have our For loop. It runs the four nested actions once for each element in the array %Gtselected. The Items field here wants a comma separated list, not necessarily an array, so we give it the %Gtselected() form. For each element in the %Gtselected array, the value of that element will be written to %gendelete, used in the following four actions, and then it goes on to the next element, putting its value in %gendelete, and so on.

As for the four nested actions, the first simply fixes a “developer brain fart.” Right now, menu items start at 0, while array elements start at 1. So, the value of array element 1 is the same as menu item 0. This will be fixed soon according to the Tasker developer:

Will fix that, it should be the same as the tap indices obviously.
It’s going to cause problems for some people’s scenes, but it’s too silly to leave like that.

By adding 1 to %gendelete, which in turn contains the number for the selected menu item, we bring that number up to the level of the array, so that menu item 1 is the same as array element 1.

When those two match, it becomes very easy to remove things from the array, using the third action in the For loop, Array Pop. By simply using Array Pop with %gendelete as the position, we pop out the array that’s in that position in the list. The other elements in that array then get pushed down so that if you remove the third array element in a five element array, number four becomes number three.

Wait, you skipped an action! Yes, on purpose. The second action in the For loop, combined with the fourth, fixes an inherent issue with this system. The first time the loop runs, the array element numbers will match the menu item numbers, once we have added 1 to compensate for the difference in starting position. However, because all the array elements get pushed down when we remove an element, the numbers won’t match after the first time!

Let’s say we have 10 items in the list/array, and we select number 3 and 5. %select_indices will then show 3,5 (always in order, no matter which one you select first). The For loop then pops element 3 from the array, leaving us with 9 elements, where the previous number 5 is now number 4. When the For loop then comes around to pop number 5, it pops what was number 6 when you selected the items

To fix this problem, we add 1 to %shuffle at the end of each loop. %shuffle then represents the number of times the list has been shrunk. The Variable Subtract action in spot two of the group subtracts this number from the number of the element we’re going to pop, but only if %shuffle actually has a value (the If condition takes care of this). If we delete 5 items, then the number of the fifth item will have to be adjusted down by 4 in order to match up.

When the loop is done looping, it’s time to write the changes to the file. Unlike the first version of the todo list, we here overwrite the entire file, because we have all the information in the array – so the file is outdated. By writing %Gentodo() to the file, we write a comma separated list of items to it. When we then read that back into a variable, and then split to an array the next time we open the scene, we simply split by the comma.

At this point we end both our If groups and move to the three actions that can always run, if only for the sake of it. We essentially clear %Gtcd, %shuffle, and%Gtselectedd, so that they’re ready to go next time. I didn’t actually think %shuffle needed clearing since it’s a local variable, but it turns out that if you were to delete something in several batches while in the scene, %shuffle would continue counting with the last used value if not cleared.

The scene: Selected item indicator

There’s a text field on the bottom of the scene showing “%Gtselectedd items selected.” It’s as simple as that.

The scene: New item button

The button to add a new item isn’t very complicated. The Tap tab task looks like this:

Variable Query, Title: New item, Variable% gentoadd

If %gentoadd doesn’t match *gentoadd*

Array Push, name: %Gentoadd, Position, 9001, Value: %gentoadd

Write File, File: gentodo.txt, Text: %Gentodo()

End If

This task is simple. It starts by using the Variable Query action to ask the user for the title of the item to add. It then does an If check to see if something was actually entered into the variable. If so, it uses Array Push to add that to the array. By specifying a very high position (it’s over 9000), you’re pretty much guaranteed that the array is smaller than that, and in those cases, it simply adds it after the last one. So, if you have a 10 element array, then add a new item, it will become number 11, not number 9001. After that, it writes the changed array to the file.

A nice side effect of using arrays is that when the file contents are read into the variable, a comma that you put in is treated the same as a comma that originally separated array elements. This allows you to add multiple items in one go by adding an item in the format 1,2,3,4,5. Once added, it will show as a single list item with all numbers in one, but when the list is refreshed (scene destroyed, relaunched) each of the items seperated by a comma will be its own item. This does mean you can’t use commas in the titles as the title will then be split, but I think the benefit of being able to add a bunch of items in one go makes up for that.

The scene: Refresh button

Alerts

This is my generic list, which is new (I used to just use a widget), but the three other lists I have (home, shopping, morning) also use this new array system. The basic concept is the same, just slightly different to accommodate three lists in the same scene.

Those three lists all have different alerts, so you’d assume that those needed changing – but they don’t really. They all work by reading the contents of the file, checking to see if there’s anything in the file, then acting based on that. Items are now separated by a comma instead of line shift, but that doesn’t affect the alert systems.

AutoRemote integration

All my todo lists can now be added to remotely from AutoRemote. This system had to be changed when I redid the todo system itself. The format for adding is the same, i.e. “todo tag=:=item name,” just with the addition of a generic/universal list tag. The task that activates upon receiving a message in that format then has four If groups that are all identical except for the variables and file paths being adapted to each list. The If condition for each group is then a match with the appropriate tag. For the universal list, this group looks like this:

By now you know what all of these do as they’ve been used before. The only real difference is that it pushes %arcomm into the array instead of %gentoadd. Like I said, there are four such groups in the same task, one for each of my four lists. At the end, independent from the If groups, is this:

Say “Item added to %arpar2 list”

AutoRemote Chrome integration

So far I’ve only used the AutoRemote Chrome plugin to copy text from my browser to my phone. I thought I would make it easier to add items to my list, so I simply added a bunch of rules to the Chrome plugin. Each rule has a name that doesn’t really matter, and a command like “todo shopping.” This then allows me to select text in Chrome, right click, and send to my todo list (receiving end is the same as above). It’s a very handy option to have, as I can just go to any search field (like on google.com), type something in, right click it, and send to any of my lists.

Video

Update: Tasker beta 1.3.2b2 and above

Turns out that the array/menu numbering difference and the deselect bug have both been fixed in the latest Tasker beta, which means that the next release version will also have them fixed. The change in the todo list is that you don’t add 1 to %gendelete with the fix, and the Item Tap tab task in the menu scene element should be like this:

If %select_indices doesn’t match *select*

Variable Set %Gtselected to %select_indices

Variable Split %Gtselected, Splitter: ,

Variable Set %Gtselectedd to %Gtselected(#)

Else

Variable Set %Gtselectedd to 0

End If

In conclusion

Arrays and For loops can save you a lot of hassle. Right now there’s something of an issue with global arrays and menu scene elements, where the whole thing slows down significantly because the global variables have to be set all the time. It doesn’t matter much on a small todo list, but in a later article I’ll show how to make a Tasker-based file browser, where it does matter. I originally made such a browser using arrays and found it to be extremely slow, and after some help from another Tasker user, it turned out that arrays were extremely inefficient in that particular situation. There may very well be a V3 of this list somewhere down the line, as I already know several ways to speed it up. Even so, the current iteration works great, at least for my use.

]]>https://www.pocketables.com/2012/10/beginners-guide-to-tasker-part-7-variable-arrays.html/feed2858603Beginner’s guide to Tasker, part 6: AutoRemotehttps://www.pocketables.com/2012/09/beginners-guide-to-tasker-part-6-autoremote.html
https://www.pocketables.com/2012/09/beginners-guide-to-tasker-part-6-autoremote.html#commentsMon, 01 Oct 2012 06:55:50 +0000http://www.pocketables.com/?p=45445The previous 5 parts have showed how much there is to know about Tasker itself, but that’s only half the

]]>The previous 5 parts have showed how much there is to know about Tasker itself, but that’s only half the story. The extensive selection of third party plug-ins for Tasker extends its functionality in all sorts of ways, from triggering from NFC tags to controlling home automation systems. One of the latest additions to the Tasker plug-in market is also one of the most powerful, and it’s called AutoRemote. Put simply, it allows Android devices to communicate with one another, and with computers. The era where your phone didn’t know what your tablet was doing ends here.

What is AutoRemote?

Mobile devices can communicate with one another, but in ways designed with the user in mind. SMS, email, video chat, IM, and so on are all services designed for the user, not the back end. AutoRemote on the other hand is a communication system designed for the devices to communicate, without the user having to be part of it. It allows messages to be sent between devices that have been registered as a group, instantaneous, and without bothering the user. Ever wish your phone could notify you of your tablet battery running low after days of being idle? AutoRemote gives the two the channel needed to communicate that kind of information.

It does, however, not do so entirely on its own. While AutoRemote has grown beyond its original dependency on Tasker in some areas, it’s still very much a Tasker plug-in. After all, something has to manage the messages, act on them, and send them. Tasker already has the ability to collect practically any data, so with AutoRemote there to allow it to communicate that data to other devices, you have what you need to create setups that make iOS devices look like they’re from the last century.

Getting started with AutoRemote

AutoRemote can be had from Google Play for $1. Once installed and opened, it will fetch your personal URL, which will be in the format http://goo.gl/RandomCharacters. This URL is both used for registering your device with other devices, and for accessing AutoRemote’s web access. Opening the URL in a browser will present you with a page where you can send messages to your device, as well as instructions for accessing AutoRemote’s second personal code, the key, which is used for some parts of the AutoRemote eco system.

Back in the app, you can access the menu to get into the list of registered devices. Here you can register a new device by using the personal URL of that device, and this way connect devices together. You’ll have to do this on both devices in order for both of them to be able to send messages to the other. Any devices registered in this list will be available as an option when you go to send a message.

Once this is done, AutoRemote’s Tasker-independent features will be ready to go. Try going into Google Play, go into an app page, select Share, and then remote open URL. This will open the same page on the other device, showing you that it’s set up correctly.

Tasker context

AutoRemote adds both contexts and actions to Tasker, so let’s start with the context. It’s available in Tasker’s State context category, under Plugins. There’s quite a few settings available in the configuration screen, so let’s go through them all.

Plugin Options

Event Behaviour: The AutoRemote context is a state by default, but as you can imagine, you’ll want it to behave as an event in many situations. Checking off this box does that. Note that Tasker still thinks the context is a state, just one that turns on and off quickly, so if you use this to change settings that Tasker normally revert automatically – like screen brightness – you need to uncheck “restore settings” in the profile options.

Target: One of the methods for filtering messages. Specifying a target in the context and the message allows you to control which messages trigger the context without matching the message itself.

Matching Options

Message Filter: The main method for filtering messages. This one allows you to specify text that should be part of the message for it to trigger the context. It’s a partial match system, so “message” will match “this is a message.”

Clear Message Filter: Clears the message filter, which isn’t the same as simply making the message filter blank, as that actually creates a blank message filter that will make it react to all messages.

Case Insensitive: If checked, the message filter will be case insensitive

Exact Message: Makes the message filter require an exact match, whereas the default is a partial match system as mentioned above.

Message: The name of the variable you want the message to be transferred into. Default is %armessage

Comm Params Prefix: Part of a system to allow you to send more advanced commands using AutoRemote. The basic syntax for this is parameters=:=command. To use an example from AutoRemote’s Google Play description (also example 6 below), this can be used like this:

You can use AutoRemote with other Tasker conditions, such as the Date and Time conditions. Create a “shop=:=” command and combine it with a 5PM condition. Then, share your personal AutoRemote URL with your wife and have her send stuff she needs you to buy like “shop=:=carrots and ice cream”. Then, at 5PM your phone could say that list out loud: “You need to go shopping! You need to buy carrots and ice cream”

There can also be multiple parameters in a single message, separated by a space before the command separator =:=. This settings controls the name of the parameter variable(s), and the default is arpar. This system will be easier to understand with the examples further down.

Command: Controls the name of the command variable created from using the =:= system.

Main settings: For accessing AutoRemote’s general settings.

Tasker action 1: AutoRemote Message

The AutoRemote context helps you trigger profiles based on incoming messages, and the message action allows you to send messages. Like the context, it has a few options as well.

Device: Select which device to send the message to, or, alternatively, a channel (see below) or the last sender.

Device Type: Selected automatically based on the setting above

Message: The message you want to send

Channel: Channels are connection groups that multiple devices can join to be part of the same network. If this option is used, a channel connection will be made with the receiving device. This allows that device to simply reply to a channel instead of having to specify a device. Don’t confuse this with the Channel option under Device – this one allows you to send a message to a specific device and at the same time enable a channel, whereas sending a message to a channel sends a message to that channel. The description below from the AutoRemote developer might help understand channels better:

To better understand what a channel is, imagine channels as chatrooms. When you enter a chatroom, you start receiving all messages in that chatroom. The same happens with channels. Also, when you exit a chatroom, you stop receiving messages from it.

Advanced settings

Time To Live: The amount of time the system will try to deliver the message before it gives up

Message Group: Allows you to make the message part of a message group, basically categorizing the message. You can then specify how to handle multiple messages from the same message group. An example would be if your tablet lets your phone know what it’s doing, but your phone has been off, so there are several such messages queued up, and you only want the last.

Target: Corresponds to the Target option in the context

Password: If AutoRemote has been password protected in the main app on the receiving device, you need to specify the password here for the message to get through.

Send Message: Allows you to test send the message

Tasker action 2: AutoRemote Channels

The second available action is for managing channels. The available options are:

Name: Name of the channel to manage

Device: All devices by default. If specified, the changes apply only to a specific device.

Clear chosen device: Clears the above setting

Enter of Exit: Makes the specified device enter or exit the specified channel

Exit all: Makes the specified device exit all channels

Apply now: Let’s you apply the settings right away instead of running the action.

AutoRemote for Windows

There’s a program available for Windows computers that expands the AutoRemote network there. On its own, the program is very similar to AutoRemote on Android. You can add devices, send messages, and receive messages. URLs can be opened in a browser when received, and on top of that, you can create rules for incoming messages, similar to profiles in Tasker. This enables you to run commands upon receipt of certain messages, for instance by tying it to programs like nircmd.exe to use it to turn off your PC at night (which is what I do).

AutoRemote EventGhost plugin

The Windows program also has a tab which allows you to install and manage an EventGhost plugin. EventGhost can best be described as Tasker for Windows, a program that automates you computer in much the same way Tasker does your Android device. The way it works is similar, but still different enough that you basically have to learn an entirely new Tasker-like program to be able to use it properly. There’s an example further down which shows a very basic setup with EventGhost, but I can’t start going into EventGhost in detail here – especially since I haven’t used the program much myself.

With the EventGhost plugin installed, there will be a couple of new actions available in EvenGhost. One is for registering EventGhost, which basically means that the action lets your AutoRemote network know that it’s there. It should be run on EventGhost startup, and will then make EventGhost an available device on your Android device.

The other action is for sending a message. The options available here are identical to the other places you can send AutoRemote messages, so I won’t go into detail. Note that EventGhost has to be registered to the device you want to send messages to.

To actually trigger an EventGhost macro (similar to Tasker profile), you need the event that a message creates. The simplest way to get this is to set up the message you want to send from your device, set it to send to EventGhost, and then send it. This will make the event appear in EventGhost’s log, allowing you to drag it into a macro. Like I said, EventGhost is different enough from Tasker to be alien to new users, and I won’t turn this into a EventGhost guide.

AutoRemote Chrome extension

AutoRemote also has a Google Chrome extension available. It’s relatively new, but the beta made a cameo in the video to example 2 in part 4 of this guide, where I open a URL on my phone by right clicking in my PC browser. The extension adds an option to send text to one of your devices when right clicking in Chrome, which you can use to send URLs or entire parts of a web page.

Example 1: One device letting another know what it’s doing

When I talked about how Android has ruined iOS for me, I mentioned that I’m expecting my phone to know that I’m on my iPad, and in turn let it notify me of emails instead of my phone. That was a reference to a very real possibility on Android, which uses Tasker and AutoRemote. Here’s how that would work.

Option 1: When the tablet is in use at all

Create a new profile in Tasker on the tablet. As the context, use the Display State option under State -> Display. Configure it for the screen being on. This makes the profile active when the tablet’s screen is on.

As the enter task, add a AutoRemote Message action. Configure it to send the message “tabletstatus active=:=” to the phone. Then, add an exit task, and configure a similar message with “tabletstatus inactive=:=.”

On the other device, create a new profile. Select AutoRemote, enable event behavior, and set message filter to “tabletstatus.” For the task, add a Set Variable %Tabletstatus to %arpar2. You will now have a global variable which will be either “active” or “inactive” based on the status of the tablet.

You can now do what you want with that. If you have a email notification profile, you can for instance add a Variable Value %Tabletstatus matches inactive to it to make it stop triggering if you’re using your tablet. You could also add a Say action to the AutoRemote-triggered profile and make it say for instance “Tablet is now %arpar2,” which would give you a vocal message for when the tablet is in use. This latter example is shown in the video below (it might not be obvious that it’s the phone that speaks, but it is).

So what exactly is going on with all the =:= and %arpar2 and whatnot? Well, we want to send a message from the tablet that is unique to the screen on/off scenario, and we want it to contain information about the state of the tablet. By using messages in the format “tabletstatus (in)active=:=,” we’re activating AutoRemotes command system, which puts parameters before the =:= and commands after. We don’t need commands here, but we do need two parameters. The first (tabletstatus) is static, and simply lets us filter this particular message for use in the context on the phone. The second parameter is “active/inactive,” based on the state of the tablet. By enabling the command system with =:=, AutoRemote splits the message into (by default) %arpar and %arcomm variables. %arpar2 is the second parameter, which is here “active/inactive.”

We can then transfer this “setting” to a global variable on the phone and use it elsewhere in Tasker, or we can simply use the local variable %arpar2 in the same profile (which is the case with the Say example). When the tablet turns on, the Display State On context becomes active, runs the enter tasks, which then sends a message to the phone that the tablet is active. When the screen turns off, the profile deactivates, and the exit tasks sends a message saying it’s inactive. In reality it’s such a very simply profile, but in practice, it gives one device the ability to act on the state of the other.

Note that such a profile can become a nuisance if it’s constantly going off when you’re for instance just trying to check the time on your tablet. Part 5 of this guide covered how to set up profile delays properly, a system that should probably be implemented in a setup like this.

Option 2: When a specific app or feature is being used

Making the phone aware of when the tablet is in use is great, but what if you only want it to be aware of when specific apps or features are in use? The concept is practically the same as above, depending on what exactly you want it to be aware of. If you want your phone to know when your tablet is connected to a specific WiFi network, has headphones plugged in, or anything like that, then all you really need to do is switch out the Display State context on the tablet with whatever context fits. If you want it to be aware of when a specific app is being used, however, it’s a bit more complicated – but not much.

Tasker has a built in variable for the so-called window label, which is the name of the window (i.e. app) that is currently being displayed. This variable is %WIN, and is updated as the window name changes. If you make a profile with the event profile Variable Set %WIN and tie it to an task with Flash %WIN as the action, you can move around your device and see the window name displayed as a flash message as you move between apps, giving you an idea of how this works and what names are used for apps. It’s normally pretty straight forward, like Netflix’ window name being Netflix or Gmail’s window name being Gmail.

Point is, there’s a variable that basically tells you what’s being displayed on the screen. By using the Variable Set %WIN context in place of the Display State context in the setup above, switching out “active” with %WIN” in the enter task, and deleting the exit task (since it becomes an event profile), you can make the tablet send the name of the active window to the phone. The %arpar2 variable will then be the active window, which you can use as a trigger for various things. An example would be to set the phone on silent if you’re using an ebook app on the tablet.

Note that this particular method would send every single %WIN change to the phone. It’s a good idea to filter this somewhat before sending the message, to avoid it spamming the system. If you need your phone to know when your tablet is using Netflix, you can set it to only send the message if %WIN matches Netflix, rather than filtering it on the phone end.

Example 2: Gmail notification that opens up Gmail on the PC

Example 4 in part 3 of this guide showed how my Gmail notification system works. If certain contexts are met (such as being at home), it displays a Gmail logo on the screen when an email comes in. This can then be clicked to open the Gmail app on the phone. Since I posted that part though I added a long tap feature to the logo, an AutoRemote message to my PC for gmail.com.

The task is almost identical to the tap task for opening the phone’s Gmail app (so see the original example for that), it just sends an AutoRemote message instead. That message automatically opens in the browser on the PC, which means that simply holding down on the Gmail logo when it pops up opens Gmail on the PC.

This is a very simple system, but one I use a lot. When emails come in while I’m at home, I can either view them on my phone or my PC, all thorough the notification itself.

Example 3: Forward notifications to a PC when it’s on

This example is based on a setup that the AutoRemote developer himself uses. It uses AutoRemote and EventGhost to create a system where notifications are forwarded to the computer when it’s on.

First you need to go into EventGhost. Select Configuration, Add Plugin, and find AutoRemote under Other. Configure it with a name, and add a device to the list of devices. Not right click the Autostart tree in the list and select Add Action. Find the Register EventGhost action under AutoRemote. Select the device you added, and enter “notification” as the channel. Click OK, and make sure it’s nested under Autostart.

Next, add a macro. Give it any name. Right click the macro, select Add Event, and enter “AutoRemote.Message.osd” in the field. Finally, right click it again, select Add Action, and then Show OSD under EventGhost. Enter “Message from phone: {eg.event.payload.arcomm}” into the “text to display” box. Save the EventGhost configuration, then restart EventGhost.

Now go to Tasker on your device. Create a new profile, and select the Notification context under Event -> UI. Don’t add any filters to the configuration. As the connected task, create a new one, and add AutoRemote Message as the action. Select to send to channel as the device, then enter “notification” in the channel field further down. In the message field, enter “osd=:=%NTITLE.” Save out of Tasker, go into AutoRemote, and check that it’s set to drop PCs that can’t be reach from channels automatically (that should be the default setting anyways).

That’s it. When the computer is on, the title of notifications on the phone will appear as a message on the PC. So, what’s going on here?

The Register EventGhost action in EventGhost lets the device know it’s active, and by running it on startup, that happens when the computer turns on (assuming EventGhost is set to autostart). Macros as the profiles of EventGhost, and dropping events and actions into macros tie them together like contexts and tasks in Tasker. In this case, we have a event for an incoming message containing “osd” and an action to display an OSD (On Screen Display) that contains EventGhost’s version of the %arcomm variable from Tasker. This means that when a message starting with “osd” is received, it displays the command variable (the notification title in this case) on the screen.

It’s easy to get confused here, because we’re not just in Tasker anymore. EventGhost uses different methods for events and actions, with variables in a completely different format. To really get the most out of making these two work together, you should probably read an EventGhost tutorial – which I won’t be writing, because I don’t know EventGhost very well myself.

Example 4: PC letting an Android device know what it’s doing

This example is similar to example 1, but with a PC as the device we’re checking in on. Assuming you’ve not messed too much with the default setup of EventGhost, the log on the side should show what happens on the computer from EventGhost’s point of view. This is a great feature, because it’s a list you can drag and drop events from! If you for instance switch to Skype, the log will show the event “Task.Activated.Skype.”

Assuming you did the steps in example 3 to activate the plugin and register EventGhost on startup, it’s now very simple to use these events. Add a new macro, give it a name, and then drag and drop the event you want from the log and into the macro. If you want to send your device a message when you’re using Skype, the “Task.Activated.Skype” and “Task.Deactivated.Skype” events are the ones you want, as an example.

Next, right click the macro, and select to add an action, then find Send Message under AutoRemote. Send whatever message you want to send, you know the drill by now. For my Skype example, I simply made the message “skypeon.”

Now, in Tasker, create your profile. Use AutoRemote as the context, and filter the message by whatever you made the message “skypeon” in my case. Make the task whatever you want to do – the point of this example is the EventGhost/AUtoRemote end, not what you do with it in Tasker.

A possible use for this can for instance be if you play online games and want the phone to for instance be quiet or use louder notifications when you’re doing that. You’d then make AutoRemote set a variable based on a message from EventGhost, trigger a silent profile based on that variable, and reset the variable using a message for when the computer program closes. Again you might get a use for the delay system from the previous guide in order to avoid having quick window switching trigger profile changes.

Example 4.1: Turn you phone into an automatic control pad for specific computer programs

This is more of a tip than an example, but I thought I would include it. Both EventGhost and NirCmd allows you to send keypresses to the system, and both of those can be used via AutoRemote (NirCmd directly from the AutoRemote Windows program). By using scenes, you can create custom interfaces with buttons that send AutoRemote messages to your computer, which then trigger keyboard input there. Imagine having a Photoshop scene that has buttons for copy, paste, levels, select, and whatever other tools you need as buttons in the scene. By tying this to a system where the computer notifies the device when Photoshop is running, you can create a scenario where starting up Photoshop on your computer automatically makes a control panel for it appear on your phone.

Example 5: Copy text from Chrome to a device’s clipboard

I mentioned the Chrome extension above, which I have had installed for quite a while now. As per the AutoRemote dev’s suggestion, I set it up so that I can copy text from Chrome on my computer directly into the clipboard on my phone.

When you have the Chrome extension installed, register your device, make a new rule, and then set command name to “Copy,” and the command to “copy.”

Next, go into Tasker, and create a new profile. Add the AutoRemote context, and set “copy=:=” as the message filter. Select Event Behaviour. Tie the context to a new task, and find the Set Clipboard action under Misc. Put %arcomm in the text field for this action.

With all this configured, you should have a new option for AutoRemote where you can copy the selection or open URLs on registered devices.

Example 6: Remote access todo list

EventGhost and Chrome extensions are all good, but it’s important to not forget what started AutoRemote: Web access. That personal URL you get can be entered into a browser to give you a page that allows you to send messages to the device from any web browser, which is much easier than needing special software.

One of the examples on the Google Play page for AutoRemote is a scenario where a wife sends grocery list items to her husband, which will then be spoken out loud when he leaves work. Such a scenario is actually quite easy to set up. Make a new profile in Tasker, add the AutoRemote context, and set the message filter to “shop.” Add a task with a Say action with “You need to go shopping! You need to buy %arcomm” as the text, and then add a second context for the time the person leaves work (the time you want the message to play) in the same profile. The message should now play at that time, and the message (grocery list) can be added to by using the web interface to send “shop=:=shopping items here” to the device.

Note that this is a “dumb” version of such a system, where only the latest message will be read, it’s time based, and so on. By using methods from previous articles you can store any new list items in an actual list, add to that list with new messages, and have the message play based on for instance leaving a WiFi network rather than a specific time.

In conclusion

The guide continues on in part 7. More parts will come eventually, though at a much slower pace.

]]>https://www.pocketables.com/2012/09/beginners-guide-to-tasker-part-6-autoremote.html/feed4245445Beginner’s guide to Tasker, part 5: Tips & trickshttps://www.pocketables.com/2012/09/beginners-guide-to-tasker-part-5-tips-tricks.html
https://www.pocketables.com/2012/09/beginners-guide-to-tasker-part-5-tips-tricks.html#commentsMon, 24 Sep 2012 11:59:26 +0000http://www.pocketables.com/?p=43906The previous four parts of this guide have been thorough, but this is Tasker – thorough only covers a small

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

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

Name: %date

From 1, Length 2

Store result in %dd

2. Variable Section

Name: %date

From 3, Length 2

Store result in %mm

3. Variable Section

Name: %date

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

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:

File: dinner.txt

To Var: %dinnertext

2. Variable Split:

Name: %dinnertext

Splitter: |

3. Variable Set:

Name: %dinnerrandom

To: %dinnertext(#)

4. Variable Randomize:

Name: %dinnerno

Min: 1

Max: %dinnerrandom

5. Variable Set:

Name: %Dinnersuggestion

To: %dinnertext(%dinnerno)

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.

Do Maths

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.

Counting things

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.

Test

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.

Notification contexts

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.

In conclusion

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.

]]>https://www.pocketables.com/2012/09/beginners-guide-to-tasker-part-5-tips-tricks.html/feed2443906Beginner’s guide to Tasker, part 4: Variable data processinghttps://www.pocketables.com/2012/09/beginners-guide-to-tasker-part-4-variable-data-processing.html
https://www.pocketables.com/2012/09/beginners-guide-to-tasker-part-4-variable-data-processing.html#commentsThu, 13 Sep 2012 18:12:48 +0000http://www.pocketables.com/?p=43705With the basics, variables (in general), and scenes now all covered, it’s time to dig into something a bit more

With the basics, variables (in general), and scenes now all covered, it’s time to dig into something a bit more specific: Processing data using Tasker variables. It’s more of an implied feature than the previous topics, but it’s also (in my opinion) one of the most powerful features in Tasker.

Variable data processing?

I’m kinda making up terms here, but it’s as good a term for this aspect of Tasker as anything. By variable data processing, I’m referring to how you can work with data stored in variables, extracting information from it, creating your own contexts, and so on and so forth. I have multiple profiles and tasks that use this in my Tasker, and some of them have been posted on this site before. The calendar event announcer and the weather forecast announcement system are both examples of variable data processing. It’s all about taking some data – text, in other words – and working on it until you get what you need from it.

Data sources

To really understand the power of variable data processing you first have to realize how many potential data sources there are out there. More or less anything that is stored in text form can be used in Tasker, it’s all about knowing how. Websites, exported calendar data, text documents – all of them are potential data sources. If you see some text, you can most likely use it in Tasker – it’s that simple. Weather data, local news, moon phases, horoscopes, Pocketables articles, you name it. Want to create a profile that is active when your horoscope mentions money? No problem.

It’s also important to understand the difference between what you see and what a computer sees. A web page is seen by the computer as pure text, a mixture of references to images, text, rules for how to lay out the page, and so on. CTRL + U brings up the page source of a web page in most web browsers, allowing you to see what the computer sees – the web page in pure text form. The chaos of text that greets you when you look at the source can be frightening at first, but as you’ll see further down, it can also be extremely useful.

Reading data into variables

The first part of any system based on outside data sources is to get the data into a variable, where we can work with it. There are many ways of doing this, but some of the most important ones are Read File, HTTP Get, Get Voice, and Variable Query – all of which are actions. The examples will focus on data gathered with HTTP Get though, as that’s the hardest to work with, and the most powerful.

Read File reads a file stored on the internal memory into a variable, like the contents of a text file.

HTTP Get is used to get (the source text of) a webpage into a variable, %HTTPD.

Get Voice is used to listen for voice input, which is then turned into text and stored in a variable, %VOICE. This is the foundation for a DIY voice assistant like my Nelly.

Variable Query pops up a dialog box asking for a variable value. Great for things like quick todo list entries, Tasker-based accounting systems, URL archive, and so on.

HTTP Get

HTTP Get (found in the Net action category) is perhaps the most versatile data collection action of them all, as it allows you to load web pages into variables. It does however have some quirks here and there. In theory, it loads the contents of the web page into the built-in variable %HTTPD. On some devices however, like mine, %HTTPD simply doesn’t contain the right data (or any data) after using HTTP Get. In such cases, using HTTP Get’s option to save to a file, combined with Read File to get it into a variable, is an excellent workaround. In examples further down you’ll see this approach a lot, though I should point out that simply using HTTP Get to populate the built in %HTTPD variable is the “proper” way to do things – when it works. Then again, to actually work with the data you have to have it in a user created variable, meaning you have to copy the contents of %HTTPD to another variable, leaving you with just as many actions as if you use HTTP Get and Read File.

In the HTTP Get configuration screen, you’ll see several fields, the top two being Server:Port and Path. As a general rule, put anything before and including the domain (like .com) in the first field, and the rest in the Path field. For instance, the URL

In theory, the contents of this URL should then be available in %HTTPD after the actions runs. If not, use the Output File field to save it to a file (e.g. pocketables.txt) and then use Read File on that file.

Data processing tools

Once you get the data into a variable, the job of actually turning it into something useful begins. Often, especially if you load entire web pages into a variable, the variable becomes an epic mess of text. It’s always a good idea to do this type of Tasker setup in front of a computer, so that you can have the full text available in front of you. If you’re working with a web page, for instance, have the source code (CTRL + U) of the page in front of you to get a better look at what is in the Tasker variable. You’ll see me do this in the video in example 2.

Next up I’ll cover some of the most common tools you’ll be using when working with the data. These are all actions that manipulate the content of a variable, and as such, are located in the Variable action category. I won’t cover all, but I will cover the most important ones.

Variable Split

Congratulations, you just met the single most important action there is for this kind of Tasker setup. Variable Split could just as well be called Variable Chainsaw or Variable Ninjasword, as what it does is that it cuts/slices variables into pieces. It has two relatively simple configuration fields: Name and Splitter. Name is the name of the variable you want to chop into pieces, and Splitter can best be described as the point in the variable where you want to split it.

For instance, let’s say you have a variable %Hobbies that contains the text “football,hockey,swimming”

If you then use a comma (,) as the splitter, the “chainsaw” will target all of the commas and cut the variable in those spots. The actual splitters will be destroyed in the process. This creates new variables that are numbered derivatives of the original, each containing a piece. In this case, you would get the following variables:

%Hobbies1: football

%Hobbies2: hockey

%Hobbies3: swimming

You just used the commas as points to split a single variable into smaller, individual pieces. This method is the alpha and omega of variable data processing. By choosing the right splitters you can chop huge variables containing entire web pages into small, manageable pieces that contain just the information you need. You can split a weather website into variables that contain just the weather forecast, or split a news site into just the titles.

This is where all the “weird” text in a web page comes in handy. All the tags that are used to assign formatting to specific parts of a web page can very often be used as splitters as well, allowing you to grab parts of a web page much more easily than you’d think from seeing just the text. By using the source on a computer together with CTRL + F (find text on page), you can feel your way to finding a good splitter.

As an example, let’s take a look at pocketables.com. Let’s say that we want to create a list of articles currently on the front page, both links and titles. We load the page into the variable %Pocketables. Looking at the source in a browser (which is also what’s in %Pocketables at this point), we see how each article is listed in the source code:

All the tags (like <h3>) in between the text are what decides how the page looks to you – it’s like a guide for telling the browser how to display the page. You see the visual result, but Tasker sees this code when you load a web page into a variable like this. This is a good thing, as we can use these tags as splitters.

In this case, we see that the link to each article is immediately preceded by <h3><a href=”. By using CTRL + F in a full browser and searching for <h3><a href=” in the source, we see that there are only 10 occurrences, which means it’s only used before each of the ten articles on the front page. If there were 20, we could assume that it was used twice for each article. If there were 175, we could assume that it was used all over the place. We want the splitter to be as exclusive as possible, and in this case, <h3><a href=” would give us 11 “child” variables (as the first child variable would contain what’s before the first occurrence of the splitter, hence giving us one child more than there are splitter occurences).

%Pocketables4 would then for instance contain all the text between <h3><a href=” number 4 and <h3><a href=” number 5. As you can see from the image above, this is still a lot more text than what we want:

However, as you can see, the URL is immediately followed by ” title=”. This means that if we split each child variable again using this splitter, the first of the second generation child variables will contain the URL, and only the URL. An example of such a variable would be %Pocketables41. This is not the 41st child variable, but rather the first child of the %Pocketables4 variable.

%Pocketables42 will then contain everything following ” title=” up until the end of the original %Pocketables4. This variable starts with the title of the article, and then has lots of “garbage” at the end. Using the same method as we did to get the URL by itself we split %Pocketables42 using the splitter “>, which is the text immediately following the title. We’re then left with a third generation child, %Pocketables421, which contains just the title of the article.

To summarize, here’s a code snippet with relevant parts highlighted. The three pieces of red text are the various splitters used, blue is the second generation child (%Pocketables41 in the example), and purple/pink is the third generation child (%Pocketables421). The text at the end is just a shortened version of all the garbage that we cut away.

<h3><a href=”http://www.pocketables.com/2012/09/tv-show-favs-for-android-hits-version-3-0.html” title=”TV Show Favs for Android hits version 3.0“>TV Show Favs for Android hits version 3.0</a></h3>

By using this simple splitting method, you can chop up data into the chunks you need. You here have two variables that can be used directly elsewhere, for instance you could have a Open URL action with %Pocketables41 in the URL field and a Say action with %Pocketables421 in the text field, and have Tasker open a URL while speaking the title of the page it’s opening.

In this case, you would need to do this splitting process 10 times in order to get all 10 front page articles into separate articles. That creates a lot of actions and a lot of variables, and remember that every split creates variables you don’t need. As such, it’s wise to use local variables (lower case letters) for this type of work, as those won’t end up populating the Variables list in Tasker. I used global variables in the example, which can be smart if you need to refer to the resulting variables in other tasks and don’t want to copy them into global variables, but just be aware of the side effect and make a choice based on that.

I should point out that it’s possible to automate the process of splitting multiple variables multiple times, using Tasker’s For action, which essentially loops an action for each available specified variable or value. This is done by using arrays, which are essentially base variables with childs. The variable %Pocketables above is an array containing %Pocketables1, %Pocketables2, and so on. It is then possible to specify a set of actions that will run for each variable in an array, like for instance all children of %Pocketables. I won’t go into the use of arrays in more detail however, as it’ll further complicate an already complicated topic. My advise is to stick with the “manual method” until you’ve mastered it. Besides, unless you’re doing a ridiculous amount of variables, the “manual” way can often be easier to keep track of.

Also note that if you split into more than 10 parts, your second generation variables will start to be named the same as first generation variables. For instance, %Pocketables11 can be the 11th child of %Pocketables or it can be the 1st child of %Pocketables1. If the first generation %Pocketables11 is important, you don’t want the second generation %Pocketables11 overwriting it when it’s created.

Keeping track of all the child variables is often very hard, which is why you should play around with what splitter you use. It’s sometimes wiser to split multiple times in order to create lower numbered children instead of trying to cut as close as possible the first time around. Had you for instance been after only the title in the example above, ” title=”might have seemed like a good option for an initial splitter, since it immediately precedes the title. However, there are (at the time of this writing) 99 occurrences of that splitter in the source code for this site’s front page, which means that you would have to hunt around for which 10 of those 100 actually precedes a post title. You would then end up for for instance %Pocketables57 and %Pocketables71 as the relevant first generation children. Not only is this harder to deal with than a static naming scheme, but common splitters in web pages often vary in numbers as the page is updated, meaning that tomorrow it might split away something completely different. The naming scheme %Pocketables/2-11/2/1 created by the example method above, on the other hand, doesn’t have this problem.

Like I said, it’s a mess, which is why it’s not a bad idea to have a version of the text you’re splitting open on a computer while you’re working. That combined with CTRL + F to find text makes it so much easier to “cut the right spots.”

Variable Section

Variable Split might be the most important tool available for this type of work, but it’s not the only tool. Another great one to know how to use is Variable Section, which is designed to pick a specific part of a variable and throw the rest out the virtual window. Unfortunately it doesn’t section based on splitters, like you wouldn’t be crazy to assume, but instead it sections based on character numbers.

The Variable Section configuration screen has five options to be aware of. The first is the Name, which is simply the name of the variable you want to section. The second is the character number you want to start at, for instance if you want to skip the first three letters in a variable, you choose 4 here. Length is the length from that character that you want to include in the sectioning, for instance choosing 5 here would just fit the word “apple.” Adapt to fit changes the previous option depending on the length of the variable, so you don’t try to section ten characters of a five character variable. Very useful if you don’t know the length of the section, just where it should start. Finally, Store Result In lets you save the result to a different variable than you started with.

So, what’s this feature for? Well, I find that it’s great for cutting off the beginning of variables that contain info they shouldn’t. Often this means variables that contain data you can’t split away because it’s different every time, or because the splitter you would have to use is so ridiculously common that it would somehow create issues.

For instance, let’s say you want to split the time (hours and minutes) out of a variable like this one:

13:30:52.000-04:00

Sure, you could split with a colon as the splitter, but that would also split the minutes from the hours. You could end up with variables in the form of %timesplit1, %timesplit2, and timespit3, which would be 13, 30, and 52.000-04, respectively. You could then reassemble the time by doing a Set Variable %timesplitx to %timesplit1:%timesplit2, and end up with a %timesplitx that is 13:30.

OR you could simply use Variable Section from 1 with length 5 and get a variable with 13:30 right away.

In many cases, Variable Section is an alternative to Variable Split, but it’s an alternative that can often save you a lot of work. Knowing that it’s there and when to use it can be very handy.

Variable Search Replace

Variable Search Replace is a relatively new feature, and one I have mixed feelings about. In theory, it should replace Variable Split for a lot of tasks. In practice, it’s a feature that’s frankly still in beta.

Problem 1 is that it doesn’t use Tasker simplified pattern matching system, it uses actual regular expressions. As such the method to use a wildcard isn’t * any more, it’s .* (note the period). If you’re used to pattern matching for If conditions, and don’t have experience from anything that uses actual regular expressions, this will make it that much more complicated to use.

Problem 2 is that it doesn’t support variables. If you type a variable into the field, it will use the variable name, not the variable content. According to the Tasker developer this has been on the todo list to fix for several months now, but it still isn’t fixed.

Bottom line, Variable Search Replace is a bit of an ugly duckling in the Tasker toolbox right now, one that is still a ways from turning into a beautiful swan. Because of this, I don’t want to spend too much time on it in this guide, but I will give you a quick example of how it can replace Variable Split in some cases.

In the Pocketables front page example above, we split out the URL by splitting multiple times. You could actually achieve the same by using Variable Search Replace and the following search string:

<h3><a href=.*”

This would search for any mention of <h3><a href=”, followed by the non Tasker-standard wildcard (.*), ending with a “. This would return results (separate variables for each match) along the lines of this:

The wildcard is here the URL, which we’ve “fenced in” by placing a wildcard in the string between two pieces that border it. We have to use <h3><a href=” here in order to catch the right URLs (not all the URLs in the code), and “ is needed to stop the wildcard from including absolutely everything following the URL. As such, we end up with some garbage information at the beginning and end. We can Variable Section from 1 length 13 to get rid of the beginning, but due to the varying length of the URL, we need to either Variable Search Replace or Variable Split the “ to get rid of that. So, you’re left with three actions anyways, meaning that it isn’t exactly infinitely superior to Variable Split. Personally I use Variable Split more or less exclusively, because at least I know where I have it with regards to pattern matching syntax and variable support.

Example 1: Weather forecast

Preperation

This is the how-to version of the weather forecast task found in this article. Since it was originally made as a download for people to use without understanding how it works, I’ll go through this example referring directly to the downloadable task. That way, you can download and import the task yourself, and “read along” as I explain the bits.

Download the task from below. Two versions are available, a direct .xml download and a zipped version. On some devices, you can go to this page in your browser, long click on the .xml download, select “save link”, open it once downloaded, and then select to open with Tasker. If that doesn’t work, download the .zip, and unzip it to the Tasker/tasks folder manually. The resulting steps are identical regardless of which of these methods you use.

Go into Tasker, long click on the Tasks tab, select Import. Select the Weather task.

Open the task, then the HTTP Get action. Switch out YYYYYYY in the Path field with your location. This can be a US zip code, State/City, or Country/City. Examples are 90210, CA/San_Francisco, and Norway/Hamar – with the slashes included. Then, switch out XXXXXXXXX with a Wunderground API key. You can get such a key for free by signing up for Wunderground: http://www.wunderground.com/weather/api/

This will not work without you obtaining your own API key. Random numbers or any of the examples used here won’t work in real life.

Make sure there are no spaces or other “irregularities” when you insert the API. The resulting Path field should look something like this:

api/123a123b123c/conditions/forecast/q/Norway/Hamar.xml

The bold text indicates the pieces you replaced.

Finally, go into the Say action, click on the magnifying glass next to Engine:Voice, and select a Text To Speech engine that you have installed.

Task download

Explanation

Actions 1-2:

The weather data is available online in XML format, which we can get our hands on using HTTP Get. Like I explained earlier, I prefer doing HTTP Get into a local file and then read it into a variable using Read File rather than use the HTTP Get-generated variable %HTTPD. By the end of action 2, the result is that you have a variable %Weather that contains everything in the XML file.

Action 3:

This is the first Variable Split. At this point, you should have the XML file open in a full browser (or text editor) in order to be able to see what’s in it. If opening it in your browser brings up an RSS message, try using CTRL + U (show source) on the page.

The first splitter used here is <fcttext><![CDATA[. This splitter is chosen to get as close to the description of the weather as possible, which you’ll see if you search for it in the source text. Note that some browsers “organize” the tags in such a way that it won’t be able to find this specific splitter using search. If that happens, just search for the first part of the splitter (up until >), or just look at this screenshot (click for larger image):

As you can see, the first forecast follows immediately after this splitter. This means that %Weather2 will contain the forecast plus a lot of garbage text, while %Weather1 is all the garbage text before the splitter.

That’s not all though. Since all the forecasts are “labeled” the same way, %Weather3, %Weather4 and so on will also be created. These contain weather data for future periods, similar to how %Weather2 is for the coming period. Again, %Weather1 is just garbage text.

Note: If you want the metric version instead of the imperial version of the forecast, use the splitter <fcttext_metric><![CDATA[. This will make it use units like km/h instead of mph. You can see the logic of this by studying the screenshot above.

Actions 4-5:

These are both Variable Split actions with ]]> as the splitter, one for %Weather2 and one for %Weather3. These simply cut off the garbage from the end of those variables, leaving you with the child variables %Weather21 and %Weather31 that contain the weather forecast and nothing else. This particular version of the task uses forecast information for two upcoming periods, which is why we’re cleaning up %Weather2 and %Weather3, but not %Weather4 and so on. If you want more periods, simply add more Variable Split actions like these for more %WeatherX variables, and use their %WeatherX1 children in the Say task at the end.

Actions 6-10:

Technically, you’re done getting the weather info after actions 4-5. You then have %Weather21 and %Weather31 which you can use however you like, be it in a Say action to give you a spoken forecast or perhaps to send to a Minimalistic Text widget to display somewhere. Actions 6-10 are however there to figure out if the second of the two upcoming forecasts is at night or in the morning. This is basically a fancy feature that isn’t strictly needed, but I added it originally to make the whole thing more “professional.” It also uses Variable Split, so I’ll explain how it works.

Action 6 copies the contents of %Weather2 into a new variable, %Nforecast. We’re going to split %Weather2 again using new splitters, and we don’t want to overwrite the existing child variables, so we’re making a copy in order to avoid this issue.

Action 7 is a Variable Split for %Nforecast with <title> as the splitter. Remember that %Weather2 (which %Nforecast is a copy of) is already a child, so it looks for the splitter in an already limited part of the original document. As such, there’s only one <title> in %Nforecast, even though there are many in the original source text. I’ve marked the parts that aren’t in %Nforecast with red below to demonstrate this.

Point being, this split results in a %Nforecast2 that contains the title of the second forecast period as well as a garbage </title> at the end.

Action 8 deletes this </title> by splitting %Nforecast2. This creates a %Nforecast21 which contains the title of the second forecast period.

Action 9 creates a variable %Nextforecast and sets it to “tomorrow.”

Action 10 overwrites the variable created in action 9 with the text “tonight” IF %Nforecast21 matches *night*/*Night*. This means that if the title of the second forecast period contains the word “night,” the value of %Nextforecast will be “tonight.” If it doesn’t contain that word, the value from action 9 (“tomorrow”) will stay.

At the end of these five actions, we have a variable that is either “tomorrow” or “tonight” depending on whether the second forecast period is the coming night or the next morning. If the forecast task is run early in the day, the first forecast period will be for that day, and the second will be for that night. If it’s run later in the day, the first forecast period will be that night, and the second the next morning. %Nextforecast lets us know which of those two are correct.

Action 11:

This is the Say action that actually gives us the spoken forecast. The text is:

Weather forecast for today is %Weather21. Weather forecast for %Nextforecast is %Weather31.

This Say text contains three variables. Two of them are the weather forecasts we got from the XML online, while the last, %Nextforecast, changes the text to correctly specify when the second forecast period is for.

Like I said though, you could easily skip actions 6-10. It only loses you the ability for the Say to correctly specify when the second forecast period is for, which might not matter to some – and likely not if you’re using this in a widget. It is however a good example because it uses data from the original XML source as an If condition, not just an information source. You could just as easily have used it in a Variable Value context, which has a lot of uses in situations where the variable in question isn’t just day/night.

Of course this example also extracted actual information, the weather forecast itself. The method is basically the same no matter what you do, you just have to know where to chop a source text up to get what you want.

Example 2: Local news fetcher

This example originates from a help request in our forums, where a forum member wanted to create a task that would fetch his local news and read it to him. The recipe is the same as I’ve already shown, but since this is a task I had to create from scratch, I fired up screen capture software on both my phone and PC and recorded what I was doing, while narrating. It should help visualize this entire article, as well as show a trick with using a Flash action as a “debug tool” when creating tasks like this. The video is below.

The website used as a source this time is this one. Checking the source for a bit revealed that the best splitter to start with is <h2>, which doesn’t immediately precede the headlines we’re after, but does have the advantage of not being used all over the place.

After splitting that first time we got variables %lbnews1, %lbnews2, %lbnews3 and so on, with %lbnews2 and beyond containing the headlines – along with some garbage text. Splitting %lbnews2 using the splitter ” > puts the headline at the beginning of the variable %lbnews22, but still leaves a bit of junk at the end. A final split of %lbnews22 using the splitter </a> leaves us with a variable %lbnews221 which contains only the headline, which can then be used directly in actions within the same task, or transferred to a global variable and used elsewhere.

Since the initial split created multiple children that share the same format as %lbnews2, just with a different article, we can then copy the actions that split %lbnews2 and %lbnews22, and simply replace the variables with %lbnews3 and %lbnews32, respectively. We then get %lbnews321, which contains the second headline – and nothing else. Copying again and doing the same with the number 4 would give us the third headline in %lbnews421, and so on and so forth for as many of the headlines you need. Each headline will then be in its own variable which can be used in a Say action or something else.

Like I said earlier, there are ways to automate this beyond manually copying the actions for each child, but for the sake of simplicity I won’t go into that.

Task download:

The downloads below contain the finished task with 5 complete headline variables. It can be edited to change the number of headlines it splits out of the source if necessary.

Follow the instructions for downloading and importing in example 1 to get this into Tasker. The final action, which is a Say, has to be edited to specify a different voice engine if the Amy UK English Ivona engine I’m using for my text to speech is not installed.

Example 3: Google calendar event announcer

Another explanation of a task I’ve given you a download for before. This time it fetches data from Google Calender using Google Calendar’s ability to access the calendar with a web link, in XML format. Like with example 1, I’ll give you a task you can download and import, and then I’ll go through and explain how it works.

Preperation

Download the task from the bottom of the article. Four versions are available: A direct .xml download and a zipped version for each of the two basic task versions, DDMM and MMDD. Which of the basic versions you need depends on the date format you use. This task only works with the date formats DD/MM/YYYY and MM/DD/YYYY. This is a setting you pick in your device’s system settings, in the date and time section. It has to use one of those two, or it won’t work. If you read 07.12.2012 as July 12th, you want MM/DD/YYYY. If you read it as December 7th, you want DD/MM/YYYY.

Follow the instructions in example 1 on how to download and import the task.

Once imported, open the task, then the HTTP Get action. In the Path field, you will see XXXX and YYYY as part of the path:

These are the two pieces of information you have to switch out. XXXX needs to be replaced with your Google user name, e.g. “example” if your login email for Google is example@gmail.com. If your email for Google does not end in @gmail.com, you also have to change the bit after %40 with whatever domaing your email is. Examples:

YYYY needs to be replaced with a private access key for your Google calendar. To get this, start by going to the Google Calendar website, then go into settings. Click the Calendars tab, then the calendar you want to use. At the bottom of the calendar details screen, click the orange XML button next to Private Address. You should get a popup box with a URL that looks something like this:

Save the edit to the HTTP Get action and then find the Say action at the end. Select a speech engine that you have installed on your device.

Note: Recently created Google Calendar calendars use a different format with a randomkey@group.calendar.google.com email in the URL. This task has been tested to work with the new format, however you need to grab both the specialized email address and the key from the XML button mentioned above.

Task download

Explanation

This task was made on demand for a very specific purpose: Reading the next upcoming event, if that’s on the same day. This means it won’t list multiple events, although you can use the same method (with a different source URL that contains the right data) to make one that does, if you need that.

Actions 1-2:

Reads the data into a variable, like before.

Action 3:

Copies the variable into another variable, since we’ll be splitting it multiple times. We did this earlier too, with another variable.

Action 4:

Does a variable split of %Ceventdate, which is the copy of the calendar source data, using startTime=’. This contains the start date and time of the event. This splits it right up against the edge of the time information, and because we’re working more with it later on, we don’t cut off anything from the end of it right now.

Action 5:

Copies the value of %Ceventdate2 into a new variable, %Eventdate. Like earlier, this is because we’re going to use this variable multiple times, and don’t want any overwrites.

Action 6:

This splits the recently created %Ceventdate2 copy %Eventdate using the splitter –. %Eventdate contains data in the form of 2012-09-12T21:30:00.000+02:00, which means that splitting by a dash puts the year in its own variable, the month in its own variable, and the day of the month plus some garbage text at the end in its own variable.

Action 7:

This splits %Eventdate3, which is the third child from action 6 (the one with the day of the month plus garbage) using the splitter T. This is purely to clean up that last variable from action 6, removing the garbage.

Action 8:

Creates a variable %Samedayevent and sets its value to “no.” This is to make sure that the default value of this variable is “no,” in case the If condition in action 9 isn’t met. We’ve done something similar before, and without this, a leftover value from the previous time the task ran will still be present if the If condition in action 9 isn’t met.

Action 9:

Overwrites the value of the variable created in action 8 to “yes” If %DATE matches %Eventdate31-%Eventdate2-%Eventdate1. This one requires a bit of explanation, and will make it clear what the previous bunch of actions were for.

%DATE is Tasker’s built-in variable for the date. It’s in a specific format, the same as the device’s system settings – hence why there are multiple versions of the task download based on the date format used. %Eventdate31-%Eventdate2-%Eventdate1 takes the day, month, and year that we got from actions 6-7 and rearranges them to match the format that %DATE is in. That way, we’re able to compare the current date (%DATE) with the date of the next event, even though they’re originally in different formats!

After action 9, we have a variable %Samedayevent that’s either “no” (if the If condition in 9 wasn’t met) or “yes” (if it was). This variable is a setting that we will use later to control whether or not the Say action mentions the next event. Note that like I said, this task was originally created for someone who wanted this specific feature. Many people would prefer that it lists the next event no matter if it’s not on the same day. It is however a great example of how you can process a mess of data into something that’s even in the same format that Tasker is used to.

Action 10:

With action 10, we’re done with the actions that check to see if the event is on the same day. Instead we’re back to dealing with our original variable, %Calendar. We made a copy of this in the beginning, which we then split out to eventually get the date of the event, and now we’re going to work with the original. In this case I don’t think it would have mattered if we hadn’t copied it to begin with, but it’s always good practice to do it to be sure.

Anyways, action 10 does a Variable Split of %Calendar with the splitter <title type=’text’>. This is the text that immediately precedes the title of the event, and even though it’s not unique (it’s used once earlier in the source text), it’s ok to use it this time because there will always only be one occurrence of that text before the one we want. That just means that instead of using the %Calendar2 child, we use %Calendar3.

Action 11:

Does a Variable Split of %Calendar3 with the splitter </title>. This is just for cleaning up the garbage text at the end of %Calendar3, a procedure we’ve used many times by now.

Action 12:

Splits the variable %Ceventdate2 with the splitter T. We haven’t used the %Ceventdate “family” for a few actions now, but it’s still there for us to use. This time we’re after the time, not the date, so we’re starting over. The reason why we copied %Ceventdate2 to a new variable in action 5 was to be able to use it now.

%Ceventdate2 is identical to the original %Eventdate, so its value starts with data in the format 2012-09-12T21:30:00.000+02:00 as well. I believe we could have used %Eventdate32 directly instead of starting from this far back with %Ceventdate2, but the original task was made in somewhat of a hurry, and I don’t want to change the task in this example compare to the original article where it was a download only. Keeping track of all these child variables is a pain, and sometimes you get them mixed up. It is however better to be safe than sorry.

Action 13:

A real world example of Variable Section! Sections %Ceventdate22, which now contains data in the format 21:30:00.000+02:00*garbage*, to only be 5 characters long. That means we get the hours, the colon, and the minutes – the time, in other words. This is where the original example of Variable Section above comes from, and like I mentioned then, it saves us from having to reassemble the time like we would have had to do had we split it with a colon (as the colon is used in the time, too).

Action 14-15:

These two actions set the variable %Nextevent to either “Your first appointment today is %Calendar31 at %Ceventdate22” or “You have no appointments scheduled for today”, depending on the value of %Samedayevent, which can be “yes” or “no.” These are frankly redundant as we could have put actions 8-9 here and have them do it directly, but again it has to do with this task being put together a bit too quickly.

Action 16:

The final action, the infamous Say which actually turns 15 actions worth of work into a spoken message. Simply tells us the value of %Nextevent, which was set in the two previous actions. The result is that it has a different message for a day without appointments, and of course the message is dynamic and has the title of the event (%Calendar31 from actions 10-11) and the time (%Ceventdate22 from actions 12-13).

This task is long, and complicated, because of the use of different messages for different situations (event/no event). Without that feature, it would have been a matter of splitting out the event title, which is fairly simple (actions 10-12, basically). It’s often the minor details that take time, as this example proves, and sometimes that extra hassle isn’t worth it for some people.

In conclusion

Being able to process data in variable using Tasker opens up for a lot of possibilities, but there’s also a lot to keep track of when you’re splitting variables left and right. Keeping a steady hand, having the source text open for reference, and debugging using a Flash action (see example 2) are essential for getting through this without going crazy in the process.

In the next part of the guide I’ll cover some tips and tricks of using Tasker, things that didn’t really feel natural including in any of the previous parts but still deserve to be mentioned. Later on in the series I’ll do parts dedicated to examples of all sorts, so if you have a profile or task you just can’t figure out how to make, let me know and it might make it into an article as an example, like example 2 in this article did.

]]>https://www.pocketables.com/2012/09/beginners-guide-to-tasker-part-4-variable-data-processing.html/feed9043705Beginner’s guide to Tasker, part 3: Sceneshttps://www.pocketables.com/2012/09/beginners-guide-to-tasker-part-3-scenes.html
https://www.pocketables.com/2012/09/beginners-guide-to-tasker-part-3-scenes.html#commentsSun, 02 Sep 2012 11:40:01 +0000http://www.pocketables.com/?p=43087In the first part of this guide, I covered Tasker basics, and in the second part, variables. This time, I’ll

What are scenes?

Scenes are user interfaces that you can create in Tasker. Think of a scene as a box that contains various elements that you would normally find in an app interface, like buttons, text, text input, images, sliders, and so on. Normal Tasker actions can be tied to these elements, so that you can have a button that runs a task, a text field that lets you write text to a variable, or a slider that controls screen brightness.

Scenes can be all kinds of sizes, and be displayed in different ways: As a pop-up box, full screen like an app, as an overlay over another app, and so on. The size and type of scene depends on what you need the scene to do. I will quickly go through the basics of creating a scene, and then I will go through multiple examples at the end to show how everything works in practice and for different uses.

Creating a scene

Scenes have their own tab in each project, and you add a new one by tapping the plus symbol. The first thing you see after entering a name is a screen with a box in the middle, and a magnifying glass and ok/cancel buttons on the bottom. When the magnifying glass icon is not lit up with a green dot, you’re in the screen for editing the base “canvas” for the scene. You simply drag the edges of the scene to the size you want, indicated in pixels on the bottom. Currently there’s no way to set the size in pixels directly, something that will likely change now that scenes have a much bigger role due to Tasker’s app creation functionality. Also note that some aspects of how the scene will look are controlled by the action that triggers the scene, which I’ll cover later.

Clicking the menu button will bring up a few options such as grid size and background color. The background color picker is fairly self explanatory, but I should mention that the unlabeled slider controls transparency/opacity. The grid size option controls what grid is used for editing the scene, which affects the accuracy of placing elements on the scene. If you want three buttons of the same size side by side in the scene, you will need a grid size that allows for three identically sized buttons.

“Turning on” the magnifying glass makes a few new buttons pop up, and also shows the grid that you just set the size of on the scene. This is where you edit the content of the scene; add buttons, images, and so on. A few new buttons also appears on the bottom, specifically a teddy bear icon and a plus symbol. The teddy bear button lets you set the touch mode, with the three options being Normal, Move, and Resize. Normal means that you can both move and re-size elements in the scene, all depending on where on the element you touch (middle being move, edge being resize – but on small elements you often only get resize). The other two limit the editing to either moving or re-sizing an element. The plus symbol is for adding new elements to the scene, but you can also just hold down on the scene to get this option.

Holding down on existing elements allows you to do things like copy, delete, hide, pin, set depth, and so on. You can duplicate an element, set one element to display underneath another, pin it so it can’t be accidentally moved, etc.

Configuring elements

There are 11 different elements that you can add to a scene, and they don’t all share the same options. When you add an element, a configuration screen pops up, and there are multiple tabs of settings that you need to deal with for each element.

The UI tab (and background tab where applicable) is normally pretty self-explanatory for all elements, as it deals with how the element looks. Text size, name, text, color, position, icon, and label are just some examples of options you’ll run into in this tab. Note that Name refers to what Tasker uses to refer to an element internally in Tasker, while Label or Text (depending on the element type) are the fields that control what the element will actually display. Variables work fine in these fields, and I’ll show how that can be used in practice in the examples further down.

The other tabs on the configuration screen vary greatly depending on element type. For the most part, each tab is essentially a task, capable of containing actions, and whose name indicates what triggers the action. For instance, adding a button to a scene brings up a configuration screen with three tabs: UI, Tap, and Long Tap. The Tap and the Long Tap tabs are each their own tasks which trigger depending on whether you tap the button or long press it. Anything you want to happen (Tasker actions) when the button is tapped goes into the Tap tab, and similarly with the Long Tap tab. Adding an Airplane Mode: Toggle action to the Tap tab will result in a button that turns Airplane Mode on or off when clicked. Other than being in tabs like this, actions work like you’re used to. You can use multiple actions, limit them using If conditions, and so on.

With 11 element types that all work differently, there are a lot of different tabs to be familiar with. Like with individual actions, there are too many to go into detail with each one, but the Tasker help button is available in the element configuration screens to explain how each element works. The examples at the end of this article will also go into detail on how some specific usage scenarios are configured. Scenes can be used for so many things that examples are a better way of trying to explain the potential rather than trying to explain each component individually. In fact, making elements work together is far more difficult than configuring them on their own, as some of the examples will show.

Triggering scenes

The Scene category of actions currently has 20 different actions available. Most of them have to do with manipulating elements using actions, but the top four actions are different; they control the existence of a scene. These four actions are Create Scene, Destroy Scene, Hide Scene, and Show Scene.

A scene can be active even if it isn’t displayed. You can compare it with how an app can run in the background, and in the same manner, a scene that is active in the background takes up system resources. The Create Scene and the Hide Scene actions deal with this state of visibility, with Create Scene starting up a scene without displaying it and Hide Scene taking a visible scene and hiding it without actually closing it.

Show Scene and Destroy Scene are the two most used options, and the only two of these four that I actually use. Show Scene displays the scene, and creates it (starts it up) if needed. Destroy Scene closes the scene, so that it doesn’t run in the background either. The name “destroy” can be confusing as it sounds like it deletes the scene you created, but it actually doesn’t affect the saved scene “template” that you created in Tasker at all – it simply closes the scene completely. To make this perfectly clear, here’s a short vocabulary of terms often used with scenes:

Create scene: Starts up a scene in the background

Show scene: Shows a created scene (and creates it if needed)

Hide scene: Hides a scene, but still allows it to run in the background

Destroy scene: Closes the scene completely

This can be confusing since most people would assume that “create scene” refers to what you do in the scene editor. In fact that is often referred to as creating a scene too, so you just have to be aware of the double use of the term. Activate and deactivate would have been better choices for names, but hindsight is always 20/20.
Normally you’d use Show Scene to make a Scene appear, and Destroy Scene to make it disappear and not run in the background. The examples at the end will show a few ways to use these in practice.

Show Scene options

The Show Scene action is the method you’ll most likely use to trigger your scenes and make them appear. Like I said above, this action actually controls some aspects of how the scene will look. Specifically, there is a Display As option in this action that has 9 different states:

Overlay

Overlay, Blocking

Overlay, Blocking, Full Display

Dialog

Dialog, Blur Behind

Dialog, Dim Behind

Activity, Full Window

Activity, Full Display

Activity, Full Display, No Title

These 9 Display As option decide how the resulting scene will display and act. From the Tasker user guide:

All Overlays are displayed over the current application and persist until hidden or destroyed.

Blocking overlays only block touches on the part of the screen they cover.

Non-blocking Overlays are also displayed over the Keyguard.

Dialogs are little popup windows which take all user input while they are displayed and can be dismissed with the Back key.

Activities are standard Android app views.

What you have here is essentially three display types, each with three variations.

Overlays are meant for scenes that display over part of another app. Let’s say you want to have music controls visible while browsing. You could then make a small scene with music controls, and display that as a overlay at the bottom of the screen when your browser is active (using an app context).

Dialogs are essentially pop-up boxes, like yes/no dialogs and the likes. You might want to have a profile that triggers on plugging in your headphones, and then pops up a box with several options for apps to launch. A scene displayed using a dialog option would be perfect for this. Do note that there’s an action called Menu in the Alert category which provides an alternative way to create a dialog scene.

Activity scenes are meant for scenes that work more or less like apps. As a result, you would normally use those options for scenes that you want to act like apps. With Tasker’s new app export ability, many people find themselves using scenes as configuration screens in exported apps.

If you use any of the Display As options that are not fullscreen, you will also get some additional options that adjust the position of the scene. This is particularly useful for overlay scenes which often need to go over a certain part of the screen.

Do note that display type options sometimes act differently on different devices and OS versions. My advice is to try the options out and see which ones work the best for you.

The Show Scene action also has an option to “show exit button,” which is enabled by default. This shows a red exit button in the bottom right corner which will close the scene when clicked. This is a failsafe to prevent anyone from making a scene with no way of closing it. You can really mess up if you use certain display types and disable this without having an exit option yourself, so make sure that you have some sort of way to destroy or hide the scene from within the scene before you uncheck this option.

In the examples that follow, pay attention to how the Show Scene action is rarely on its own in the task that triggers the scene. Very often, you have to do additional preparation in the same task in order to properly create the scene, such as setting an element value (example 1), loading text files into variables (example 2), and downloading images from the web (example 3). Also pay attention to the order of these actions. Example 1 has the Show Scene action first, as the other action manipulates an element in the scene, thus requiring the scene to exist beforehand. Example 2 and 3 have the Show Scene action last, as the other actions in the triggering task gather information that has to be in place before the scene can be created. Like I said, the difficult part of scenes has to do with making all the parts work together correctly, not configuring individual elements.

Example 1: Pop-up settings menu

My pop-up settings menu has been around for a while, and has evolved as I’ve added more to it. I use it as a way to quickly access settings I use often, most of which are settings for my own Tasker profiles and tasks. There’s a slider and buttons for controlling screen brightness, buttons for activating various profiles I have, and more buttons that do all sorts of things.

How it’s triggered

The settings box can be triggered using two shortcuts; one on my home screen, and one on my lock screen. Tasker has a built in feature that allows you to run tasks from shortcuts, which is why I use in this case.

When either of those shortcuts are clicked, a task called Show Psett runs. This contains two actions, Show Scene: Popupsett, and Perform Task: Refresh Br. The Show Scene action is what I described above, and in this case it uses Dialog, Blur Behind as the display type.

Refreshing the slider: a lesson in dealing with generic elements

The second action, which runs the separate task Refresh Br, has to do with the display brightness slider in the scene. To understand why it’s there, you first have to understand how generic scene elements work, as well as how the slider element works.

A slider element in a scene has to be configured with a minimum and a maximum value, which is what the value of the slider will be when the slider handle is all the way to one side or the other. Screen brightness has 255 levels in Tasker, so my brightness slider is set to go from 0-255. When you slide the slider half way, the value is 128, when you slide it all the way, it’s 255, and so on. This is a setting in the slider element’s UI configuration tab.

The other tab in the configuration for the slider element is Value Selected. Value Selected is the slider element’s version of the Tap/Long Tap tabs I mentioned for button elements earlier. Every time the slider handle is moved, Tasker runs any actions added to the Value Selected tab. Additionally, the value that the slider lands on when you release the handle is written to the local variable %new_val automatically. For my brightness slider, moving the handle all the way to the right sets the value of %new_val to 255, and it runs any action in the Value Selected tab.

In this case, this tab contains a single action: Display Brightness, where the Level field is set to %new_val. When the slider handle is moved, the value it lands on is stored in %new_val, and the Display Brightness action uses that value to change the screen brightness. The result is that sliding the slider all the way up sets the screen brightness to 255, which is 100%.

It’s important to understand that the slider doesn’t know that it’s a brightness slider. All it does is turn a position on the slider into a value, and that’s it. As such, the slider handle will start at 0 every time the scene is created, because the slider neither knows nor cares what the current brightness level is. In order to make the slider handle be in the correct position on the slider when the scene pops up, you have to actually tell the slider where the handle should be positioned. This is what the Refresh Br task does.

As you can see above, this task consists of two actions: Set Variable and Element Value. Element Value is an action in the Scene category, and it allows you to manipulate the value of an element using a task. In this case, we want to tell the slider to put the slider handle at the same level that the screen brightness is currently at. If you’re at 25% brightness, you want the slider to be 1/4 of the way to max, and to make that happen, you need to tell the slider to start there. By running an Element Value action that sets the value of the slider to the current brightness level as part of the same task that triggers the scene, the slider will be in the right position when the pop-up box appears.

So, what about the Variable Set action? Well, the Tasker dev messed up a bit when he created the Element Value action. The Value field only accepts global user-created variables and numbers, so we can’t use the built-in variable %BRIGHT (which always contains the current brightness level) in that field. To work around this “bug,” I copy the value of %BRIGHT into my own variable %Brait, and use that variable in the Value field instead. It’s a weird and slightly annoying bug, but worth noting since a brightness slider is a useful thing to have in a scene, so you might run into this situation yourself.

To put all of this in words, this is what Tasker sees the Show Psett and Refresh Br tasks as:

Show the pop-up settings scene and move the slider handle so it matches the current screen brightness

Where the red text indicates what Show Scene does and the blue text indicates what the Refresh br task does.

The important lesson to take from this is that elements in a scene are generic, and that means that they won’t always work the way you think they would work. In this case, the slider is used to control the brightness level, but the slider doesn’t know that, and so it needs you to tell it that the brightness level has changed without it in order to display that properly. In example 5 you’ll find a use for the slider that proves pretty conclusively that it doesn’t have to be a brightness slider.

As for why the two actions in Refresh Br are in their own task instead of being part of the Show Psett task, that was originally in order to refer to the same refresh task from other places than just that one task. I ended up changing the system to where only the Show Psett task actually uses that task, meaning that it doesn’t need to be its own separate task at this point. However, in the todo list example below, I will show you an example of where such separation does have a use.

The scene

This is what the scene edit screen looks like for the pop-up settings scene, and what it looks like when actually triggered. It’s a collection of button elements, text elements, and a slider element. As you can see, I’m using a grid size that allows me to space out buttons of various sizes evenly, and finding the right grid size for that to be the case can often be a pain.

In this case, the settings box actually looks like it’s fullscreen, even though the Display As type is Dialog, Blur Behind. That’s because the scene itself covers most of the screen, but you can still see the status bar shining through, and the effect of the Blur Behind option.

Also note the position of the slider handle. The brightness is set at 25% in that image, and the slider reflects this – because of the Refresh Br task. Without it, the brightness would still have been 25%, and the slider would still have been able to control the brightness, but it wouldn’t have displayed the correct brightness unless it was the one to set the brightness.

Top seven buttons

The top seven buttons all do different things, but are all rather basic. Most of them have two actions: Perform Task and Destroy Scene. Destroy Scene closes the pop-up settings scene, while Perform Task runs a separate Tasker task. Two of the buttons, WebCam image and Todo list, trigger new scenes which are separate examples above. The reason why the TeslaLED task doesn’t use Destroy Scene is that it toggles the LED light on my phone on or off, so I want the scene to stay active (not close) when I click the button, so I don’t have to start the scene up again to toggle it off after I toggle it on.

The actual functionality of the tasks behind the Perform Task actions here isn’t important, the point is just that I use these buttons to toggle other tasks from a central location. For the record though, the seven buttons do the following: Run a task that archives the articles I’ve written on this site that day, opens a “virtual window” scene with WebCam images, overrides an active school profile using a variable, toggles the LED, opens my todo list scene, turns my computer monitors off wirelessly, turns my computer monitors on wirelessly.

Profile buttons

The three profile buttons control a profile system that is separate from my automated profiles that I talked about in part 2 of this guide. They’re designed to be activated manually, which is why I have buttons for them. Each button closes the scene (using Destroy Scene), sets the variable %Profile to a specific value, and in the case of the Normal mode button, deactivates silent mode.

The values that %Profile is set to in this case are literally “Normal mode,” “Silent mode,” and “Movie mode.” Movie mode and Silent mode are separate profiles altogether, both of which uses Variable Value as the context. In order for the Movie Mode profile to be active, the value of %Profile literally has to be “Movie mode.” In the previous article I talked about advantages of using number values instead of text values for variables that are used as settings, but in this case, using a (complicated) text value has one big advantage. That advantage can be seen in the right image, where the text element is set to display “Profile: %Profile.” Since the value of %Profile is the full name of the currently active profile, the text element will end up displaying the name of the active profile (this can be see in the screenshot in the “The scene” section above. Had I sued 0/1/2 instead of Normal mode/Silent mode/Movie mode as the values, the text element would for instance have displayed “Profile: 1.”

That little lesson in variable value naming aside, this profile button setup demonstrates how you can activate and deactivate entire profiles using scene elements. The scene elements (buttons in this case) set a variable to different values, and then various profiles trigger depending on that value.

Brightness controls

I already explained how the slider works, but as you’ve probably seen, there are also buttons present that set the brightness to specific values. These buttons simply set the brightness to the specified level (measured from 0-255, so that 50% is 128), and then destroy the scene. As for the OK button, it only does one thing: Destroy Scene. That button is there for when I use the LED toggle or the brightness slider, as those two elements don’t contain their own Destroy Scene action. Like I explained earlier, the choice not to include a Destroy Scene with those is because I expect to want to continue using the scene after I interact with them, and so having the scene go away would be annoying.

Example 2: Todo list

How it’s triggered

The todo list system currently consists of three lists, each for a different situation. I get notified of items from the shopping list when I walk outside, the morning list when I get up, and the home list (listed as “after school” in parts of the system) when I get home. These lists are stored as physical text files on my phone, but Tasker needs these to be variables to display their content. As such, the first three actions in the task that triggers the todo list scene are Read File actions. These actions read the text files and turn them into variables, one for each list.

The fourth action is a Wait action, the purpose of which I’ll get into later. It simply delays the rest of the task by half a second.

The fifth and final action is the Show Scene that actually makes the scene show up. Like the previous example, the Display As setting is set to Dialog, Blur behind.

The task itself is triggered from the pop-up settings box in example 1, using the Perform Task action.

The scene

This is what the scene looks like in edit mode and in actual use, with some examples thrown into the latter for good measure. The field between Title and Tag is a text input field, and the three fields at the bottom are text fields.

Text input field, tag buttons, and save button

Text input fields work a lot like slider elements. Each time you input something in the text field (i.e. for each and every letter), it writes the content of the text edit field to the local variable %new_val. It also runs all actions under the Text Changed tab in its configuration screen, just like how the slider runs all actions in the Value Changed tab when the handle is moved.

The problem with this is that if you’re typing, you’re going to run those actions a heck of a lot of times. As such, I advise that you keep the number of actions in this tab to the bare minimum. For me, there’s only one action, which transfers the value of %new_val to my own variable, %todotitle. I don’t actually think I even need to do that, but I have an old habit of using user created variables.

Point being, when I’m done typing into the text field, there will be a variable %todotitle that contains whatever was typed into the field.

Next up is the tag buttons. These are very simple buttons that set the variable %Todotag to Shopping, Home, or Morning respectively.

The Save button is where the actual magic happens. When clicked, it appends the corresponding text file with the value of %todotitle (plus a line shift) depending on the value of %todotag. In other words, whatever you wrote in the text input field is added to the text file for the list you selected using the tag buttons. It filters this using If conditions on the Write File actions.

The important lesson here is how the use of a separate Save button means that I can put the actual Write File action out of reach of the “rapid fire” Text Changed tab. If I had put Write File in the Text Changed tab for the text input field, it would have written to the file every time a new letter was put in. Not only could that cause problems for the system, but you couldn’t use the append option for adding the text to the end of the file, as it would then repeat all preceeding letters as well when it wrote new ones. Inputting “apple” in the field would then result in a file like this:

aapappapplapple

I can’t emphasize enough that making everything work together is what’s difficult with scenes, and this is just another example.

After it has saved the text to a file, it destroys the scene, and runs the task that triggers the scene all over again (the one described at the beginning of this section). The point of this is to refresh the entire scene in as simple a way as possible, clearing the text input field and updating the text elements so that they display the new content of the text files.

This is where the 500ms delay comes in. I had trouble with the scene not reloading properly when doing it without a delay, so I added one. Sometimes you just have to manually give tasks a bit of breathing room by adding wait actions.

The save button also has a second use, triggered by holding down the button instead of just quickly clicking it. This is done by adding actions to the Long Tap tab, in this case a simple Destroy Scene action. Since clicking the button will make the scene reload, I needed a button that actually closes the scene. Instead of adding a separate button, I simply added a second use for the Save button.

Text elements

The bottom part of the scene consists of six text elements: fields that list the contents of the three todo lists, and corresponding labels on top. The labels are static, but the lists are dynamic.

First of all, each list has a variable as the content of the Text field. They’re the variables that are created by the initial task that creates the scene, and contain the contents of each of the todo lists. In other words, each of the three text elements contain the text stored in the text files. Whenever the initial task is run by destroying the scene and running the initiation task again, these variables are refreshed.

The Tap action for each text element is top open the corresponding text file. This opens it in whatever app is set to open text files, and this is frankly just a very quick and simple way of adding a way to edit todo lists. I very rarely have to do so, as I normally clear the entire list at once, but it’s nice to have the option.

The Long Tap task for each element does three things. First, it displays a new dialog scene the quick and dirty way, by using the Menu action I briefly mentioned earlier. The Menu action technically creates a scene, one you can modify the looks of even, but you configure it via the action’s own options, not the scene editor. It’s quicker when you just need to create a quick dialog scene, like here. This Menu scene asks if you want to clear the corresponding todo list.

There are two options in this Menu scene, Yes and No. No destroys the Menu scene, and then the initial Long Tap task continues, closes the todo scene, and restarts/refreshes it using the same method as with the save button. The Yes option writes a blank space to the corresponding todo list text file, with append unchecked. The append option for Write File decides whether or not the new text is added to the end of the file, or if it overwrites the file. The Save button Write File actions have append enabled, but this one doesn’t, as it’s supposed to clear the list.

There are a couple of reasons why I write an empty space to the text file instead of writing nothing or deleting it. If I had used Delete File to delete the file, then Tasker would have given me an error when it tried to read the file into a variable as part of initiating the scene. If I had written nothing to the file, then the variables created by Tasker when initiating the scene would have been blank. As explained in the previous article, this causes Tasker to literally display the name of the variable where the variable is used. In other words, an empty list wouldn’t display as empty in the scene, instead it would show the name of the variable, like %Todoshopping.

After you click yes, the todo scene is destroyed, then recreated to refresh it.

The non-scene part of this list

Since I know for a fact that there are people out there who tried to make a todo list system like mine and failed, I’ll also briefly mention the side of this system that isn’t scene related – just for the sake of not leaving it half done. What this scene does is to give you an interface for creating and managing the todo list, but the other component to the puzzle is a way for Tasker to check it and act based on it.

The image above shows my Todo Morning task. The purpose of this task is to check the morning todo list and notify me if there are any items in it. It starts off by reading the text file that contains the list into a variable. If that list is empty, the variable will contain only a space (ref. the way I clear the list above). As such, I can use an If condition for %Todomorning Matches ++ to check if there are any items in it. ++ means “at least two letters,” which is true when there are any actual items in the list, but not true if there’s only that one single space.

Action 4 in the list above creates a notification with %Todomorning as the text, but is limited by this If condition. As a result, it only creates the notification when there are items in the list.

Action 2-3 are not really relevant, but I’ll explain them for the sake of not leaving any questions. This Todo Morning task runs as part of a much larger task that runs when I get up in the morning, and I want the spoken message that I get when that happens to mention if I have any items in my todo list. I do this by setting the variable %Todomorningnot to “You have items in your todo list” using the same If condition as action 4 above. %Todomorningnot is then inserted into the Say action in the main morning task. Action 2 makes sure that this variable doesn’t contain anything if the If condition is not met.

The final result is that if the list contains any items, a notification will be created, and my morning message will notify me of it. If the list is empty, there will be no notification and no message.

Example 3: Virtual window WebCam scene

My virtual window has been the topic of a short article before, but I didn’t go into much detail. Just like the todo list, this is also all about the scene.

How it’s triggered

This scene is also triggered by a task linked to one of the buttons in example 1. The scene itself contains images that have to be downloaded from the web, and because of this, the Show Scene action is at the end of the task. The three actions before it are HTTP Get actions, which are used to download the images. The images are saved to a specific path, so that each time the task runs it overwrites the existing images.

It’s imperative that the Show Scene action is run last here, or the scene would load the old images.

The Display As type in this case is Overlay, Blocking. In this case it doesn’t really matter though.

The scene

The scene is as simple as it gets. It has three image elements, each of which uses one of the downloaded images as a source. The images have been moved and re-sized in the editor, and even though it loads newly downloaded images each time it’s displayed, it keeps the same layout.

Each image also has Destroy Scene as the Tap action. That means that tapping any of the images will make the scene go away.

This is a very simple scene from a technical point of view, but I use it a lot. It also demonstrates the use of dynamic images, which has many applications. You could for instance create a scene that shows today’s new web comics when you click a button.

Examples 1-3 in practice

Examples 2-3 are triggered with buttons in example 1, so I thought I would create a simple video to show how all of this looks in practice. There’s a lot that goes into making everything in a scene work the way it should, especially when there’s a lot that has to work together. As you can see in the video though, it’s all quite simple when you actually get to where you can use it.

Example 4: Gmail notification

The first three examples are all fairly standard uses for scenes. This one is not. It all started with a wish to add a more visible notification for incoming emails, similar to notification LEDs on some devices. I experimented with using the camera LED, and that worked well, but it wasn’t quite as…elegant as it could be. My Galaxy S II has an AMOLED screen, and one of the advantages of such a screen is that the color black is created by turning off the pixels. Black pixels are therefore just the screen being off, and you can’t tell a black bezel from the screen when that’s the case.

I came up with the idea of having a Gmail logo be displayed on the screen, in such a way that it appears as if only the part of the screen with the logo actually turns on (which is in reality what actually happens as well, due to the way AMOLED technology works). The video below is the result of this idea, and all the magic is done with Tasker scenes.

How it’s triggered

Part of what makes this example so different is how it’s triggered (or perhaps controlled is a better word in this situation). First of all, this scene is triggered automatically using a profile and a context. Four contexts, to be exact. The main one is an event context for any notification from the app Gmail. In other words, this context is triggered if Gmail receives a notification, which is only when it receives an email in my case.

This event notification is further filtered using three state contexts. The variable %Sleepmode can’t match “on,” the Home profile has to be active, and the display has to be off. The first of these is to prevent the profile from being active when I sleep. The second is to make make sure it only runs when I’m home (I have a different Gmail notification system for other locations). The third is to make sure it only runs when the display is off, so that it doesn’t start interfering with me using the device.

Now, to the task that creates the scene. The first action shows the Gmail Notification scene, which is the Gmail logo on a black background. The display type is Overlay, Blocking, Full Display. The second action is another Show Scene, this time for a completely black scene, with display type Activity, Full Display, No Title.

So, why two scenes? In my testing, I found that (on my device and ROM, this might very well be device-dependent) the Overlay display type wasn’t capable of turning on the screen of my device. The Activity display type is, but its definition of Full Display doesn’t include the status bar, leaving it visible. By using two scenes – one of each type – I managed to get a scenario where the scene will turn on the display, and it will actually cover the entire screen with a black box, meaning the pixels will stay off on an AMOLED screen.

Since I initially created this system, I’ve rooted my device, and I can now use the Secure Settings plugin to wake the device. Still, I don’t tend to fix something that’s not broken, and the non-root method is a better example of how you can use scenes creatively.

On to action 3, that one’s a Wait action which decides how long the display will stay on for (as action 5 is System Lock). The Gmail logo is clickable, and clicking it will bring you to the Gmail app, so action 4 is there to prevent the rest of the task from running (and in doing so, turn off the screen) if I do indeed click the logo. The variable that the Stop action has an If condition for is set when clicking the logo, as you’ll see further down.

Action 6 is a new wait, this time to make sure that the lock screen animation has time to finish before the two scenes are destroyed with actions 7-8.

When all of this works together, you get the result in the video above.

The scene

The two scenes here aren’t very interesting in themselves. The Gmail Notification scene has the Gmail logo, and that’s about it. There are however quite a few actions tied to the Tap task for the image. First, it sets the %Gmailactive variable, which in turn controls the Stop action I mentioned above. Then it destroys the two scenes used to create the notification. Next, it loads the Gmail app, allowing me to actually read the email that came in. Finally, it waits for 6 seconds, and then clears the %Gmailactive variable, resetting it for next time.

Like I said, this is a fairly peculiar use of scenes, but it’s also one of my favorite Tasker setups. My phone is normally sitting in a DIY cradle on my desk when I’m at home, with the screen pointing towards me, so having a visible notification is great. Being able to limit it to when I’m at home and not using the phone makes it that much more useful. For the record, when I’m not home, the notification switches to three one second vibrations instead of this setup.

Example 5: Lock screen using scenes

The previous examples have all been from my own Tasker setup, with scenes and systems I know well. For this last one I’ll do a reader request from a previous Tasker article and create a lock screen in using scenes.

How it’s triggered

Since we’re talking about a lock screen, the logical thing to do would be to trigger it on Display On, which is an event context. The problem with that is that since it takes a few milliseconds to show the scene, you get this lag effect when using that context – at least on my older Galaxy S II.

The alternative is to trigger it on Display Off. This might seem backwards, but the advantage is that the scene is then ready to go when you turn the screen back on, making that part faster. This method does however also have its disadvantages.

First off, any elements in the scene will have been created when the screen was turned off, and might be outdated by the time you turn it back on. As you’ll see later on, I added a simple text element with %TIME as the text to my test lock screen, which resulted in a “static clock” that displays the time that the scene was created (but doesn’t change on its own). That means it’s useful for checking the time quickly by turning on the screen if the scene is created at the same time, but not if it (and the time) is from back when the screen was turned off. It is however possible to half fix this by adding a profile that does trigger on Screen On, and use it to update the time-sensitive elements by using the various element update actions in the Scene category of actions. You then get a scene that appears quickly, but with the wrong data, which is then updated after a split second.

The second problem with using Screen Off is that if you have a security lock screen (e.g. pattern unlock screen) below your Tasker-created lock screen, you need to use the dialog display type to make your own lock screen be on top (if that’s what you want, of course). Unfortunately, any dialog scene also turns the screen back on, so when you lock the screen, it will create a scene that turns the screen back on. You can half fix this issue too, by adding a System Lock action after the Show Scene action in the task. You then end up with a lock screen that flashes briefly when turning the screen on.

So, bottom line, both of these methods have issues. If you’re not overly picky about it though, the split second you have to wait when using the Screen On context isn’t too bad.

Creating a lock screen scene

Now this is where the fun begins! There’s so many things you can do to create a lock screen in Tasker, and the end result can be pretty impressive.

I started out by adding a slider, picking the Tasker icon as the handle (or thumb as Tasker calls it), and setting it to go from 0-100. Then I went to the Value Selected tab and added a Destroy Scene action with the If condition %new_val Maths: greater Than 90. Why? Slide to unlock! When you slide the slider past 90% to the right, it destroys the scene, and the screen “unlocks.”

Next I added the “clock.” It’s a simple text element with %TIME as the text, as I explained above. Using a large text size makes it look like a widget. You also have %DATE, %BATT, and a ton of other built-in variables to help populate your lock screen scene. Just remember that the more dynamic content you add, the more you have to update using a second profile if you should choose the Display Off option for triggering the scene.

Next I added a Gmail logo by inserting an image element and using the Gmail app logo. I added an action to open the Gmail app as a Tap action, as well as a Destroy Scene action to close the lock screen when doing so. Since I don’t plan on using this lock screen system myself, I cheated and added static text to display new emails beside the icon. Adding an actual email counter (or SMS counter for that matter) is not a problem.

Finally, I added a static image of my dog, just to fill the screen. If I were to actually use this though, I would have used the rest of the space for something else, like owner information and the likes.

Once your scene is done, all you have to do is link a task that triggers it to your preferred context.

Situation-dependent lock screens

While I don’t plan to replace my WidgetLocker lock screen, there is one advantage of this scene system that makes me very tempted to do just that: Having situation-dependent lock screens. You can easily create multiple scenes for different occasions, like one for home, outside, school, work, and so on. Many people, me included, have profiles for various locations and situations, and using those to control which scene is displayed is as easy as having multiple Show Scene actions with If conditions.

Why WidgetLocker doesn’t have profiles is something I can’t fathom, but from what I’ve seen of the developer’s response to user feedback there isn’t much hope. Despite that though, using scenes as lock screens isn’t quite there yet if you ask me, but it’s ridiculously close for something that wasn’t designed for it.

In closing

This has been a very long part of the guide, with a stronger focus on examples than on theory. That’s simply because the scene feature has so much potential that I think it’s easier to understand how it works by seeing real life examples. As you’ve probably noticed though, there are a lot of minor things here and there that makes each scene unique, from having to pre-load data before creating a scene to using multiple scenes to combine their advantages.

The next part of the guide will cover data processing using variables, which is something that opens up for a whole range of new uses for Tasker.

]]>https://www.pocketables.com/2012/09/beginners-guide-to-tasker-part-3-scenes.html/feed8343087Beginner’s guide to Tasker, part 2: Variableshttps://www.pocketables.com/2012/08/beginners-guide-to-tasker-part-2-variables.html
https://www.pocketables.com/2012/08/beginners-guide-to-tasker-part-2-variables.html#commentsSat, 25 Aug 2012 20:13:32 +0000http://www.pocketables.com/?p=42278In the first part of this guide I covered the basics of Tasker, and mentioned that I would go more

In the first part of this guide I covered the basics of Tasker, and mentioned that I would go more into variables and scenes later on. Both are features that require a bit more explanation than the other aspects in general, so I’m going to dedicate an article to each of these topics. First out, variables.

What is a variable?

Variables are part of many programming languages, and Tasker is, in many ways, a programming language. Mathematics also use variables, and in many ways they work the same too.

A variable is essentially a virtual text file. Imagine a text file called variable.txt that contains the text “Hello World.” Instead of it being a physical file you can move around however, it exists within Tasker; and instead of being called variable.txt, it’s called %variable. The percentage symbol is always present at the beginning of a variable name, and it’s the way that Tasker knows that something is a variable – just like the file extension .txt lets computers know that it’s a text file. The name that follows the percentage symbol is in a way the file name. Just like a text file, a variable can contain text, but only text. This text can be a single symbol, number, a URL, a paragraph from an article – any text, in other words.

When a variable is used anywhere in Tasker, Tasker will replace the variable with whatever the value (content) of the variable is when it executes whatever the variable is used in. Let’s say you have a variable %hello that contains “Hello World.” You then tell Tasker to create a notification with the text %hello. When Tasker then goes to create the notification, it will check the value of the variable, and use that instead of the variable name. As such, the final notification created by Tasker will not read “%hello.” Instead, it will read “Hello World.”

Why use variables?

The purpose of variables is to have a way to store information in a dynamic way. This enables you to not only transfer information between different parts of Tasker, but also to control Tasker settings and text remotely, without having to go into each context/task and manually change it.

To fully understand the purpose of using variables, you first need to know about the different ways that you can change the value (contents) of a variable. Some examples include:

Set the value of a variable using an action. This value can then be used as a context for a completely different profile, or used as part of other actions

Turn the contents of a real text file into the value of a variable

Do math using variables. For instance, you can add +1 to a variable every time an action runs. The variable value would then increase in numerical value the more times the action is run, acting as a counter

Many system settings and events exist in variable form in Tasker. The value of the variable %TIME is always the current time, %DATE is always the date, %BATT is always the battery level and so on. Full list of these so-called built-in variables are here, and knowing how to use these is one of the more important lessons of Tasker

In short, there are many ways to change the value of a variable. The whole idea is to create a library of information that different parts of Tasker can access, instead of having information stored as static text that’s only usable where it’s written. In fact, variables share a lot of advantages with the internet:

Information can be shared easily between connected participants

Information collaboration is possible by having multiple participants work on the same information

Information can be updated in once place and still reach multiple participants without each of them having to be updated directly

With the internet, participants are internet users. With Tasker and variables, the participants are different actions, contexts, and so on within Tasker.

Variable name capitalization

The capitalization of variable names actually changes – and indicates – what type of variable it is. There are three types: local, global, and built-in. To create variables of a certain type (only global and local variables can be user created), simply use the corresponding capitalization format. Furthermore, global variables are listed in Tasker’s Variables tab, however neither local nor built-in variables are.

Local variables are all lowercase and are only available to the task/profile that creates them. If you have a task “Home” that creates a variable %home, then that variable will not be available to other tasks. Another task “Away” would hence not be able to use that variable.

Global variables are listed in the Variables tab and will be visible and usable by all parts of Tasker. These variables have to start with a capital letter. If your “Home” task creates a variable %Home, your “Away” task will be able to see it, change it, and use it.

Built-in variables are always all uppercase. These are the variables I talked about above which are built into Tasker and that take on the values of system information. %TIME, %DATE, and %BATT are the examples I used above. These can be read by any part of Tasker, but do not show in the variables tab. Furthermore, they cannot be changed by the user, as they by definition display a piece of system (generated) information. The only way to change %BATT is to change the actual battery level by charging or discharging the battery.

Exceptions

No rules are without exceptions. There are some variables that take the form of local variables, but are actually built-in variables. An example is %new_val, which you’ll run into in scene creation. For the time being though, you can ignore these for the sake of avoiding unnecessary confusion.

Variables for information sharing and dynamic text

Variables can be used to share information between parts of Tasker, and even between plugins and Tasker. To use the internet simile from above, variables allow one part of Tasker to send information to another part, just like an internet user would email another.

The concept of dynamic text is like document collaboration in Google Documents or other online document editors. Instead of text being a static creation, parts of it can be changed out by different independent sources.

Example 1: My morning message

I have an elaborate sleep mode setup that I use every night. When I wake up in the morning, I use a Tasker action called Say (found in the Misc category), which is a text to speech function. This action has a text field into which I type the text I want it to say, and then the phone reads that message out loud. Currently, this text field reads:

Good morning. You slept for %Smduration hours. %Lazy. Weather forecast for today is %Norweather. %Todomorningnot

As you can see, this message contains 4 variables (it used to contain more). Before the Say action runs, dozens of other actions run, collect and process data, and store the final results in these four variables.

%Smduration is the duration, in hours, that the sleep mode was active for. If it was activated at 23:00 (11 PM) and deactivated at 7:00 (7 AM), then the value of %Smduration would be 8.

%Lazy’s value depends on the value of %Smduration. If %Smduration is at least 9, %Lazy’s value is “You lazy bastard”. If %Smduration is less than 9, it’s simply nothing.

%Norweather is the result of a task I made to collect Norwegian weather data. Its value is a very short description of the weather forecast for that day, like “sunny” or “heavy rain.”

%Todomorningnot is part of my Tasker-based todo list system. If I have todo list items marked “morning,” its value is “You have items due in your todo list.” If I don’t have any such items, its value is simply nothing.

By using these four variables, the message the phone speaks in the morning varies depending on these – and here comes the reason for the name “variable” – variables.

If I get up after 8.5 hours on a rainy day where I have nothing to do, the phone will speak the following message:

Good morning. You slept for 8.5 hours. Weather forecast for today is rain.

If I get up after 10.2 hours on a sunny day where I have items in my todo list, the phone will speak the following message:

Good morning. You slept for 10.2 hours. You lazy bastard. Weather forecast for today is sunny. You have items due in your todo list

Using variables in this way here gives me two very important abilities:

My morning message is dynamic. Even though I never go in and manually change the Say action’s Text field, the message still changes.

I can transfer information from one part of Tasker to another. The four variables in the message are each the result of work done by other tasks and actions, and using variables allows me to transfer this information to where I need it.

Example 2: AutoRemote

AutoRemote is a Tasker plug-in that I’m particularly fond of. It allows different devices to talk with one another by sending each other messages that are not visible to the user. It allows Tasker on one device to talk to Tasker on another device, without using a communication method that is meant for something else – like SMS or email.

Incoming messages through AutoRemote can be used in two ways: as triggers, or as information sources. If it’s used as a trigger, you can for instance set up a Tasker profile that activates if a message that says “hello” is received through AutoRemote. This could for instance be used as a “find my tablet” feature, where sending a message with “hello” from your phone to your tablet triggers a task that makes the tablet beep.

If the message is used as an information source, the actual content of the message can be transferred to a Tasker variable. Let’s say that you want your tablet to be able to tell your phone the status of the battery. Your tablet could then send the following message to your phone:

Tablet battery level %BATT percent

Where %BATT is a built-in variable. When the tablet sends this message, it will replace %BATT with its own battery level. As such, the message that arrives on the phone will have the tablet’s battery level.

The phone would then be configured to look for a message that contains “Tablet battery level.” AutoRemote has an option for whether it has to be an exact match, which in this case we wouldn’t want. This message filter would act as the context for the profile, meaning that the profile would trigger when a message containing “Tablet battery level” was received.

This is similar to the “find my tablet” example above, but we want to go one step further here – actually using the content of the message as well, not just use the message itself as a trigger.

To do this, you would configure AutoRemote to turn the message into a variable – let’s say %tabletbattery. That variable could then be used in a notification, Say action, or similar. Simply creating a Say action with %tabletbattery as the text, and using it in the profile that is triggered by the incoming message, would then have your phone read the tablet’s battery status out loud when it receives a message from the tablet.

Since %tabletbattery is a local variable it would only be available within that profile, but you could easily use the Set Variable action in the Variable category to create a global variable. This is done by setting the Set Variable action to create a variable with global variable capitalization, like %Tabletbattery, and setting its value (in the Set Variable configuration screen) to %tabletbattery. This would then create a global copy of the local variable.

In this AutoRemote example, the value of a built-in variable on a tablet is sent to another device using a plug-in, where it’s turned into a variable which that device can use. This is just another example of information transfer using variables, but a more advanced one since it transfers information between devices.

Example 3: Minimalistic Text and Make Your Clock Widget

Minimalistic Text and Make Your Clock Widget are two independent Android widget creation apps that both have the ability to receive information from Tasker. They both interact with Tasker very similarly, using an action that transfers information from Tasker (either static text or the value of a variable) into the apps’ own variables.

I use both of these apps, and I use them both with Tasker. I use Minimalistic Text for my shopping list, by having a widget on my lock screen that Tasker can write information to. The widget only shows something if I’m outside and have items in my shopping list; otherwise it’s blank. The shopping list is handled by my own Tasker-based system.

The configuration screen image to the right shows how the action that bridges Tasker and Minimalistic Text is configured. It transfers the value of the Tasker variable %Todoshopping into the Minimalistic Text variable TODO, the latter of which is a variable in a completely different app and as such doesn’t use the % symbol to indicate a variable. Once this task is run, any place where the variable TODO is used in Minimalistic Text ( will then show the value of %Todoshopping. Each time %Todoshopping is changed in Tasker, the bridge action has to be run in order to transfer that information to Minimalistic Text.

Variables as settings

Variables have another use that is perhaps less apparent, but still very important to be aware of: they can be used as settings. This is done by assigning values to variables which are then used as references later. If you have a profile for when you’re home, you can use the Set Variable action to set a variable %Home to “on” when it activates (enter task), and set it to “off” when is deactivates. Any other part of Tasker will then be able to check what value %Home has, and in turn know if you’re home.

If you think about it, this is how settings work outside Tasker as well. If you go into system settings and turn off WiFi, you’re essentially setting a WiFi variable to “off” – it’s just a more visual way of doing it. If you’re connected to a WiFi network called McDonald’s, that’s like having a variable for WiFi network with a value “McDonald’s.”

Referencing variables: contexts

When I say that other parts of Tasker can check the value of variables and act accordingly, there are many ways it can do this. For contexts, the value of a variable is its very own context. It’s located in the State section, Variable category, Variable Value context.

The screen you get when selecting this context asks for a Name, Op, and Value. Name is the variable name, like %Home. The variable name you put here is simply the name of the variable which contains the information you want the profile to be aware of and react to.

Op is a bit more complicated. It means Operator, and refers to the method Tasker uses to check the value of variables, using a simplified version of regular expressions. You can set it to things like Matches, Doesn’t Match, Maths: Less Than, and so on. In short, the operator refers to the relationship between the third field, Value, and the actual value of the variable.

As an example, let’s say that you want a profile that is active when %Home is set to “on,” and deactivated when %Home is set to “off.” You would then use %Home as the Name, Matches as the Op, and “on” (without the quotes) as the Value. The resulting context can then be read like this:

Activate the profile if the value of the variable %Home matches “on”

To take another example, think back to the morning message example above. The variable %Lazy there has a different value depending on whether or not %Smduration is less than or more than 9. If I want to create a profile that reacts the same way, the Name would be %Smduration, Op would be Maths: Greater Than, and value would be 9. The resulting context can then be read like this:

Activate the profile if the value of %Smduration is at least 9

To finish off with a real world example, I use this system for my location profiles. I have three profiles that are mutually exclusive yet use different contexts. My Home profile is active when I’m connected to my home WiFi, my School profile is active when there’s a calendar entry in my School calendar, and my outside profile is active when the other two aren’t.

To be able to make sure that all profiles are indeed mutually exclusive, I use my own variables as settings. Both the School and the Home profiles have Variable Set actions on both the enter and exit tasks. When the Home profile is active, it sets the variable Home to 1, and when it deactivates, it sets it to 0 (exit task). The School profile does the same for %School.

The Outside profile then has two Variable Value contexts: %School Matches 0, and %Home Matches 0. In other words, it’s only active if both those variables are set to 0 – which in turn only happens when the other two profiles are inactive. The School profile also has two Variable Value contexts, %Home Matches 0 and %Schooloverride Matches 0. The former makes sure the school profile isn’t active when I’m at home (which could happen if we finish early,) whereas the latter variable is set by a button in a scene I have. I’ll cover scenes in the next article, but to make a long story short, I press a button that says “School override” and the school profile deactivates. This is for situations when I finish early but don’t go straight home (50 meters away), allowing me to manually trigger the Outside profile (by deactivating the school profile) for those rare occasions.

Referencing variables: actions

It’s not just contexts that can be controlled by variables – actions can be, too. One of the images in my first article pointed out the If checkbox on an action configuration screen. This checkbox is present for most actions, and allows you to control the action based on If conditions. An If condition is quite simply a condition that has to be fulfilled for the action to run.

For all intents and purposes, If conditions and Variable Value contexts work the same way. You have a variable name, an operator, and a value that has to be compared to the value of the variable. In the previous section, I explained how the Variable Value context works by using the configuration %Smduration Greater Than 9 as an example. That’s from my sleep mode profile, but it’s actually not used as a context in that profile: it’s used to limit an action using an If condition. The image to the right shows how this is configured.

As you can see, the If checkbox is checked; %Smduration is inputted into the first field; 9 into the second; and the operator is >, which is the symbol for Greater Than. With the action configured this way, the action will only run if the value of %Smduration is greater than 9. If it isn’t, the task simply skips that action.

I can use the same system to limit single actions based on the %Home variable created by my Home profile. If I want an action to run only when I’m home, all I have to do is check the If box, type %Home into the first box, select = (Matches) as the operator, and type 1 into the second box. That way it will only run when the value of %Home is 1, which only happens when I’m actually at home.

Please note that the choice to set %Home/%School to 1 or 0 instead of on or off is my own personal choice. You decide what the various states of a setting should be, and if you were to create your own Home profile with a %Home variable, there’s absolutely nothing stopping you from using a value of “crabcakes” as “on” and “hurricane” as “off.” It would simply mean that you would need to set the context/If condition to %Home Matches “crabcakes”.

It’s also possible to group multiple actions under the same If condition. To do that you use the If action found under Task, configure it like you would an integrated If condition, and then place it before the first action you want in the grouping. Any actions following that If action will then be nested under it, and follow its condition. You close the group by inserting an End If action. This is simply an easier method for applying the same If condition to multiple actions

Finally, there’s an action in the same category called Else. This is an optional action you can use between an If and an End If condition to create a new group of actions (nested under the Else action) which will run if the If condition is not met, but only if it’s not met. The screenshot to the right demonstrates this with one of my profiles, where I’ve inserted an Else action for the sake of demonstration.

The way to read this setup is as follows:

If the if condition is fulfilled, run action 3 (Notify Sound) and 4 (Minimalistic Text)

If not (Else), run action 6 (Stop)

The Else action is optional, and it really only saves you from adding a second If group that is the exact opposite of the first one.

I have previously written an article on controlling profiles using variables, which you can find here. Much of it is the same as what you’ve read here, but it was written for existing Tasker users, not beginners.

Special characters

When doing pattern matching using this method, it’s important to be aware of the three special characters *, / and +.

* is a wildcard, meaning that you can use it to match only part of a piece of text. If you input Android into the value field and use Matches as the operator, it will only match the exact use of Android. *Android* on the other hand will match any use of the word Android, like I like Android very much. *Android would match I like Android, but not I like Android very much, because the wildcard is only in front of the word, not behind it. In some cases it’s better to use *ndroid* instead of *Android* because the former will catch both Android and android.

Update: Sean points out in the comments that you can use all lower case letters in pattern matching and it will work with everything. For instance, *ndroid* here is not necessary because *android* would match with both Android and android. It does however not work the other way around, so *Android* would not match both. I wasn’t aware of this, and it saves you some hassle when dealing with case sensitivity.

/ acts as OR, meaning that it lets you insert multiple values in a single field. Inputting 1/2/3 in the value field and using Matches as the operator would match variable values of both 1, 2, and 3. This is very useful since it lets you create contexts and If conditions that react to several different variable values.

+ means “at least one letter.” You can see the use of this in the If/Else/End If screenshot above, in the very first action, where the If action is configured as %Todoshopping Matches ++. Tasker reads this condition as “If %Todoshopping contains at least two letters, no matter which letters they are.”

Empty variables

Empty variables will not be replaced by blank space; instead, they will retain their full variable name if referred to. If you create a notification with %Variable as the text and that variable doesn’t contain anything, then the notification will literally say %Variable. To make it display blank space instead, create a Variable Set action for that variable and set it to a space.

Use an If condition with the variable in question as the variable, Matches as the operator, and *variable-name-without-%-symbol* as the value (see the screenshot below to see what I mean by this).

Example for the variable %Home:

This writes a space as the value of the variable if it’s empty, which it detects by seeing if the variable value is the variable name. Note that you should insert the space in the text field last, and immediately save without selecting anything else. Otherwise you will likely get an error message saying that the field can’t be empty.

Processing data using variables

So far I’ve mostly talked about simple ways of using variables to transfer information and control actions and contexts, but that’s only half the story. For those who have read my older articles about Tasker, you’ve probably seen some articles which processed data internally in Tasker. Examples include a weather forecast announcer and calendar event announcer. What these have in common is that they process information after it has been imported into Tasker, essentially taking a single variable full of information and chopping it up into tiny pieces that can be used as settings or as dynamic text.

To do this, you use many of the tools available in the Variable category in the action list. Variable Split is one of the most powerful, but you’ll also find Variable Section, Variable Search & Replace, and others. Knowing how to use these gives you the ability to get Tasker to do practically anything, since more or less any text-based information source online or offline can then be used with Tasker.

Unfortunately, this is a massive topic to cover, and I’m already coming up on 4000 words from explaining the “simple” side of variables alone. As such, I want to dedicate an entire article to this topic later on in the series, after some of the more basic things are out of the way. I did however want to mention it briefly in this article as to not make people think I either forgot or that they’ve missed something.

Nelly is built on pattern matching variables

To finish off this part of the guide, I can mention that my DIY Tasker-based voice assistant, Nelly, is built (more or less) entirely on the concept of variables and pattern matching. It can be a good idea to read through that (old) article after reading this part of the guide to see how it’s implemented in practice and at such a large scale.

]]>https://www.pocketables.com/2012/08/beginners-guide-to-tasker-part-2-variables.html/feed7642278Beginner’s guide to Tasker, part 1: Tasker basicshttps://www.pocketables.com/2012/08/beginners-guide-to-tasker-part-1-tasker-basics.html
https://www.pocketables.com/2012/08/beginners-guide-to-tasker-part-1-tasker-basics.html#commentsFri, 24 Aug 2012 11:21:26 +0000http://www.pocketables.com/?p=33154Update: This is the original first part of the beginner’s guide, and it covers Tasker from the viewpoint of the

Update:This is the original first part of the beginner’s guide, and it covers Tasker from the viewpoint of the now old UI that’s only used on pre-ICS Android devices. An updated version of this guide is available here. As well as UI-related differences, the new version is also much newer in other ways, like references to other posts and examples. Pick the version of the guide that fits the version of Tasker you’re using, which depends on your Android version.

A part 0 has been added to the guide, talking about what Tasker is and how you can go about learning it. It’s available here. This part of the guide therefore jumps straight into talking about how Tasker itself works.

Tasks, profiles, projects, contexts, scenes, variables, and actions

These seven terms are important to understand in order to use Tasker.

Actions

An action is the most basic part of Tasker, a thing that the app does. Switching off WiFi is an action, going back to the home screen is an action, starting Angry Birds is an action, turning down the media volume is an action. Tasker have over 200 basic actions, and most of them have configuration options that make them capable of doing different things, like how the Media Controls action has five different options for which button it should emulate. Linking actions together allows you to do some truly amazing things with Tasker, things that go far beyond changing a setting or two when you leave the house.

Tasks

Actions are grouped in tasks. As an example, my Outside task has three actions: One for setting screen brightness, one for alerting me of items in my shopping list, and one for updating an online status file to say that I’m not home. Tasks can also be triggered with actions, so that a task can have several actions that run individual tasks, each with their own actions. This way you can group actions together into more meaningful tasks, and it allows you to reference a set of actions from different tasks. For instance, I have a task with several actions that update a widget, and this widget update task is used as a part of other tasks where updating the widget is necessary, like my reboot profile. Tasks can be triggered either by contexts, or directly using shortcuts, widgets, and other methods.

Contexts and profiles

A context is a trigger. An incoming notification, the opening of an app, or connecting to a certain WiFi network are all examples of contexts which can be used to trigger a task. If you want the GPS to turn on when you leave the house, you could for instance use not being connected to your home WiFi as the context, and have that trigger a task with an action that turns on GPS.

Unlike tasks, contexts can’t “live on their own.” They’re always the first part of a profile, and a profile consists of up to four contexts and one or two tasks. A profile is what links tasks and contexts together, deciding which task should run when the context triggers. Depending on the type of context (state or event), a profile can be active continuously or only momentarily. In cases where there are multiple contexts in a single profile, the relationship between them is AND (e.g. context 1 and context 2), meaning that both contexts have to be fulfilled in order for the profile to trigger. If a mix of event and state contexts are used, the profile will follow event profile rules.

An example of a state context is being connected to your home WiFi connection, in which case the profile is active as long as you’re connected. In such cases, tasks can be either enter or exit tasks, which decides whether or not the task runs when the profiles becomes active (enter task) or when it deactivates (exit task). Some actions, specifically actions that change settings, automatically revert to their previous state when the profile deactivates, without the need to specify that in the exit task. An example is screen brightness, and if a profile’s enter task sets the screen brightness to 100%, it will automatically go back to the old value when the profile deactivates.

Update: Rich from the Tasker Google Group points out that the actual task connected to the state context-based profile only runs once – when the profile becomes active. This is true, and a very important point. A profile that has only state contexts will be active as long as the context is met, however, the enter task will only run once. This means that if you for instance set the screen brightness using the enter task of a state profile, it’s possible for other apps and Tasker tasks to change the screen brightness while the profile is still active, without the profile being aware of this. In other words, settings will only persists if nothing else tampers with them. That means that it’s really the exit task that is unique with state context based profiles, as well as the ability to revert some settings automatically when the profile becomes inactive.

Another important thing to be aware of is that an exit task can sometimes run before the same profile’s entry task, if that entry task has a Wait action that delays part of the entry task for so long that the profile becomes inactive.

In an event profile, on the other hand, there is no continuous state. Receiving an SMS message is an example of an event context, triggering the profile momentarily to make the attached task run once. Such profiles can’t have exit tasks since there is no time difference between when the profile activates and deactivates (there’s no practical difference between when you start receicing an SMS message and you’re finished receiving it). Furthermore, it’s impossible to have more than a single event context attached to a profile. The reason is that since an event context by definition lasts only a split second, and the relationship between contexts is AND, having two event profiles would make the profile trigger only when two split second events occur at the exact same time, which isn’t likely to ever happen.

When an event context is used together with state contexts in the same profile, the profile becomes an event profile, like I mentioned above. In those cases, the profile triggers momentarily when the event happens, but only if the state contexts are fulfilled. For instance, you could have a profile with an SMS received event and a WiFi Connected state for your work’s WiFi network in order to automate what happens when you receive an SMS message at work.

You can also have up to four state contexts in a profile without an event context, in which case the profile is still a state profile. All the state conditions then have to be fulfilled for the profile to be active.

Variables

A variable is like a virtual text file within Tasker, or like a variable in math. A variable is represented by a % symbol followed by a name, like for instance %Variable1. Variables are used to get access to system information, transfer information between parts of Tasker, and even work as settings and options. The variable %DATE will for instance always be the current date, so if you were to tell Tasker to create a notification with the text %DATE, then %DATE would be replaced by the actual date when the notification appears. I’ll go into this in much greater detail later.

Scenes

A scene is essentially a customized user interface. You can user Tasker’s scene functionality to create menus, pop-ups, settings boxes, and much more. This is a very useful and complex feature that I will also cover in greater detail later.

Projects

A project is the final grouping in Tasker. Think of it as a folder capable of holding all of the above, so that you can keep everything related to a specific Tasker system in one place. The more complex Tasker setups often use multiple profiles, multiple tasks, and even multiple scenes all working together. You can group all of those together in a single project to stay organized.

The Tasker screen

Tasker has a beginner mode that is designed to make the app easier to use for beginners, by disabling certain features. Unfortunately, this sometimes causes problems because you end up having people refer to features that aren’t visible in someone else’s Tasker. As such, I’ll be basing this guide on the normal Tasker look, not beginner mode. To deactivate beginner mode, go to Tasker preferences (by clicking the menu button on your device), the UI tab, and uncheck beginner mode.

Knowing the difference between the various terms I explained above is half the battle when it comes to understanding how the UI works. The image above should help explain what everything is, but there are a few things I want to point out. The arrow you need to drag to hide/show the project tabs can be very hard to see, and very hard to grab even if you do see it. If you don’t see the top row of tabs from above, it’s because it’s hidden, and you need to try to find that arrow if you want to use projects to organize everything.

The icons next to profiles indicate whether a task is enabled. A green check mark means that it’s enabled, the red circle with a line going through it means it’s disabled. I point this out because some think the symbol indicates what will happen when you press it, not the current state. In the image above, you hence see one disabled profile and three enabled ones.

The single profile whose name is green above (Home) is currently active. A profile being active means that its context conditions are met, like if you have a location based profile and is currently at that location. That profile would then be inactive if you leave the location. If it’s disabled however, it won’t ever become active no matter if the context conditions are met. Profiles which contain event contexts cannot be continuously active in this way, as mentioned above, but then can be disabled to prevent them from triggering.

Finally, it’s worth mentioning that holding down on parts of the UI is the way to access a lot of features. It’s the way to import and export items, add more contexts to a profile, switch out tasks, turn enter tasks into exit tasks (or vice versa), and so on. Also, to delete items, you grab the right part of the screen besides their name (where the enable/disable icons ae for profiles) and drag them down to the trash can that appears. This is also how you sort items and transfer them to other projects: drag and drop.

What Tasker requires to work

When Tasker is active, there will be a constant notification icon present in your notification bar. This is to make sure the system will never close Tasker, as Tasker obviously needs to run at all times to work. This notification also shows which profiles are currently active, which is a quick way to keep track of your state profiles.

Some features in Tasker, specifically the ability to read notifications from other apps, require that Tasker has accessibility access. This is a system-level access that you have to manually give to Tasker by going to the device’s main system settings, accessibility section. I have this enabled in order to let Tasker see notifications from Gmail and run a task based on them.

Tasker also requires device administrator privileges for certain features, like manipulating the status of the lock code. This also has to be enabled manually, and if you do enable it, you will have to manually disable it to uninstall Tasker. This is another system level Android thing that you can read more about here.

Being rooted is not required for Tasker, but it does give it more abilities. The availability of certain actions and contexts is dependent on the device and software version/ROM, and being rooted can unlock features that are otherwise unavailable on a certain device. Tasker can also use root to kill apps, manipulate files, and so on.

There are dozens of plug-ins for Tasker, giving Tasker lots of new abilities. These plug-ins are available in the Play Store, and install as normal apps. Tasker shares the plug-in system with another automation app, Locale, and so many Tasker-compatible plug-ins are listed as Locale plug-ins. Furthermore, some apps have Tasker compatibility built in, meaning that installing the main app also unlocks the plug-in components in Tasker. The plug-ins can be accessed from either the third party or plug-in parts of Tasker (in the list of other actions/contexts) depending on whether the plug-in was built into Tasker or got installed on the side. If the accompanying app is installed, there’s no practical difference between actions listed in the third party section and those listed in the plug-in section, other than the name of the category they’re listed in.

Creating your first profile

The best way to learn Tasker is to tinker with it and explore. The configuration for each context, each action is different, and so it’s hard to generalize. The image below explains some of the buttons and options that are fairly common in the configuration screen for actions, while skipping those that are more unique to that particular task. Each action and context has different options however, and with the amount of contexts and actions in Tasker, explaining each and every one is a massive task.

There is however documentation for more or less all the features and settings in Tasker, and you can access this documentation by clicking the question mark icon present in the bottom right corner of many of the configuration screens in Tasker. You then get a brief explanation of the screen you’re on. It’s not always easy to understand the explanation, and there have been some (valid) complaints about the documentation for Tasker, but it’s still your very best friend when exploring Tasker.

The truth is that learning Tasker involves a fair bit of self study. This article, and future ones in this series, will cover how to use Tasker in general. Taking that and turning it into the specific profiles you need however requires some trial and error.

The video below shows the creation of a simple state profile with an enter task and (later) an exit task. My advise is to play around with the various contexts and actions and see what happens.

If you have any questions, don’t hesitate to ask. I’m also open to user requests for specific profiles/tasks which I can then create as examples in future parts of this series. You can also check out the Tasker tag for more articles on Tasker, but as those are written without beginners in mind, they might confuse more than anything.

Part 2 of this guide is now available here, and there are 7 parts to this guide in total. Find the complete list here.