I’ve previously written about how you can use AutoShare to access Google Now searches without having to split your voice command in two. That disables any voice feedback though, as well as other methods, which means that the alternative method- which does actually require you to split your command in two- is preferred by many. Personally, I don’t want to choose, so I merged them.

This is very simple and requires that you read the two articles linked above to actually understand each method. Once you’ve done that, create an AutoVoice Recognized-based profile with something like Google, Search, or something similar (or several) as the command filter.

For the task, recreate this:

Actions 2 and 4 are the respective main actions from the two previous articles, linked at the beginning.

What this does is simple. If you say just “google” (or whatever your trigger word is), it will open Google Now and start voice recognition, allowing you to speak the rest of your command, and get voice feedback and the other perks with this method. If you just need to do a search, however, you just continue talking, and it will instead use the AutoShare method to push your search query to Google Now without having to wait for Google Now to launch to continue talking. It does this by simply checking if %avcommnofilter is set; if it’s not, it means you stopped talking after you said the trigger word, and that means you want to use the Google Now voice recognition method.

It’s hardly the most advanced Tasker creation ever, but I think it’s a neat little trick, and it works well. This way you can quickly switch between which Google Now method to use, and you don’t even need multiple profiles and triggers.

The post Here’s a simple way to use Google Now dynamically with AutoVoice and Tasker appeared first on Pocketables.

Disclaimer: The Tasker PAI series is a series of Tasker articles “Provided As Is“. They are marked as such because there’s an above average likelihood that something will break very badly when used by someone else, for whatever reason, and I don’t have the time to fix it for everyone that happens to. Read more here. Articles in this series are only published so that those who know what to do with it have the chance, but questions to these articles will be ignored. 

A lot of people seem to be trying to use Google Calendar data in Tasker, and keep finding an old article of mine that was never meant to show how to do anything other than the specific thing in it, namely fetch the next event.

To try to make something a bit more universal, I sat down and created what’s best described as a Google Calendar plug-in for Tasker. If you feed it your private URL for a calendar, it will chop it up into tiny pieces and sort data into arrays that you can access.

This task is something I created fairly quickly, tested very briefly, and don’t plan on spending more time on. I’m 98% certain that there are better ways of doing this, but it’s not something I’m going to spend time on figuring out, because I have no use for it. I’ve successfully gotten it to work with both all day and more specific tasks (that’s what those If groups are for), but it will probably break for the weirdest of reasons, like time zones, Google Calendar format, device date settings, or who knows what. As such, I will only explain how it’s supposed to work, and beyond that, I can’t help you:

• Action 5 needs to be edited, and Path needs to be replaced with whatever comes after google.com/ in your private ICAL download link of your calendar. Not a public calendar, not an XML link; pricate ICAL. It should go something like https://www.google.com/calendar/ical/emailstuff/codestuff/basic.ics, where you copy the part in bold into the path field. You find the option in your calendar settings, Calendars, and then whatever calendar you want to use. 
• Action 9 controls how many events it fetches. %cal1 makes it fetch event 1, %cal2 makes it fetch event 2, %cal(1:10) makes it fetch events 1-10, and so on. %cal() makes it fetch all events and will likely take a while, since the ICAL download seems to contain a bunch of events. Look at the variable array section on this link to understand howto “program” this part.
• Actions 56-58 are disabled Flash actions you can use to test to see if it works, and also demonstrates how the variables created by this work.

When run, the task will generate 7 local variables for each event. It does so by creating 7 separate arrays. Each array will have one element (variable) for each event you fetch. The arrays are:

• %caltitle – the title of the event
• %calstartdate – the start date of the event
• %calenddate – the end date of the event
• %calstarttime – the start time of the event
• %calendtime – the end time of the event
• %calstartsec – the start date and time in seconds, Tasker standard
• %calendsec – the end date and time in seconds, Tasker standard

This means that if you have it fetch 3 events, you will have %caltitle1, %caltitle2, %caltitle3, and similarly for all the other arrays. The information for event 1 will be spread across %caltitle1, %calstartdate1, %calenddate1, and so on, and similarly for event 2, 3, etc. Event 200 will have its data in %caltitle200, %calstartdate200, and so on, if you try to fetch that many.

This uses local variables because otherwise it would be too slow. Transfer the data you actually need in intelligent ways if you run this externally.

Download: Calendar_Sorter.tsk.xml

The post Tasker PAI series: Google Calendar multi-event fetcher appeared first on Pocketables.

Most of the time, my Tasker articles talk about general concepts and ways of doing things, rather than provide step-by-step instructions. When I do provide something that looks like that kind of instructions, it’s normally in the form of examples. This has caused me to get a lot of requests for more detailed instructions, perhaps with a project download at the end, and sometimes I cave and do just that. It rarely ends well.

Tasker is a very unique app. You can have your first creation working after five minutes, and then a year later, you can still have problems getting something to work. It’s an app that has multiple levels of mastery built into it, and it’s only by exploring, trying, and failing that you will be able to learn how it works, and how to make something work.

Unfortunately, there’s a way to skip this natural learning curve: by looking for detailed instructions. The idea is that if you can just find someone who have or are willing to describe how to do something in extreme detail, you can just copy it, and everything will be peachy. That logic sounds solid, but unfortunately it’s about as wrong as it gets.

Android is fragmented. Extremely fragmented. The ridiculous number of hardware and software combinations is unbelievable, and that creates havoc for an app like Tasker, which taps into so many aspects of the OS. Many of Tasker’s abilities are completely and utterly dependent on factors such as hardware and software, and you have absolutely no guarantee that something that works on one device will work on another. Even two different ROMs based on the same version of Android and running on the same device can have drastic differences that will affect Tasker in various ways, and that’s the problem.

Detailed instructions create the illusion that when implemented, it should work. Sometimes it even does that, and everything is perfect in the world. More often than people realize though, issues pop up that throw the entire thing off, and what then? Well, if it had happened to the person who created the task/profile/whatever to begin with, it would likely take a minute or two to pinpoint the issue, because that person knows exactly how it works, and where things can go wrong. Then it would be a matter of finding a fix, which may or may not be possible, but at the very least the person would know what the problem is.

Unfortunately, the problems tend to happen to the people who try to copy something blindly, and they have no clue how anything works, which is why they copied it in the first place. So, how do you fix something that you have no clue how works? You don’t. Most of the time, that person then goes back to the person who initially created the instructions, asking why.

Sometimes that’s worthwhile, but I dare say that the majority of the time, it’s completely pointless. Without holding the device in question in your hand, seeing how everything works, trying to fix something that works for you but doesn’t work for someone else is just not realistic.

