[Solved] IFTTT event triggered twice, expected once for once published event

I am using my Photon to control my garage door. Further, I am using IFTTT recipe to trigger door open/close. When the door changes state (open -> close, close -> open), I publish a single Spark event, logging new state. I verified in dashboard, that only 1 event is published. Further, I have a IFTTT recipe to monitor these specific events and notify on my mobile.

Now the problem is, when the door is closed, I receive 1 IFTTT notification (expected correct behavior). But when it opens, I receive 2 notifications! In the dashboard, I see that only 1 event is published, be it open or close command. So, why does open state generate 2 notifications, instead of 1? Any ideas?

Here’s my code:

int remote = D3;
int garageCloseDetectPin = D4;

int commandProcessingUnderway = 0;

String command = "";
String garageState = "";
String previousGarageState = "";

unsigned long currentTime = 0;

void setup() {
    pinMode(remote, OUTPUT);
    pinMode(garageCloseDetectPin, INPUT);
    digitalWrite(remote, HIGH); // reverse relay connections

    Spark.function("Garage", garage);

void loop() {

    currentTime = millis();

    garageState = digitalRead(garageCloseDetectPin) == HIGH ? "closed" : "open";

    if(commandProcessingUnderway == 0 && ((command.equalsIgnoreCase("open") && garageState.equals("closed")) || (command.equalsIgnoreCase("close") && garageState.equals("open")))) {
            digitalWrite(remote, LOW);
            commandProcessingUnderway = 1;
            Spark.publish("Garage", garageState.equals("closed") ? "Garage opened" : "Garage closed", 60, PRIVATE);
    }else if(commandProcessingUnderway == 1 && (previousGarageState.length() > 0 && !previousGarageState.equals(garageState))) {
            digitalWrite(remote, HIGH);
            commandProcessingUnderway = 0;
    command = "";
    previousGarageState = garageState;

int garage(String cmd) {

    if(cmd.length() < 1)
        return garageState.equals("closed") ? 1 : -1;

    // Ignore incoming request, if already processing other request
    if(commandProcessingUnderway == 1 || command.length() > 0)
        return -100;

    // otherwise, record for processing
    else if(cmd.equalsIgnoreCase("open") || cmd.equalsIgnoreCase("close")) {
        command = cmd;
        return 0;

And here are the event publish logs:

event: Garage
data: {"data":"Garage closed","ttl":"60","published_at":"2015-09-20T06:19:33.587Z","coreid":""}

event: ifttt-trigger-event-check
data: {"data":"{\"count\":34}","ttl":"60","published_at":"2015-09-20T06:19:34.355Z","coreid":""}

event: Garage
data: {"data":"Garage opened","ttl":"60","published_at":"2015-09-20T06:20:57.273Z","coreid":""}

event: ifttt-trigger-event-check
data: {"data":"{\"count\":36}","ttl":"60","published_at":"2015-09-20T06:20:58.537Z","coreid":""}

event: Garage
data: {"data":"Garage closed","ttl":"60","published_at":"2015-09-20T06:21:13.185Z","coreid":""}

event: ifttt-trigger-event-check
data: {"data":"{\"count\":37}","ttl":"60","published_at":"2015-09-20T06:21:14.286Z","coreid":""}

Notice how the numbering scheme (count) is not consistent for IFTTT events! While during OPEN count increased by 2 (34 to 36), during CLOSE it incremented by 1 only (36 - 37). Anybody else noticed this behavior with Particle IFTTT recipes?

[Update] I changed the IFTTT recipe to send me SMS instead of notification, and while the numbering scheme (count) is still messed up ( jumps 2, then jumps 1), I received only 1 SMS for each close and open events! So, when it costs money (sending SMS) things are coded correctly, otherwise not so much :smile: Seems more like IFTTT issue to me now.

[Update 2] SMS has the same problem. Published earlier update too soon! 2 SMS received for open and 1 for close.

HI mohnish82,

I’ve been playing around with publishing events and IFTTT for a while now without issue but I just ran into the same problem you’re seeing. After a little trial-and-error, I think I’ve figured out when the problem shows up and how we can work around it.

Basically, there seems to be an issue with triggering a recipe for a given Particle event with specific data (“Event Contents” in IFTTT). Things seem to be just fine if you create a recipe that triggers based solely on Event Name, but as soon as you try and narrow it down to trigger for specific Event Contents, it will get triggered twice any time there is a match.

In your case, you are publishing a single event “Garage” along with data “Garage opened” or “Garage closed”. I’m guessing you have one recipe that looks for Event Name “Garage” with Event Contents “Garage open” and then another for “Garage” with “Garage closed”. Am I right?

I think that if you simply change your code to publish two unique events e.g. “GarageOpen” and “GarageClosed”, your IFTTT recipes can ignore Event Contents and this will avoid the double-triggering curse. It certainly did the trick for me anyway!

There appears to be a bug in the way the Particle channel is matching Event Contents. I’m not sure who to report it to though. Is the Particle IFTTT channel implemented by the Particle folks on behalf of IFTTT or by the IFTTT folks on behalf of Particle. Anyone know?

1 Like

@dave, could you weigh in on this?

This is not happening anymore since firmware updated to 0.4.6.

Marking as resolved.

1 Like

When IFTTT checks on a recipe, we hold onto the request they made for a while, and we start checking for that case proactively. IFTTT doesn’t tell us when you create or destroy a recipe, so if you change a trigger a few times in a row, many “ghost images” of the recipe can linger. I suspect that might be what you hit? These eventually time out since IFTTT stops sending requests for older triggers, etc. But I could be totally wrong! :slight_smile:


Yes, I have something similar. I think it must be some sort of “ghost” effect and I’m hoping will just sort itself out on its own after a while.

Hmm, is this something you’re still seeing? We restarted a service related to this earlier tonight, so I’m curious to see if there were side effects as a result.


Hi @Dave, so I just turned mine on again, and the first try didn’t register in either my IFTTT prompted Google Spreadsheet file (~6:58pm), nor my IFTTT promted SMS messaging. However, second try, at 7:05pm did work on both in my Google Spreadsheet and via text message. Also, the double entries have stopped!! Yay! You can see in this image, that all the triggers from yesterday had two notifications for each time my box was opened and one for each time it was closed. Whereas today, it is now 1 and 1! :slight_smile:

1 Like

I too am having the same issue. I am very new to micro controllers, so this is kinda shaking my confidence. I am trying to make a simple system that will send me a notification on my iPhone when a simple button is pressed. I have tried many different ways of publishing, but still get 4 notifications sent for every one time the button is pressed. Hoping that someone can help me!!! I just ordered another Photon tonight to make the same thing for a friend… yet, mine isn’t working right! Any help would be appreciated.

4 notifications sounds like you’re going over the publish limit and are rate limited after the fourth. That said, could you share the code you’re using, perhaps we can offer some advice.
Alternatively, check the Particle dashboard to make sure you’re only sending out a single SSE after a button press.

1 Like

Thanks for the help! The code it’s self is pre-written, the only part that I added was the “Spark.publish”.

Here it is:

const int buttonPin = D0;     // the number of the pushbutton pin
const int ledPin =  A4;      // the number of the LED pin

// variables will change:
int buttonState = 0;         // variable for reading the pushbutton status

void setup() {
  // initialize the LED pin as an output:
  pinMode(ledPin, OUTPUT);
  // initialize the pushbutton pin as an input:
  pinMode(buttonPin, INPUT);

void loop() {
  // read the state of the pushbutton value:
  buttonState = digitalRead(buttonPin);

  // check if the pushbutton is pressed.
  // if it is, the buttonState is HIGH:
  if (buttonState == HIGH) {
    // turn LED on:
    digitalWrite(ledPin, HIGH);
    Spark.publish("Izzy", PRIVATE);
  } else {
    // turn LED off:
    digitalWrite(ledPin, LOW);

Yup, that’s what I suspected. You’re blowing over the rate limit as soon as you press the button since the loop runs extremely fast. Once you go over the 1p/s, with 4p/s bursts allowed, you’ll get turned off until you’re back under the 1p/s. Since you immediately go over 4, you get cut off, but those four publishes still trigger IFTTT, hence the four notifications.
As a quick fix, try placing a delay(1000) after your publish, that’ll keep you under the rate limit. It’s not the most elegant solution, and definitely not something you’d want to use on the long term, but for starting out, it works nicely.

1 Like

That worked! Why would that not be a “long term solution”? What would be a better longterm solution? I’m planning on leaving this up for an extended period of time! This is my first project and I’m just learning all of this! :grin:

Thanks for all of your help!

Hi all,

I can now confirm, after observing the device logs extensively, that notifications work properly through the IFTTT channel. I tried with various things, command line triggers, IFTTT triggers, DO button triggers etc. Correct notifications got triggered in all scenarios.

I’m not sure what fixed this, but a few things happened since I reported this originally:

  1. Firmware bump - Photon firmware has been updated twice since.
  2. Service restarts - As @Dave mentioned above.

Here’s a snapshot of recent log:

event: ifttt-trigger-event-check
data: {“data”:"{“count”:6}",“ttl”:“60”,“published_at”:“2015-11-29T04:26:54.016Z”,“coreid”:"_"}

event: Garage
data: {“data”:“Garage opened”,“ttl”:“60”,“published_at”:“2015-11-29T04:27:25.803Z”,“coreid”:"_"}

event: ifttt-trigger-event-check
data: {“data”:"{“count”:7}",“ttl”:“60”,“published_at”:“2015-11-29T04:27:26.287Z”,“coreid”:"_"}

event: Garage
data: {“data”:“Garage closed”,“ttl”:“60”,“published_at”:“2015-11-29T04:27:49.889Z”,“coreid”:"_"}

event: ifttt-trigger-event-check
data: {“data”:"{“count”:8}",“ttl”:“60”,“published_at”:“2015-11-29T04:27:51.980Z”,“coreid”:"_"}

event: ifttt-trigger-event-check
data: {“data”:"{“count”:8}",“ttl”:“60”,“published_at”:“2015-11-29T04:30:10.608Z”,“coreid”:"_"}

Notice how the ifttt-trigger-event-check variable (correctly) increments by 1 after an event. This was a problem earlier, that seems to be fixed now.

Thank you all for your time and feedback.

@cozy2963 As we’re not sure how fast the loop would run, it is a bad approach to rely on it. So, a long long term fix would be to have a variable to track the status. As an example, you can refer to the code I posted in my 1st post. There, I use the variable commandProcessingUnderway, for similar purpose.

Using delay is not recommended because it artificially blocks the Photon from doing stuff. Around the exposed loop function, firmware code runs to take care of other processes e.g. maintaining cloud connection for the Photon etc. We should give that code a chance to run too, as frequently as possible. Concept similar to - fast running non-blocking processes giving impression of real time concurrency.

1 Like

@mohnish82 I read some of your posts and it appears your garage door has a similar arrangement as mine, I’d like to emulate your code if so. I’m using a 5v relay with my Photon (Core) and can open/close the door with DO Button recipe. What I’m missing however, is (1) the ability to monitor the door position (open or closed) and (2) recipe functionality for DO Button or IFTTT to open/close based on my iOS proximity (ie…opens automatically when I arrive home).

I’m brand new to coding and to Particle so any assistance is greatly appreciated! Thanks in advance.

Here’s my current code (it was borrowed from another Particle project so it’s probably not as clean as it needs to be):

int interval = 1000;
int state = 1;
int oldState;
int ts = Time.now();

int IN1 = D1; // variable for IN1 on relay
int IN2 = D2; // variable for IN2 on relay
int reed = D5; // variable for reed switch
int led = D7;
int doorstatus = digitalRead(reed); //variable for door status

String statusCheck(){
    int status = digitalRead(reed);
    return digitalRead(reed) ? "CLOSED" : "OPEN";

void setup() {
    // Time.zone(-5);
    Spark.function("relay", relayPulse); 
    Spark.function("open", openDoor);

    pinMode(reed, INPUT_PULLDOWN);
    pinMode(led, OUTPUT);
    pinMode(IN1, OUTPUT);
    pinMode(IN2, OUTPUT);
    digitalWrite(IN1, LOW);
    digitalWrite(IN2, LOW);
    Spark.variable("state", state);
    Spark.variable("ts", ts);
    // startup status
    Spark.publish("door_status", statusCheck());


void loop() {

	oldState = digitalRead(reed); //Check the current state
	if (doorstatus != oldState){ //Compare current state to status.
		doorstatus = oldState; //Make oldState the new status
		Spark.publish("door_status", statusCheck());
		state = doorstatus;
		ts = Time.now();
   delay(interval); //Delay Interval millisecond, as to not to overload the server.

// for loacation based IFTTT
int openDoor(String command){
    if (statusCheck() == "CLOSED"){ 
    return 1;
    return 0;

int relayPulse(String command){
    Spark.publish("button pushed by ", command);
    digitalWrite(IN1, HIGH);
    digitalWrite(IN1, LOW);
    return 1;

@andrew76092 My suggestion would be to open a new thread, as this thread was created for IFTTT event trigger problem. Over there, in the new thread, I along with others can help you. Future visitors looking for similar solution, would benefit from such a thread.

Thank you.

mohnish82 you are right, that makes complete sense. I’ll compile my question and open a new thread as suggested.

Thanks for the suggestion!

see IFTTT - recipe for status of garage door status

First I used spark core and my project published once when I toggle one of the GPIO. Actually I have a motion detector connected to it. I used IFTT. Anyhow I ported the same codes to photon and I can see it publish twice now. I used nice debounce algorithm in my code and this shouldn’t be hw issue. BTW everything worked fine when I had hooked it up to spark core.

Can you show the code?