AndroidApps

Beginner’s guide to Tasker, part 6: AutoRemote

autoremote main - for some reason we don't have an alt tag here
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.

tasker banner - for some reason we don't have an alt tag 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 - for some reason we don't have an alt tag hereAutoRemote 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.

Use Regex: Allows you to ruse regular expressions in the message filter

Tasker Vars

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

autoremote windows - for some reason we don't have an alt tag here

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

chrome plugin - for some reason we don't have an alt tag here

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.

eventghost config - for some reason we don't have an alt tag here

ar to eg config - for some reason we don't have an alt tag hereNow 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.

You can follow any Tasker coverage by using this link or this RSS feed.

autoremote qr - for some reason we don't have an alt tag here

Download: Google Play

Pocketables does not accept targeted advertising, phony guest posts, paid reviews, etc. Help us keep this way with support on Patreon!
Become a patron at Patreon!

Andreas Ødegård

Andreas Ødegård is more interested in aftermarket (and user created) software and hardware than chasing the latest gadgets. His day job as a teacher keeps him interested in education tech and takes up most of his time.

Avatar of Andreas Ødegård