Personally, I hate posting anything that even remotely looks like detailed instructions. I still do it, because I feel obligated to help as many as possible, even though I know it’s likely going to blow up in my face. It’s amazing how very simple things can go horribly wrong when provided as detailed instructions, with a prime example being my Galaxy S4 wave-to-call profile. The profile took me mere minutes to set up, and everything worked 100% right away. I posted it, and the issues started coming in. Proximity sensors not working, call answering not working, microphone being muted, speaker being muted, and who knows what else. So much for the idea of a profile so simple that anyone could do it, which was what I thought it was when I posted it.

My advice to anyone new to or inexperienced with Tasker is to follow the advice from the first part of my beginner’s guide:

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. If you do put in the time and learn it, however, it will very likely revolutionize how you use your device.

There simply are no shortcuts when dealing with Tasker.

The post Why detailed Tasker instructions are not a good idea appeared first on Pocketables.

The Google Now method

Google Now is capable of auto dialing, but it’s not as hands free friendly as the voice dialer. Specifically, it falls short when there’s multiple options available, like multiple contacts matching your query, or multiple numbers for a contact.

The way to get around this is to be specific. Use first and last name if you have multiple contacts with the same first or last name, and if the person you’re calling has multiple number stored, mention which one you want. When it comes to the latter, you do need to add some filler words to actually make it understand what you want it to use, at least I have to do that on mine. For instance, “call Andreas mobile” just brings up a message saying contact not found, however “call Android on mobile” works. If you do this right, it should show a card with the contact, with a thin blue line that “counts down” until it audio dials.

To actually open Google Now in voice mode from AutoVoice, install Secure Settings. In Tasker, add the Secure Settings action from the Plugin folder, hit Edit next to Configuration, and then select Lanuch Activity. Select Google Search as the app, and then .VoiceSearchActivity in the drop down menu. Use this action in a task that you combine with an AutoVoice Recognized context for whatever word you want to use to trigger Google Now.

It’s also worth noting that Google Now needs to have been opened in voice mode for it to auto dial. By voice mode I mean that you need to trigger Google Now’s voice input option, not use it using the AutoShare method.

Advantages: 

• Doesn’t require a Bluetooth headset
• Same system as rest of Google Now

Disadvantages

• Not 100% hands free unless you’re specific
• Has an odd issue where it won’t call any contact whose name isn’t a person’s name. Seriously, try making a contact called “pizza” and try to have it call it, it will Google “call pizza” instead. How does this sort of thing make it into a final product, Google?

The voice dialer method

If you instead want to use the actual voice dialer, not Google Now, that’s possible too. To do this, you need to use Tasker’s Send Intent action, found in the Misc category. You need to configure it as follows:

Action: android.intent.action.VOICE_COMMAND
Package: com.google.android.googlequicksearchbox
Target: activity

Use this action in a task that you combine with an AutoVoice Recognized context for whatever word you want to use to trigger the voice dialer.

Advantages: 

• 100% hands free
• Doesn’t try to Google your contacts…

Disadvantages

• Voice recognition seems less accurate in some cases
• Annoying delays before you can speak
• Bluetooth only

In practice

The post How to voice dial with AutoVoice appeared first on Pocketables.

To chain together commands in AutoVoice you use command IDs, as explained in the AutoVoice guide. This normally works well, but there’s an inherent problem with this system, and it’s caused by how Tasker works. When you use an AutoVoice Recognize action and speak a command, each AutoVoice Recognized-based profile will be checked for matches, one by one, rather than all at once. This means that if you have two profiles that match, both will activate, but one will do so before the other.

The problem occurs when a Command ID-dependent context’s command filter also matches the command used to trigger the profile whose Command ID the profile is dependent on. I know that sentence is hard to swallow, so here’s an example:

Profile 1:
Context
Command filter: watch a movie on XBMC
Command ID: xbmc
Task
Action 1: (whatever action is used to open XBMC)
Action 2: Say: Which movie do you want to watch?
Action 3: AutoVoice Recognize

 
Profile 2:
Context
Command filter:
Last Command ID: xbmc
Task
Action 1: (whatever plugin is used to play a specific file)

The logic behind this setup is simple. First you have a command that opens up XBMC, then it asks you what you want to watch, and then you respond. Since you use the command ID system, you can then leave the command filter blank on the second profile, and just make it dependent on the first profile having run before it instead. Makes total sense, right? Yes, but this has a big chance of not working.

The reason is that Tasker might trigger profile 1 before it checks profile 2. If it does that, the command ID will have been set to “xbmc” by the time it checks profile 2. Because profile 2 doesn’t have a command filter, it will match any command, and since the command ID dependency is now filled, it will trigger almost at the exact same time as the first one.

How to fix it

Obviously this can lead to a ton of issues, which is why it’s a good thing that it’s easy to fix. All you have to do is to not specify a command ID in the first profile, but instead add a short Wait action followed by a Set Last Cmd Id action at the beginning of the task attached to that profile. This means that the command ID will still be set, but it will add just enough of a delay to allow Tasker to finish checking the other contexts before the command ID is set. Exactly how long the Wait needs to be will likely vary, but we’re talking a couple of hundred milliseconds here, which doesn’t really slow down your task.

The post An important note about chaining together commands in AutoVoice appeared first on Pocketables.

I often see people having issues with importing something to Tasker, and I sometimes include downloadable files in my articles so that I also need to explain how to import them. To avoid having to repeat the same instructions over and over, here’s a quick tutorial video that shows you how you do it in the new version of Tasker.

No text version this time, the video is king.

The post How to import tasks / profiles / scenes / projects into Tasker [Video] appeared first on Pocketables.

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.

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 creation and app exports, Tasker is capable of producing fully functional, standalone Android apps.

Tasker is a shell, not the contents

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. If you do put in the time and learn it, however, it will very likely revolutionize how you use your device. I don’t 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.

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.

Download: Google Play

The post Beginner’s guide to Tasker, part 1.5: Tasker basics (New UI) appeared first on Pocketables.

When setting up profiles with AutoVoice, you might find yourself wanting to specify more than one possible trigger word for a context. And example is my Portal sounds demo video (bottom of the post), which uses this a lot, allowing me to for instance use both “any tips” and “user guide” as trigger words for the same profile.

To do this, you simply have to enable Use Regex on the context configuration screen, and then use | as the “or” operator (that’s a vertical bar, not an L or the number 1). So, if you want the profile to trigger on either the term 1, 2, 3 or, you check Use Regex, and type 1|2|3 into the command filter box. That’s it. You can also use the regex option for more advanced pattern matching options, but this is the one that I’ve found myself needing when setting up profiles.

The post Quick Tasker tip: How to use multiple command filters in AutoVoice contexts appeared first on Pocketables.

