How To: Control smart home X minutes before Android Alarm Clock

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 variable BeforeAlarm.
    Note: Per feedback from @RJ_Marcus, you’ll need to wrap the variable set command in a round() 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

1 Like

Isn’t the variable %secondsc rather than %seconds (based on the screen shot)? A strange variable to use but maybe Tasker already uses %seconds.

If I remember correctly, %seconds is the total number of seconds until the next alarm whereas %secondsc is just the seconds portion of the time from the full time stamp. (Eg. It was 4 minutes and 41 seconds away so %secondsc = 41 whereas %seconds = 281)

We wanted to add the total number of seconds until the next alarm to the current time stamp (in seconds) so we could calculate when to trigger things, so we used %seconds.

Thanks, friend. This was a useful guide.

I have one token to add:

My profile would not trigger correctly because the variables for time had come out in scientific (E) notation (and also contained fractions of a second). The time profile trigger could not handle this as a unix timestamp and would not trigger.

You may need to surround your time math with the round() function:

round(%TIMES+%seconds-(%mins_before*60))

Cheers

1 Like

Now that google supports routines from Android Clock, could you just do this with a silent alarm to trigger a routine to turn on a switch?

Hate to revive a old thread…
First time poster…

Been trying to get this to work and cannot…

Any ideas?
Post screen shots of logs?

Running stock android 9 on pixel xl
Looked over setting in Tasker many times
Can “run” the light turning on in task tasker and it works
So it does communicate with smartthings
Never turns on light 5 min before next alarm though

Any input would be great
Thanks

1 Like

Thanks for posting, @Nate_Rodrigues!

First, I’d suggest triple checking the details of the profiles. It’s really important that all of the details are exactly right and the variables (including the capitalization) are exactly right.

If that doesn’t help, I’d suggest posting a description export of the Tasker profiles so we can help you review.


Edit: I’d also suggest making sure the relevant (de)optimizations have been made for Tasker:

https://tasker.joaoapps.com/userguide/en/androidpowermanagement.html

And for SharpTools:

https://help.sharptools.io/portal/kb/articles/how-do-i-optimize-sharptools-for-android-5-0-and-newer

Profile: Test (8)
	Time:  Every 30m
Enter: Anon (9)
	A1: AutoAlarm [ Configuration:NOTE: This will not work correctly if the 'Relible Alarms' option is enabled in Tasker. No extra configuration needed Timeout (Seconds):5 ] 
	A2: Variable Set [ Name:%mins_before To:5 Recurse Variables:Off Do Maths:Off Append:Off ] 
	A3: Variable Set [ Name:%BeforeAlarm To:%TIMES+%seconds-(%mins_before*60) Recurse Variables:Off Do Maths:On Append:Off ]
Profile: Test2 (10)
	Time: From %BeforeAlarm Till %BeforeAlarm
Enter: Anon (11)
	A1: A Thing [ Configuration:Thing: Living Room Lights
Command: on Timeout (Seconds):0 ]

De optimizations are good

Want to thank you for quick reply

At quick glance, it looks like everything is setup as expected. A couple of things you might check:

  1. Make sure the Tasker profile are active. Usually this is done by simply backing out of Tasker completely or by tapping the :heavy_check_mark: in the action bar after editing a profile.
  2. Make sure that Reliable Alarms is disabled (in Tasker Preferences → Monitor)
  3. Check that AutoAlarm can read your alarms:
    1. Open the AutoAlarm App
    2. Tap the Test option and verify that it’s showing the correct next alarm.
  4. Check if the variables are being set by the first profile (which runs AutoAlarm)
    1. In Tasker, open the VARS tab
    2. If you don’t see the variables set (or they don’t look right), the profile that runs every 30 minutes might not be working as expected. At least for troubleshooting, you could try manually running the Task with AutoAlarm in it.
  5. Add some debug Alert → Notify actions to your tasks so you’ll get a notification when they are running and you can be sure the action is happening as expected.

I just tried walking through the steps part by part and I see what @RJ_Marcus was referring to. It looks like the resulting %BeforeAlarm variable was being stored in scientific notation which didn’t work with the time profile.

If you take his suggestion and wrap the variable formula in round() it keeps the time as a normal integer timestamp which works with the profile:

round(%TIMES+%seconds-(%mins_before*60))

I’ll update the text in the original post above accordingly. :smiley: