This post draws inspiration from a user on the SmartThings community who wanted to know how they could trigger an action in their smart home 10 minutes before the next alarm clock on their Android phone.
They had found a Reddit post where a user had described the basic concepts of how to setup the Tasker profile, but couldn’t quite get it working.
The video below shows the step-by-step instructions needed to set this up. Further below are the written instructions which may be helpful as a reference.
Tasker can definitely be a bit overwhelming to learn at first!
A summary of the profile as noted on Reddit has been copied below for easier reference:
To consistently perform a Task, a certain number of minutes before the next scheduled device alarm is to go off, use two Profiles:
PROFILE 1 Time > Repeat Every 30 minutes LINK TO TASK: A1. Plugin > AutoAlarm <SET THIS TO HOW MANY MINS BEFORE> A2. Variable Set: %mins_before To: 5 A3. Variable Set: %BeforeAlarm To: round(%TIMES+%seconds-(%mins_before*60)) Do Maths: On
Then the Profile to Trigger your desired Task at the time before the Alarm is going to go off:
PROFILE 2 Time > From: %BeforeAlarm To: %BeforeAlarm LINK TO TASK: <your main task>
So, Tasker has the concept of Profiles, Tasks, and Actions:
- Actions = the individual actions you are going to take (setting variables, calling plugins, etc)
- Tasks = a collection of actions (can be called from Profiles or within other Tasks)
- Profiles = a set of conditions (contexts) which trigger a Task
The way time events and AutoAlarm work is a bit different than a normal Tasker profiles/tasks. You have to run one task periodically to trigger AutoAlarm and setup the variables for timing, then another task which is triggered based on the variable you set in the first task.
So the first profile is a time triggered profile which repeats every 30 minutes and then runs the AutoAlarm/variable task. The first step in that task is to get the timing of the next alarm as a local variable - a local variable can only be seen/used within the life of the task; when the task ends, the variable disappears. Then the next steps in that task is to copy that local variable into a global variable which persists indefinitely and is identified as global by having a capital letter in the variable name.
So from the profile above:
- Action A1 is running AutoAlarm to get the time of the next alarm (it sets the time of the next alarm in a local variable)
- Action A2 is just setting a local variable which is defining the offset - how many minutes before the alarm do you want to trigger your target task.
- Action A3 is calculating the trigger time by finding the time of your next alarm and then subtracting your offset (
mins_before
) from the alarm time and ultimately storing this in the global variableBeforeAlarm
.
Note: Per feedback from @RJ_Marcus, you’ll need to wrap the variable set command in around()
to keep the number in the proper format (see his post).
The BeforeAlarm
variable is then used in your second Profile which is also a time based profile, but one that uses your BeforeAlarm
time to determine exactly when it can be triggered. Once the profile is triggered, it triggers your main Task.
Prior to this users request, I hadn’t used AutoAlarm before, so I bought a copy and downloaded it. From what I can tell, it has a bunch of different local variables it sets when it’s triggered. At around 2:00 PM, I set an alarm for 2:05 PM and ran the test which shows that the following variables get set:
Of interest is the %seconds
variable, since that’s what your profile uses. The %seconds
variable is how many seconds into the future your next alarm is going to trigger. So in my case it was set to 281.34 seconds (or roughly 4.7 minutes away).
What the A3 profile is doing above is taking the current time in seconds as reported by Tasker in the %TIMES
and adding the %seconds
variable to it. So it’s basically calculating the unix time (in seconds) at which point your alarm is going to trigger. And then in the second part of the math, it’s converting your offset in minutes to seconds and then subtracting it from your calculated alarm time – eg. it’s calculating the unix time (in seconds) at which point you want your event to trigger.
One thing I would note here is getting the variables exactly right is important. As you can see from the screenshot above, %second
is very different than %seconds