After posting his initial AutoVoice home automation video, Doug Gregory posted another awesome video, where he uses sound effects and graphics from the Portal video game series to give his voice command system an identity that fans of the games will love. I love the idea, so I went ahead and borrowed it for my own setup. It’s not hard to do, but here are some quick details to help anyone who wants to do the same.

(If you have no clue what Portal is, you’ve missed two of the best video games ever made)

First off, you obviously need the voice files. They’re luckily very easy to get a hold of, as it seems that Valve (the company behind Portal) doesn’t  run around killing harmless fan sites, unlike most companies. As such, these files are both available and sorted online. The sound files used in Doug’s video are from the turrets in the game, and can be found here, among other places. That link has a list of all the files, with what they say, and can be downloaded directly as MP3 files. Additionally, GladOS’ voice from the game is very similar, and mixing the two does give you more options. Those files can be found here.

All you really need to do is to download the files, place them on your device, and then use them using the Music Play option in Tasker. Note that Music Play makes the task continue before the sound finishes playing, so you might need to add Wait actions if you find that the sounds interfere with other things, like voice control input.

As for the graphical interface Doug uses, I didn’t copy that, but it’s easily done using Tasker scenes for anyone who wants to use it. I also really like his idea of using AutoNotification to enable a notification that allows him to activate the voice system from there, which is done with AutoNotification.

Some examples of my own implementation of this can be seen in the video below. Some of it’s similar to Doug’s, and just taps into my existing home automation tasks. I did however do a couple of new things, like using a combination of Variable Randomize and Music Play to enable more than one possible reply to certain queries. To do this, put all the files you want to use for a specific reply in a separate folder, and name them 1, 2, 3, etc. Then, in your task, use a Variable Randomize action to randomize a variable (like %soundno) with a minimum value of 1 and a maximum value of whatever your highest numbered sound file is called. Then use the Music Play action, and input the path to one of the files. Replace the number in the file name (but not the file extension) with the variable you randomized.

I also added some easter eggs like playback of the turret opera and the two ending songs for the Portal games, based on a comment I saw on Doug’s video on Reddit. That’s done by simply using the Open File option, with default apps already configured.

So with that in mind, here’s my implementation of this:

The post How to use Portal sound effects in Tasker [Video] appeared first on Pocketables.

AutoVoice has gotten a lot of attention lately, as it should. More and more people are looking into creating their voice assistant after seeing what other people are doing with it, and that means that Google Now suddenly has a sibling on many people’s phone. It can be troublesome to have two separate services that you need to trigger, but luckily it’s very simple to merge the two.

The video really explains it better this time, but here’s a quick written version:

Download AutoShare, a Tasker plugin from the same developer as AutoVoice, joaomgcd. When installed, go to Google Play, go into any app, and hit the Share button. Select AutoShare Intercept, then the Google option in the next window. This will let AutoShare capture the data needed to send info to Google’s voice search, aka Google Now.

Next up, create your AutoVoice profile, using whatever keyword you want to search in Google Now. “Google” is the obvious choice. For the attached task, select AutoShare in the Plugin category. In the configuration menu, use the option Use Last Intercept. Scroll down to the Text field, delete what’s there, and enter %avcommnofilter. Save out.

That’s it. Now, whenever you use the keyword “Google,” it will put the rest of the command (i.e. it will drop the word Google) into Google Now.

Obviously, this can also be used for integrating Google Now with other Tasker creations. All you’d have to do is use something else besides %avcommnofilter in the Text field, and use the action in something besides and AutoVoice profile. An example would be to set up an AutoRemote profile so you can search for something in Google Now using an AutoRemote command from somewhere else, like the Chrome plug-in.

Update: Several people have pointed out that this won’t respond to you with voice. That’s correct, and it’s not the only thing that’s different from using Google Now directly. That’s because this is technically a text search that you’ve filled in with voice data, rather than a voice search. To get voice feedback, you need to use AutoVoice to open Google Now and activate voice input, meaning you need to split your command in two.

The post How to use Google Now from AutoVoice using AutoShare and Tasker appeared first on Pocketables.

Many people, me included, like falling asleep to some sort of audio, be it music, a podcast, an audio book, or something else. Tat is why any audio player app with respect for itself comes with a sleep timer, allowing you to set it to shut itself down after a certain amount of time. The problem with sleep timers is that they’re static. You have to guess a timer length that you think will work for your current level of sleepiness, but a lot of the time, it’s just a wild guess. A two hour sleep timer might shut off your audio book while you’re still awake and listening, or it might leave you trying to figure out where you fell asleep.

I just loaded some audio books onto my phone, and heading into a period of falling asleep to those, I got an idea to make a dead man’s switch. A dead man’s switch is essentially a switch that triggers when the person controlling it is no longer capable of preventing it from triggering, normally because he’s dead.

My first thought was to create something that I would have to squeeze in order to keep active, and that would then send a signal to my phone when I let it go from falling asleep. That’s actually simple enough to do; just take a Bluetooth headset, open it, and rewire one of the wires going to the battery through some sort of button that you need to hold down to give it power. Then, in Tasker, add a profile for that Bluetooth device being connected, and add you actions to the exit task. When you let go of the button, the battery is disconnected, disconnecting the headset, triggering the profile.

My problem with this however was that holding down a button for an extended period of time while trying to sleep sounded less than ideal. Then, I had another idea, and I went digging for something I created last year: a Tasker voice control bracelet. Back then it was the first prototype for a bracelet for controlling Tasker with voice, but I gave up on it due to there not being anything like AutoVoice back then, and eventually gave up on voice control altogether, instead favoring other controls methods. I was able to find the bracelet, and eventually also a charger.

Thebracelet is essentially a sock with a Bluetooth headset inside, with the charge port and control button sticking through. I added a bit of hot glue to the button to make it easier to press, and that was actually all I needed. I then set up a profile in Tasker, using AutoVoice’s Bluetooth button feature as the context. This allows you to trigger a task when a button is pressed on a Bluetooth headset. The task I added is as follows:

Music Play (short notification sound)
Wait, 10 minutes
Music Play (short notification sound)
Wait, 15 seconds
Music Play (short notification sound)
Wait, 15 seconds
Kill app (the audio book app) using root
Profile Status (Dead Man’s Switch), set Off

I also went into the settings for that app and changed the collision handling to abort the current task.

So, what does this do? When I’m listening to my audio book, I can turn on the bracelet and click the button once. This plays a confirmation sound, and then waits for 10 minutes. It then plays the sound again, waits 15 seconds, plays the sound once more, waits 15 more seconds, and then kills the audio book app, followed by it deactivating its own profile so it can’t re-trigger accidentally.

