Beginner Tutorial: IFTTT - Monitor a Device Status Trigger

This tutorial will walk you through using IFTTT to set up a log of when your Internet goes out. It’s a great walkthrough if you’ve never used IFTTT (or even Spark) before. The only hardware you need: A Core or Photon. Also, you’ll want to have a Google account since we’ll be using Google Drive as our action channel (note that this is a really full tutorial that walks through each and every step. So it looks long. It’s not)

This will also go extra quick if you’ve already signed up for an IFTTT account. If you haven’t, just go here.

Here we go…

My husband and I used to live in an apartment that had some Internet issues. There were constantly (unnamed Internet provider) reps out at the building trying to fix stuff and often making it worse. Thus we would call them all the time to tell them that the signal had been dropping a lot recently.

Unnamed Internet company phone person: How often?
Me: I don’t know. A lot.

I wish I could have answered that question with some actual data that I had easily collected. “It tends to fail several times in the evening” or “It goes in and out all day, often 6 or 7 times.”

So let’s build a super easy project to help collect that exact data.

####1. Connect your device to the Internet and claim it to your account. (If you’ve already claimed your device skip to step 2)

If this is the first time you’ve opened your board let’s start out by getting your Core/Photon claimed. The best way to do so (provided you’re not in a conference setting) is via our app. Read through our start page and get your board claimed and connected to the Spark cloud!

Return to this tutorial once your board is “breathing” cyan and you have named and connected it to your account.

Your Core or Photon comes pre-loaded with firmware called “Tinker” that is already running a program on the board. For the Trigger we’re going to use in this example, you just need some sort of firmware on your board (it doesn’t matter what) so for now we’re just going to leave Tinker loaded on and dive right into IFTTT. If you’ve already been playing with your board that it totally fine – you just want to make sure some sort of firmware is actually flashed to it.

2. Log onto IFTTT and Create a Recipe

You’ll then be taken to the below screen:

3. Select Spark as your Trigger Channel (IFTTT step 1)

If you have not already activated the Spark channel you’ll need to do so now. Use the same email address you use for your Spark login account (but note that it needs to be all lowercase here for some reason).

4. Choose a Trigger (IFTTT step 2)

Select “Monitor your device status”

5. Complete Trigger Fields (step 3 in IFTTT)

If (device name or ID)
• Select the name of your board. For me that’s jackfrost.

Is (Status of your device)
• Decide if you want to know when your board is online or offline. I’ll choose offline for this example

6. Choose Action Channel (step 4 IFTTT)

I’d like to keep a log of how often my internet goes throughout the day so I’m going to set up a spreadsheet to track this. I’m going to select the Google Drive channel (which will let me set up a google sheet). If you have not activated this channel, go ahead and do so now. You’ll need to approve allowing IFTTT to connect to your account.

7. Choose an Action (step 5 IFTTT)

Select “Add row to spreadsheet”

8. Complete Action Fields (step 6 IFTTT)

Now we set up what our spreadsheet is actually going to be called and the exact data it’s going to collect.

Spreadsheet name

  • I’ll personalize that spreadsheet name to “Tracking Internet at home”

Formatted Row

  • This is populated with Ingredients that have been automatically populated. I like what the outcome will be so I’ll keep it as is. It will result in entries that look like this: Jackfrost / offline / January 13, 2015 10:12am

Drive folder path

  • I’m going to change this folder path to “IFTTT” so it’s easy for me to find in the future.

Ready? Hit Create Action

9. Create and Activate (step 7 IFTTT)

This is where you can write a nice description of your recipe (or else just leave what is automatically populated)

10. Now it’s time to collect data (and look up the phone number for your internet provider!)

