An important note about chaining together commands in AutoVoice
The ability to chain together commands in AutoVoice is one of the advantages it has over the stock Get Voice action, but there’s also a problem with this system that is caused by Tasker itself, can be hard to understand, and can cause a lot of issues. Luckily, it’s also easy to fix!
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.