If I however click the headset button at any time during that 10.5 minute period, it will abort the task, restart it, and reset the timer. This way, as long as I keep pressing the headset button at least once every 10 minutes, the app will stay alive. When there’s 30 seconds left, it lets me know that the timer is about to expire, so that I don’t simply forget to press the button. If I fall asleep, I obviously stop pressing the button, and the app will be killed within 10 minutes. That way, when I start back up, I only have to back track a maximum of 10 minutes to find where I left off, which is far easier than with longer sleep timers.

I also have a second profile, which uses the Bluetooth Connected context for the bracelet. When it connects, it re-enables the profile, and when it disconnects, it kills the audio book app, stops the Dead Man’s Switch task, and deactivates the profile. If I didn’t have my smartwatch connected, however, I would just disable Bluetooth at the end of the profile, rather than disable the profile.

I’ve tried this setup up in practice, and it works great. I might experiment with setting the timer to 5 minutes, but honestly, it’s very easy to find where you left off when it’s within a 10 minute period. It’s also not an issue (for me at least) to have to press the button once every 10 minutes, and the bracelet doesn’t bother me.

While I am using a custom made bracelet, you only really need a cheap, off the shelf Bluetooth headset to this this yourself. The bracelet can be put around my hand so that the button is in a very natural place, and it has the added advantage of being soft and not being in the way or disappearing after I fall asleep, Other than that, you don’t need to break out the sowing kit to do this.

I also think this basic method has potential for other uses. It basically gives you the ability to attach wireless buttons to anything you want, and with the cost of Bluetooth headsets, it won’t cost an arm and a leg to do so. All thanks to AutoVoice.

The post Creating an audio player dead man’s switch using a BT headset, Tasker, and AutoVoice appeared first on Pocketables.

While this is obviously more limited than NFC in that it doesn’t transfer any information in the process (and thus is less dynamic), it does give those of us with a NFC-less phone a way to create a physical trigger for a single use purpose. Car docking is a very common use for NFC, and so using this as a replacement allows you to do the same without NFC.

For those afraid of magnets and electronics, that’s a myth left over from the old days. There’s not really anything in today’s electronics that’s traditionally affected by magnets, with the exception of the compass, which won’t work correctly while in close proximity to a magnet. It is however advisable to do like Christopher and put the magnets on whatever you’re attaching the thing to, leaving the device with only some magnetic metal.

I think this is a great idea, and a brilliant use of a normally overlooked feature of Tasker. I’ve tried to find something to use that context for myself in the past, without succeeding, but I might have to take a second look at it now.

Thanks, Christopher!

The post Use Tasker’s Magnetic Field context as a makeshift NFC replacement appeared first on Pocketables.

Get Voice vs AutoVoice

Setting aside AutoVoice features like Bluetooth headset support for a second, it’s important to understand how AutoVoice is different than the Get Voice action that comes with Tasker.

Get Voice works on a very simply principle: use speech to text, shove the entire result in the %VOICE variable, and move on. That’s all it does. That means that it’s up to the user to take that variable and do something with it, which normally means a lot of If conditions and Variable Splits to try to get to the information you actually need. My Nelly voice assistant is a perfect example, and it has a ton of If conditions to make it work.

AutoVoice, on the other hand, is built from the ground up to be used for voice control. You have an action that initiates voice recognition (AutoVoice Recognize action), and then you have profile contexts that actually trigger based on the response (AutoVoice Recognized context). This means that in most cases, AutoVoice Recognize is the last action used in a task that uses voice control, and instead the task “continues” in a new task tied to a profile, where the profile triggers based on the response.

Furthermore, AutoVoice gives you a lot more options for accessing the data it got from speech recognition. First off, there’s %avcomm, containing everything, the same way %VOICE does. Then you have %avcommnofilter, which is everything except for the trigger phrase/word. Finally, you have %avword1, %avword2, %avword3, and so on, which contains each separate word.

As an example, let’s say you speak the phrase “hello how are you today”. You have a profile set up with Command Filter “hello”, which means it will trigger when it hears the word “hello”. The above variables will then be as follows:

%avcomm: hello how are you today
%avcommnofilter: how are you today
%avword1: hello
%avword2: how
%avword3: are
%avword4: you
%avword5: today

Command ID

One of the big advantages of AutoVoice is the Command ID system. This allows you to limit profiles to only triggering after other profiles, allowing you to create chains of commands.

For instance, you might have a task that ends with asking you a yes/no question, and then triggers an AutoVoice Recognize action to let you respond. The problem with this is that “yes” and “no” are very non-specific, and you might end up having a dozen tasks that asks for a yes or no. If you just added profiles that activated based on “yes” and “no”, all of the ones for “yes” would trigger at once!

This is what Command ID is there to prevent. When adding the AutoVoice Recognized context, you can specify Command ID and Last Command ID. If you specify something in the Last Command ID field, the profile only activates if the last profile that activated had that same thing specified in Command ID. The video below shows this, and more, in action:

It’s also important to be aware of the AutoVoice Set Cmd Id action. This can be used to manipulate Command IDs without doing it directly in the profile. There are two options:

Clear Last Command ID

This clears the Command ID for the last profile that ran. If profile 1 has the Command ID “hello”, and profile 2 has Last Command ID “hello”, that means that profile 2 will only run after profile 1. However, if you use the Clear Last Command ID action after running profile 1, profile 2 won’t run, because the Command ID set by profile 1 will have been cleared.

Set Last Command Id

This allows you to set a Command ID without having a profile do it. Using the above example, if you used this option with “hello”, it would allow profile 2 to run, regardless of whether profile 1 has.

Home automation example

The home automation video posted by Doug Gregory is very impressive, but actually not hard to set up. I haven’t seen his exact profiles, but here’s how I assume he did it.

In the video, you can see him use all sorts of highly dynamic commands. He uses different phrases, mentions several appliances in one command, and so on and so forth. 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 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.

The point is that the video makes it appear as though the voice assistant used is beyond intelligent, understanding absolutely everything he says perfectly, no matter what phrasing he uses. Instead, the system has simply been simplified so that it reacts to very specific keywords, and ignores everything else.

Other features of AutoVoice

AutoVoice has more features than I’ve covered in detail above, but I think the basic system of how everything works is what is most difficult. As such, I’ll just briefly mention the rest.

AutoVoice is designed to work with headsets, which Get Voice isn’t. You have a lot of different features relating to this, from options here and there to separate contexts and actions. You have two contexts called AutoVoice BT Pressed, which can be used to react to button presses on a Bluetooth headset. You basically put whatever you want the button to do in the task attached to the profile, and off you go. You can of course combine this with other contexts to create situation-aware button functionality.

You also have a context called AutoVoice Rec Failed. This allows you to specify a task that runs when the voice recognition fails, so that it doesn’t just ruin your entire chain by mishearing a word. In most cases, it’s logical to tie this to a simply re-triggering of the AutoVoice Recognize action, giving you another chance.