(Heads-up that it sometimes takes several minutes for this integration to connect. We recommend waiting a few moments and then disconnecting power to your Core or Photon. You should now be able to find a log of your data in an IFTTT folder of your google drive.

Here’s what your data should end up looking like:

Next Steps: If you want to keep going, a great next step is to measure when that same Core/Photon comes online. This way you can get not only how many times your signal dropped but also measure how long it was out. To do this, just follow the exact same steps as above, except at Step 5 select “online” as your status. You can even have the data pump into the same google sheet as your offline data by making sure the paths match in Step 8.

Hope you’ve enjoyed this!!


This is a great and very useful tutorial / IFTTT recipe! I love how it only requires any type of code running on my Spark so I don’t need to change any of my existing code. It’s working well here. Thanks for sharing!!


This recipe works except my device name is blank even though it is a choice in the drop-down menus. I’ve tried sending an email as well as an IOS Push Notification and both just show blank for the name when I receive them. The status and createdAt fields are displayed if I add those however. Any ideas on why DeviceName is blank? Thanks!

1 Like

Hmm, that seems weird, @robot_banjo, can you private message me your device id (not sensitive info), and I’ll check and see what’s up?



Hi @Dave I’m having the same issue as @robot_banjo and just sent you a PM with my device ID. The difference might be that my DeviceName was showing up at first on both IFTTT alerts and in the google drive file, and then days later it stopped working and has not worked since. I’ve included the dates my program was working OK and when things went south. Thanks for your help!

1 Like

Just wanted to continue the conversation here after replying to PMs – I discovered a bug related to the name not showing up in triggered recipes, and fixed it, sorry about that! The fix will be included in our next rollout, which should be early next week.


1 Like

Using IFTTT to monitor for internet or power loss is a great feature and requires no actual Spark programming. The one problem that I have is that even if the Internet goes down for a minute or two, I get a message. It would be great if the IFTTT trigger had an optional delay so there would need to be a loss for several minutes in order to trigger.


1 Like

Hey @detroit_johnny / @robot_banjo,

I just wanted to ping you and let you know I deployed the fix for the IFTTT device name issue, sorry it took me a while! :slight_smile:


1 Like

Hi @tcrussell,

Good idea! So maybe an optional setting, or a different trigger? (If my device is offline for more than xx minutes)?


Thanks for the device name fix David! I’m seeing the name show up now.

Thanks @Dave! The device name fix started working for me as of Feb 18.

@tcrussell I also like your idea for some kind of filter or option that could be set to help minimize the times the internet is only down for a short time. I didn’t realize how often it happens until I started using this script.

What’s weird is many times I’ll get the IFTTT “online” alert for my Spark, but sometimes it’s not preceded with an offline alert. I don’t understand it but I’m assuming my internet connection or the Spark cloud is glitching.

Hi @detroit_johnny,

If your device disconnects uncleanly, the cloud might not have noticed your core is disconnected yet. When your device reconnects, it ends the lingering session, and so you can get “online” events before “offline” events. I’ll admit it can be a little confusing, but hopefully knowing what’s happening behind the scenes makes sense. :slight_smile:


Yes. Add a field for offline / online for x minutes.


Hi there. I’ve been playing around with the Spark IFTTT channel, and I absolutely love it! However, I have found a bug with the Spark.variable() function. I’m not sure if it’s on your side or IFTTT’s side, but when I create two recipes monitoring the same variable (temperature in this case), both recipes are triggered, even if the variable isn’t meeting the condition of the second trigger.

For example, I have one recipe set up to text me if the temperature is above 80 degrees F, and the second recipe texts me when that same temperature variable is lower than 65 F. When The temperature rises above 80 F, I get a text from both recipes, even though it sends the current variable value, which is indeed above 80. Same happens if it goes below the threshold: two texts, one from each recipe, printing the correct variable value.

I have tried different comparison operators (greater than VS greater than or equal to), and I have tried on two different Spark Cores, both yielding the same results. I’ve also tried on two completely different wireless networks.

Just curious if anyone else has experienced this same issue monitoring one variable with tow recipes?

I’m using the OneWire Library, if that makes any difference.

@Dave - I see a significant imbalance between the online and offline events. For a core that has just been left alone and is running a simple test to toggle D7, I have received 148 online events and 8 offline events since Jan 21.

I do not think I’ve had 148 internet or power outages since Jan 21, but there might well be 148 different TCP sessions initiated from the core to the cloud, for reason.

I will attempt to capture the tcp traffic and see if the initiation of a new session correlates with the online events to ifttt.

Unless you have a better idea of what is going on…


Hi @AndyW,

Good question! Right now the cloud sends an online event for each new tcp session the device initiates. I think there is an issue with how offline events are sent that is preventing them from going out as expected, and is something on my list of stuff to fix this next sprint.

Do you think we should change the behavior around these events? Should we not publish a new online event at every session start, or offline at each disconnect?


Well, at present, new TCP connections bear little relation to real online events.

Not really sure what you would key off of to filter out these wannabe events, but it is good to know there is at least an explanation for what I’m seeing.


Having the same issue; frequently getting Online events and rarely getting Offline events. I thought perhaps it was an issue with my core but I hooked up a second that does nothing and it has the same issue though much less frequent. Both are sitting next to each other so it shouldn’t be an issue of wifi signal.