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

mohnish82 · September 20, 2015, 6:29am

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 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.

FlyingMule · September 26, 2015, 8:42pm

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?

Moors7 · September 26, 2015, 9:42pm

@dave, could you weigh in on this?

mohnish82 · October 4, 2015, 8:04am

This is not happening anymore since firmware updated to 0.4.6.

Marking as resolved.

Dave · October 5, 2015, 8:39pm

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!

Thanks,
David

Matthew1 · November 12, 2015, 2:42am

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.

Dave · November 12, 2015, 3:26am

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.

Thanks!
David

Matthew1 · November 13, 2015, 3:14am

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!

cozy2963 · November 28, 2015, 12:33am

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.

Moors7 · November 28, 2015, 7:24am

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.

cozy2963 · November 28, 2015, 4:29pm

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);
  }
}

Moors7 · November 28, 2015, 8:16pm

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.

cozy2963 · November 28, 2015, 9:16pm

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!

Thanks for all of your help!

mohnish82 · November 29, 2015, 4:46am

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:

Firmware bump - Photon firmware has been updated twice since.
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.

mohnish82 · November 29, 2015, 5:02am

@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.

andrew76092 · March 6, 2016, 6:11pm

@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());
    Serial.begin(9600);

}

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"){ 
    relayPulse(command);
    return 1;
    }
    return 0;
};

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

mohnish82 · March 7, 2016, 11:34am

@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.

andrew76092 · March 8, 2016, 3:26pm

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

Thanks for the suggestion!

Update
see IFTTT - recipe for status of garage door status

mallawa · April 11, 2016, 10:09pm

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.

ScruffR · April 12, 2016, 6:59am

Can you show the code?

Topic		Replies	Views
Double Triggering with IFTTT Integrations	7	3017	September 2, 2016
Missing IFTTT Events Integrations	1	1812	November 30, 2015
Publish on event change Raspberry Pi	1	1085	February 21, 2018
Random actions, untriggered by IFTTT Troubleshooting	2	776	August 28, 2018
Spark and IFTTT Issues Troubleshooting	4	1516	January 28, 2015

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

Related topics