Finally, you have the AutoVoice Ctrl BT action. This makes it so that all sound goes to your Bluetooth headset, and you could for instance create a profile that activates this when the Bluetooth device is connected.

AutoVoice is a great plug-in, and it’s essentially the Get Voice Extended Edition. Some might get by with just Get Voice, while others truly put AutoVoice’s additional features to good use. It’s possible to do a lot of things with this, from creating home automation systems, to controlling music, to even doing things like telling XBMC to play the latest episode of a show. The sky’s the limit.

Download: Google Play

The post How to use the AutoVoice Tasker plug-in appeared first on Pocketables.

I’ve had the pleasure of having a Tasker-controlled home automation system for a while now, and I’ve been loving it. My tiny student apartment isn’t exactly the best place to stuff in a lot of gear, however, so I’ve been rather limited as to what I can do. That’s why I couldn’t help but smile from ear to ear when I saw Reddit user droidkc’s Tasker-based home automation system on reddit yesterday, as that really takes it all out and shows what’s possible when you don’t live in a shoe box.

There’s a lot of hardware and software that goes into the setup, but key to the whole system is Tasker and the AutoVoice plug-in. It’s hard to imagine a better advertisement for AutoVoice, as it truly shows what’s possible with the plug-ins ability to chain together commands, and I don’t think anyone can argue with the result. In fact, after seeing this, I’ll definitely be doing a guide to AutoVoice in the near future.

In the mean time, you can check out some additional information about this setup over in the original reddit post.

Awesome job!

The post Check out this awesome Tasker/AutoVoice home automation setup appeared first on Pocketables.

So, well, I sat down and created it in Tasker. It’s extremely easy to do, so to add something extra, I also added the ability to automatically call back or reply with an automated SMS as options for cancelling the alarm. It’s still very easy to do, and here’s how.

Disclaimer: While I have written this article from a beginner perspective, it might still be confusing to those new to Tasker. I really do recommend reading the beginner’s guide before dealing with any other Tasker article. There is however a download link at the end that can help make this usable “out of the box”. 

First off, you need a profile to actually trigger when receiving said SMS. This is easy. Create a new profile, select the Event category, then Phone, then Received Text. You can fill out the Sender and Content field however you like, to customize who can send you an SMS like this (sender) and what phrase triggers it (“wake up” in this case). You can specify multiple options and more advanced filters using Tasker’s pattern matching system. For this example, I just set it so any text containing “wake up” (which also matches WAKE UP) would work.

Next, the task. First, to make sure that the alarm will be played despite volume settings, we start off with an Alarm Volume action from the Audio category, and set that to 7. Next, we need to play a sound. In the Media category, select Play Music, and find whatever audio file you want to use as the alarm sound. Also make sure you specify Alarm as the Stream option for the Music Play action.

Note: It would make sense to use Play Ringtone here, but it seems to be bugged right now, with a standard Stop action not stopping it on my device. As such, we need the ability to use Music Stop. 

Finally, select the Menu action from the Alert category. Fill in the title field with something you want the pop-up to say, like “Wake up alarm activated”. Scroll down to Items, click the + symbol, and then click the Action button that appears. Select Music Stop from the Media category, then fill in the Label field however you want. You can also click the icon to the left of the label field to give it a better icon.

This is all you need to do for the basic SMS alarm functionality. The rest of the article will cover how to get the additional phone back and reply with SMS options.

After that, go all the way out of the task, and add a new task (not a profile). Give it a name that you remember. As the first action, add the same Music Stop action as above. As the second action, find the Call action in the Phone category, and put in %SMSRF as the number. This is the number of the last received SMS, in other words the number of the person who woke you up, unless someone sent an SMS in the seconds between than and you clicking the button. If you want it to auto-dial (rather than just ask you to call), check the Auto Dial option.

Save that task, and create a new task. Once again add Stop Music. Then add the Send SMS action from the Phone category, and fill in %SMSRF as the number. Put in whatever you want the pre-defined message to be in the Message field.

Now go all the way out of Tasker (to update internal task references), then back in, into the original task for the profile, and into the Menu action. Add two new Menu entries using the + button. Select Action for one of them, then the Task category, and Perform Task. Click the magnifying lens symbol next to Name, and find one of the tasks you just created in the list. Go back, give it a label and icon if you want. Repeat with the final Menu entry, for the second task.

That’s it, you’re done!

As with everything else Tasker, this is just one example of how to do it. You can customize it however you want, including completely different options for the Menu.

Final result (I replaced the Send SMS option with a Flash message to avoid replying to myself, and to make it more visual):

Project download:

This file contains all necessary files for the extended version of this, including the custom Menu template I use. You do however need edit the Play Music action and specify your own audio file.

Download link

How to import:

Option 1: Manually place the Sms_Wake_Up.prj.xml file in the Tasker/projects directory. Go into Tasker, long press a project tab (e.g. the house icon), select import, and then Sms_Wake_Up.

Option 2: Open the download link on your phone, and download the file. Open it and choose the Tasker option. Go into Tasker, long press a project tab (e.g. the house icon), select import, and then Sms_Wake_Up.

The post How to create an SMS-triggered wake up alarm in Tasker appeared first on Pocketables.

The idea is simply to use Voice Control as a way to answer calls without using your hands. Unlike wave-to-answer, it has the ability to by fully hands-free, and it also has the ability to do more than one thing, since you can use dynamic commands. You can also combine it with wave-to-answer to actually trigger it, rather than have it always be there.

Creating something like this in Tasker isn’t all that hard, but it’s definitely more complicated than the wave-to-answer feature, and you’ll need to be comfortable with variables to do it. The “problem” is that you can do anything you want here, so providing a step-by-step guide is sort of counter-productive. Instead, I’m going to provide you with a couple of examples, showing you various ways this can be implemented. If this is your first foray into Tasker, you shouldn’t start with this, but rather the basics.

Example 1: Fully hands free voice control system

First off a video to show you how this version of the system works:

The advantage of this is that it’s completely hands free, requiring no waving or other gesture to activate. The disadvantage is that it needs to be used in silent mode to avoid the ringtone and vibrations to interfere with the voice control recording, which means that you basically need to be nearby to hear it go off. It is however possible to configure it to for instance play an alarm sound for a few seconds before doing anything, but since this basically needs to go through the motions to get to the voice control aspect, that means you might end up waiting longer than necessary to pick up.

Anyways, here’s the profile description:

Profile: Voice Control Call Answer
Restore settings disabled

Contexts:
State: Phone Ringing
State: Not Proximity Sensor

Task:

• Say [ Text:The phone is ringing, what should I do? ]
• Get Voice [Timeout (Seconds):20 ]
• If [ %VOICE ~ *answer* ]
  • If [ %VOICE ~ *speaker* ]
    • Take Call
    • Wait [Seconds:1]
    • Speakerphone [ Set:On ]
  • Else
    • Take Call
  • End If
• Else
  • If [ %VOICE ~ *decline*/*hang up*/*shut up* ]
    • End Call
  • Else
    • Say [ Text:Sorry, I didn't get that ]
    • Goto [ Type:Action Number Number:2]
  • End If
• End If

This example uses an inverted proximity sensor context to only make this run when the phone isn’t in a pocket or other such place, but other examples of ways to control when it’s active would be when you’re at the office, when the phone is flat on the tablet, when you’re in your car (Bluetooth connected context), and so on.

It starts off by asking what to do, which is essentially a replacement for the ringtone, since this won’t work well with a ringtone of vibrate activated (the sound would interfere with the voice control). It then waits 20 seconds for a reply using the Get Voice action.

After that, it checks the contents of %VOICE, which stores the voice input from Get Voice. If it contains the word “answer”, it does another check to see if it also contains the word “speaker” in any form (speaker, speakerphone, etc). If it does, it answers with speakerphone activated, if not, it simply answers.

If %VOICE doesn’t contain “answer”, on the other hand, it checks for a variety of other phrases that essentially mean “hang up”, such as “decline”, “hang up”, and “shut up”. You can specify multiple possible options using the / symbol when creating If conditions, and this is just a way of making it more dynamic in what it responds to. If it detects this, it simply hangs up.

Failing all of the above, it simply assumes that it didn’t hear you correctly, lets you know this, and returns to the Get Voice action to try again.

Example 2: Proximity sensor-based voice control trigger

This isn’t much different than the above, but it works very differently. By combining the above profile with aspects of the wave-to-answer profile from yesterday, you gain the ability to keep using vibrate and ringtone functionality like usual, and simply trigger the voice control option with your hand. It looks like this in practice:

The profile is nearly identical, and looks like this:

Profile: Proximity-activated Voice Control Call Answer
Restore settings disabled

Contexts:
State: Call [ Type:Incoming ]
State: Proximity Sensor
State: Orientation [ Is:Face Up ]

Task:

• Silent Mode [ Mode:On ]
• Say [ Text:What should I do?]
• Get Voice
• If [ %VOICE ~ *answer* ]
  • If [ %VOICE ~ *speaker* ]
    • Take Call
    • Wait [Seconds:1]
    • Speakerphone [ Set:On ]
  • Else
    • Take Call
  • End If
• Else
  • If [ %VOICE ~ *decline*/*hang up*/*shut up* ]
    • End Call
  • Else
    • Say [ Text:Sorry, I didn't get that ]
    • Goto [ Type:Action Number Number:2]
  • End If
• End If
• Silent Mode [ Mode:Off ]

The main difference is the contexts, which now uses the logic from yesterday’s post to trigger this profile. Since the profile is now not triggered by the call itself, but rather the moment the proximity context is fulfilled, we also need to enable silent mode at the beginning of the task to mute the phone while it does the voice control aspects. Because disabling Restore Settings is necessary for this to work, we also need to manually re-enable silent mode at the end of the task- all we need is for it to be silent while the voice control actions are at work.

Update: This profile uses the Call state context, which actually refers to a call in progress, not just the phone ringing. This is because the context that detects the ringing is an Event context, meaning it will trigger right when the phone rings, rather than stay active while it’s ringing. Since we need to use the proximity sensor as the actual trigger for this, we can’t use that Event context, so we have to use the Call context. Because of this, the profile will re-trigger if anything is detected by the proximity sensor while the call is active. This shouldn’t be an issue for most people, but if it is, there are several ways of fixing it. Here’s one example that I’ve tested to work:

Create a new profile, choose the Event category, and pick Phone Idle as the context. That means the task attached to it will run once when you hang up. Add a task, go to the Tasker category of actions, and pick Profile Status. Find the wave-to-answer profile in the list, and set it to turn it on. Next, go into the task for this profile. At the very bottom, add a new action, find the Profile Status action again, specify the same profile name, but now set it to turn it off.

What this does is that the task now disables its own profile when it’s done doing everything else. The profile is however re-enabled the moment you hang up your call, meaning it’s ready for next time.

Other customizations

Like I said, these are just two examples. You can do things slightly differently, or you can use completely different methods to arrive at the same basic functionality. You can split things out into different profiles to achieve different functionality, integrate it with existing creations, and so on and so forth.

You can also customize the actions that run based on %VOICE in completely different ways. You might not need the ability to reply without speakerphone at all, which means it would be silly to have it there. You might however want an option to hang up, but reply to the person with an SMS, either using voice-to-text or other methods.

I should also note that because the phone is still ringing until the voice control feature finishes, it’s advisable to not have Say actions go on forever, as that would risk the person hanging up or being sent to voice mail. In fact, simply dropping the Say action at the beginning might be a better solution for some when combining this with proximity activation.

This is simply one of those creations where the basic idea is what I’m trying to get across, rather than providing a specific way of doing it. I showed you two examples, but there’s an infinite number of ways to do this. Either way though, it is sure to ruin the day of someone with a new S4- unless of course they’re aware that the device they’re buying is not special, in which case they can of course implement this on an S4 as well.

The post How to one-up the Samsung Galaxy S4 with a voice controlled call answer feature in Tasker appeared first on Pocketables.

Note: This article has been updated several times, so make sure to read the entire thing before doing anything. There’s now both a downloadable profile and a video tutorial.

As for as Tasker creations go, this one is extremely simple, but then again that just goes to show how pathetic it is for Samsung to brag about putting it in a phone. You only need a single profile, and it looks like this:
Context 1: State->Phone->Call, type: Incoming
Context 2: State->Sensor->Proximity Sensor
Context 3: State->Sensor->Orientation, is Face Up
Task:
Action 1: Phone->Take Call
(Action 2: Task->Wait)
Action 3: Audio->Speakerphone, set: On

Action 2 is optional and can be added and configured if having the Speakerphone action right after Take Call ends up not working.

You also have to go into the profile settings and disable “restore settings”, or it will turn off the speaker phone immediately after turning it on.

This is all you need to set this up, and the result is as follows:

There’s a bug with the phone app so it doesn’t show the speakerphone being on in the video, but you can hear it right when I hang up.

As Pavel points out in the comments, this doesn’t detect hand movement, but rather uses the proximity sensor. This means you need the Face Up context to make sure it doesn’t go off accidentally when in a pocket, face down, or something like that. You can also filter it further by for instance adding location contexts so that this only works at home or in the office.

PS: Last year I replicated two S III features using Tasker: Smart Alerts and auto-syncing MP3 player accessory.

EDIT: For anyone using Tasker for the first time with this setup, here’s a link to download the profile. Visit the link on your device, then hit download, and click it once downloaded. It should prompt you with an option to open in Tasker. Once that’s done, go to Tasker, single click the Profiles tab, hit Import, and select Wave To Reply. Turn on the profile if it’s not on, and exit Tasker to test it out.

EDIT 2: This profile uses the Call state context, which actually refers to a call in progress, not just the phone ringing. This is because the context that detects the ringing is an Event context, meaning it will trigger right when the phone rings, rather than stay active while it’s ringing. Since we need to use the proximity sensor as the actual trigger for this, we can’t use that Event context, so we have to use the Call context. Because of this, the profile will re-trigger if anything is detected by the proximity sensor while the call is active. This shouldn’t be an issue for most people, but if it is, there are several ways of fixing it. Here’s one example that I’ve tested to work:

Create a new profile, choose the Event category, and pick Phone Idle as the context. That means the task attached to it will run once when you hang up. Add a task, go to the Tasker category of actions, and pick Profile Status. Find the wave-to-answer profile in the list (you need to have given the profile a name first, which you do by long pressing on the title and giving it a name), and set it to turn it on. Next, go into the task for the wave-to-answer profile. At the very bottom, add a new action, find the Profile Status action again, specify the same profile name, but now set it to turn it off.

What this does is that the wave-to-answer task now disables its own profile when it’s done doing everything else. The profile is however re-enabled the moment you hang up your call, meaning it’s ready for next time.

EDIT 3: Video tutorial

The below video is a complete video tutorial showing how to add this from scratch in Tasker. I tested the finished profile I created in this video afterwards, and it works perfectly on my phone/ROM. It answers the phone, turns on speakerphone, and the mic works, every time.

If you follow this exactly and you end up with a different result, then unfortunately there’s nothing I can do. The unfortunate truth is that devices and ROMs do things slightly differently, and there’s never a guarantee that something that works on one device will work on another. The only remedy is to head over to our beginner’s guide and learn Tasker from scratch, pinpoint exactly what fails, and come up with something that works on your specific device.

EDIT 4: 

It seems that Take Call doesn’t work with a lot of ROMs out there, due to something Google changed for the sake of being di…for the sake of “security”. The Tasker plug-in Secure Settings does however allow you to do it with root, by using the Phone Options action found in the Secure Settings configuration screen when selecting that action in the plug-in category.

The post How to replicate the Samsung Galaxy S4′s Air Gesture call answer feature with Tasker [Update: Video tutorial] appeared first on Pocketables.

After uninstalling Action Launcher Pro because of its lack of features, I started thinking that perhaps I could replicate the things that made it interesting in the first place. I started thinking about ways of giving home screen shortcuts the ability to have more than one feature, and I think what I came up with has potential for a lot of things.

Basically the concept here is to create a task that is capable of counting how may times you tap the shortcut that launches it, and base what it does on that. There are several ways of doing this, but these are the two best I’ve found so far.

Dual mode shortcut

• If [ %Dttest ~ 0 ]
  • Variable Set [ Name:%Dttest To: 1]
  • Wait [ MS:300]
  • Variable Set [ Name:%Dttest To: 0]
  • Flash [ Text:Action 1]
• Else
  • Flash [ Text:Action 2]
  • Variable Set [ Name:%Dttest To: 0]
• End If

Abort Existing Task checked in task settings

This is then added to the home screen as a Task Shortcut, and works as follows:

The task shares basic similarities with a toggleable task. It runs one of two sets of actions, depending on the value of a variable, here %Dttest (“Double tap test”- my naming logic). Both action groups end with setting that variable to , which means that it will always be 0 when the task first launches, thus running the first action group. This action group flips the variable over, waits 300 milliseconds, then sets it back and does a Flash action, which is here a stand-in for anything you want a single tap on the shortcut to do (could e.g. be to launch an app).

However, the task is set with collision handling to Abort Existing Task. This means that if the task is run while already running, it will stop running the first instance of it, giving the second priority. This is not the default setting, which is to abort the new one instead. By using this setting (accessed from the settings icon in the task’s action list), tapping the icon a second time right after the first (within 300ms- the Wait action) will actually abort the first task before it has a time to run the Varible Set for flipping %Dttest back to 0. The trick here is to tap at a speed that makes it abort the task after %Dttest is set to 1, but before it’s set back to 0, meaning in the Wait period.

Since %Dttest will then be 1 when the new task runs, because the first task wasn’t able to finish, it will run the second set of actions, found in the Else group. The result is that single tapping runs what’s listed under If, and double tapping runs what’s listed under Else.

Here’s how this looks in practice:

Multi-mode shortcut

This example above shows a dual mode shortcut, but it’s possible to make it have more modes. To do that, you create a task that looks like this:

Variable Add [ Name:%Dttest Value:1]
Wait [ MS:300]
Flash [ Text:Action 1] If [ %Dttest ~ 1 ]
Flash [ Text:Action 2] If [ %Dttest ~ 2 ]
Flash [ Text:Action 3 If [ %Dttest ~ 3 ]
Variable Set [ Name:%Dttest To: 0 ]

Abort Existing Task checked in task settings

It works on the same basic principle, but it counts actual number of times the shortcut is clicked, rather than working on a once/not once principle. The advantage is that it’s perhaps easier to understand, and it’s more dynamic with number of modes. The downside is that it won’t simply revert to the last option available if you tap too many times. By that I mean that if you triple tap on the first example, the one that uses If/Else, it will trigger the second action group, meaning it’s more forgiving for tapping too much. That might not be enough of an advantage to warrant the first method ever being used, but I thought I would include it since I’m just experimenting with different methods here and there might very well be another way that’s much better than this altogether.

Important to note about both methods

Both methods might fail for various reasons. I’ve tested this in Apex launcher, and as you can see it works, but I don’t know if every launcher out there conveys shortcut presses quickly enough to allow for this to work, or if they convey multiple taps at all.

The timing for the Wait action is also dependent on various factors, such as how fast your device is, how fast you plan on tapping, etc. You basically just need to experiment.

What this can be used for

I originally made this based on the Shutters feature in Action Launcher Pro, and plan on posting more specific details to replicating that functionality in a separate post. This has a lot of uses though, and allows you to stuff more into a shortcut without using folders. You can for instance have an icon that launches the phone app, contacts app, or messages app depending on how many times you tap it, or an email icon that launches private or work email clients depending on the number of taps. This could also be used as a security feature, launching a dummy email client with no sensitive accounts if tapped normally, but launching the proper one if tapped twice (should be combined with hiding the app from the launcher).

You could also be more creative, like having a double tap on Dropsync trigger a “sync now” shortcut, just to name one app that I have which has a very specific shortcut action available. The camera icon could have a double tap feature to go to video directly, a Facebook icon could have Facebook Messenger as the second option, and so on. Lots of possibilities!

The post How to create multi-mode homescreen shortcuts with Tasker appeared first on Pocketables.

Disclaimer: Advanced Tasker is a series of Tasker articles that go beyond the beginner’s guide, and that’s aimed at those who have full control over everything covered in the guide. In this article series, step by step instructions will not be provided, there won’t be any downloadable files, and questions that belong in the beginner’s guide will not be answered. The aim of these articles is to discuss ideas that can be implemented in many different ways, in many different projects- and that requires the ability to create things from scratch, not by following step by step guides. 

I’ve previously talked about how using single variables instead of arrays can speed up the population of Menu scene elements drastically.

That does however bring up another problem. Unlike arrays, variable’s aren’t ever empty. If they are empty, they contain their own name, and if you write a space to them to make them appear empty, well then they contain a space. That means that an entry with either the variable name or a space will show in your Menu element, and if you have static icons for each list item like I do, even the instance with the space will be visible- and it will be there in any case.

There’s a method to deal with this, and it’s luckily fairly straight forward. First off, you need to make sure a variable is never empty to where it contains its own name, but rather always contains a single space when “empty”. This just means you use Variable Set with a space instead of Variable Clear, and you can even use a single Variable Set action to set it to a space with an If condition for it matching its own name before you launch your scene, just in case.

When that’s done, you need to start launching your scenes like this:

Here’s what happens in the above screenshot:

• First it creates the scene without displaying it, allowing for manipulation of scene elements
• Then it uses Element Visibility to make sure the Menu element is visible, but only if the variable used in that element, %Gtodo, is at least two characters long
• Then it uses another Element Visibility to hide the Menu element if the variable doesn’t contain at least two characters
• Finally, it displays the scene

In other words, every time the scene launches, it checks to see if the variable used in the Menu element is more than a single character long. If it’s not, it’s likely because it contains only a single space, and then it just hides the entire Menu element. Problem solved! At least if your scene only displays the info, so that you launch it every time there data changes. Things are a bit more complicated if you’re…

Adding to the variable from within the scene

In that case this works, but it might require that you use Element Visibility actions elsewhere too, depending on your project. My todo list, for instance, has options to add to the lists in the scene, while the scene is active. But, if the list is empty, the entire Menu is invisible, which means that if I just add to the variable, it won’t show unless I also include the Element Visibility action to re-enable the Menu element after I add something to the variable.

I know this sounds complicated, but trust me, this method is much, much faster than the easy way out, which is to just live with the delay caused by global arrays. My todo list project has gone through multiple rewrites, and it currently uses this method for populating the list, and I can assure you that it’s much faster than using a global array. It’s more complicated, yes, but it’s all about adding a few more actions when you create the project so that it works better in the long run. I’ve used this for many months now, and it works perfectly.

On a related note, I should add that using a variable instead of an array does mean you need to compensate a bit when you’re actually editing the variable as well. For instance, you need to remember that Variable Split to convert a variable to an array only works if there’s at least two items in the variable. This is because you split the variable by a comma, and that comma is only there if there’s more than one item. A simple If condition to check if the variable actually contains a comma is an easy fix for this.

Another take on adding info to a variable is to simply skip arrays altogether. Using Variable Search Replace and Variable Set you can do a lot of what arrays are good at with variables directly, such as appending info and removing something out from the middle of them. Here’s a couple of examples from my todo list project:

The above screenshot shows a method for adding something to the end of a variable. What you don’t see from the above is that the second Variable Set has Append enabled, while the first one doesn’t. If %Gtodo doesn’t match ++, it means it’s a single character, likely a space, and it’s considered empty. In that case, it replaces the value of the variable with the data that is added, %itemtoadd, and gets rid of the space in the process. The alternative situation is if %Gtodo is longer than two characters, which means it’s not empty. In that case, it appends a comma followed by the new data, %itemtoadd, to the variable.

This means that if %Gtodo has a value “apples,bananas”, and %itemtoadd is “pears”, the resulting value of %Gtodo will be “apples,bananas,pears”. When fed as a single variable into a Menu element, it will list everything separated by a comma individually.

This screenshot on the other hand shows a way to actually edit an entry in the Menu element. This is part of a long tap task for my todo list scene, meaning that I can press and hold an item to edit it. The variable %tap_label is a built-in variable that contains the data from the Menu item you clicked, meaning that if the item you clicked was “bananas”, %tap_label will be “bananas”.

To make this work as an edit feature, it first pops up a Variable Query, where %tap_label is used to populate the text field with the info you’re editing. Once done, it performs a Variable Search Replace, replacing the old %tap_label with the info from the Variable Query.

The downside of this is that unlike doing this with an Array, you can’t stop it from replacing it anywhere it finds it. So if %tap_label is present several places, it will replace all of them. An example would be if the first item on the list is “apple”, and the second is “apple pie”. Editing the first item to “orange” would leave the list saying “orange” and “orange pie”.

These are just two examples of how to deal with the fallout from using a variable instead of a global array. The reason why I haven’t covered my last few versions of the todo list project in detail is quite simply that there’s a ton of things like this in there, in other words complex systems designed to work around issues in Tasker. It’s ironic, but even though it’s way more complicated, it’s also way, way faster.

The post Advanced Tasker: Dealing with empty variables in scene menus appeared first on Pocketables.

utter! is a voice control app that has been out for a while, though it’s still in beta. Its developer has been active in the Tasker world in the past, and this is also reflected in his app having integration with Tasker. I’ve never really used it on a permanent basis, but I’ve been installing it and uninstalling it regularly to see what’s going on.

The last time I did that, I decided to try out the tutorial feature, and it’s unique enough so that I want to share it with you. The tutorial is very interactive, opening up various parts of the UI while a computer generated voice explains what’s going on, before it helps you get the basics set up with regards to voice recognition. It’s a very visual form of tutorial, and I think it works very well, not at least because it utilizes humor in a very interesting way. In some ways, this tutorial actually reminded me a bit about the Portal video game series, for those familiar with it.

I decided to record the tutorial for those who can’t be bothered trying the free app for themselves. I should note that the difficulties it has understanding me in the video is likely due to the position of the phone relative to me while recording, as it didn’t have that issue when I did it originally. Failure to recognize synonyms for “yes” is another matter, but this is a beta after all.

I think this is a great way to teach people how to use an app, and I’d like to see more of this type of guides in other apps.

The post utter!’s tutorial feature is an example to be followed [Video] appeared first on Pocketables.