Link to IFTTT is very inconsistent

[sarit_arora]

Recently i did a quick project using photon and IFTTT. Basically, for every channel the RGB led shows a different color. After trying it again and again, it works fine for twitter initially and its very inconsistent for gmail and Facebook. Even on using “test recipe” it works sometime on the first try and then again may have to wait for 15 min before the notification comes through ( and sometimes it does not ). Is this a IFTTT issue or a photon issue? The promise of IFTTT is so good, but this inconsistency may make this very ineffective with photon. Any pointers to trouble shoot this will be greatly appreciated. Thanks!

[Moors7]

I suspect it’s an IFTTT thing, since that polls services in an interval. Depending on the interval, it can take some time for a difference to be noticed. @dave should know more about this.
If you could elaborate on what exactly it is that you’re trying to achieve, we might be able to offer (better) alternatives.

[Dave]

Hi @sarit_arora,

We use the IFTTT Realtime API, so depending on your recipe, instantly for events, or every minute for functions / variables, we check your recipe rules, and then ping IFTTT if something interesting happened. Unfortunately this doesn’t guarantee that IFTTT will check back with us right away, and it doesn’t guarantee that the action channel on the other side will respond right away. IFTTT does try to make sure things happen eventually, but these time windows can be large.

Thanks!
David

[sarit_arora]

Thanks @Moors7. Here is what i am trying to do…

void setup() {
    // register the Spark function
    Spark.function("notify", notify);
     
    // register pins
    pinMode(A3, OUTPUT);
    pinMode(A4, OUTPUT);
    pinMode(A5, OUTPUT);
     
    // switch light on
    analogWrite(A3, 0);
    analogWrite(A4, 0);
    analogWrite(A5, 0);
}

void loop() {
    // this loops forever
}
 
int notify(String command) {    
     
    if(command == "facebook") {
        analogWrite(A3, 150);
        analogWrite(A4, 0);
        analogWrite(A5, 0);
        delay(40000);
        analogWrite(A3, 0);
        analogWrite(A4, 0);
        analogWrite(A5, 0);
        return 1;
    }
     
    if(command == "instagram") {
        analogWrite(A3, 100);
        analogWrite(A4, 100);
        analogWrite(A5, 0);
        delay(40000);
        analogWrite(A3, 0);
        analogWrite(A4, 0);
        analogWrite(A5, 0);
        return 1;
    }
     
    if(command == "twitter") {
        analogWrite(A3, 0);
        analogWrite(A4, 150);
        analogWrite(A5, 0);
        delay(40000);
        analogWrite(A3, 0);
        analogWrite(A4, 0);
        analogWrite(A5, 0);
        return 1;
    }
    
    if(command == "gmail") {
        analogWrite(A3, 0);
        analogWrite(A4, 0);
        analogWrite(A5, 150);
        delay(40000);
        analogWrite(A3, 0);
        analogWrite(A4, 0);
        analogWrite(A5, 0);
        return 1;
    }
    
     if(command == "flickr") {
        analogWrite(A3, 100);
        analogWrite(A4, 0);
        analogWrite(A5, 100);
        delay(40000);
        analogWrite(A3, 0);
        analogWrite(A4, 0);
        analogWrite(A5, 0);
        return 1;
    }
    
     if(command == "yahoo") {
        analogWrite(A3, 100);
        analogWrite(A4, 100);
        analogWrite(A5, 100);
        delay(140000);
        analogWrite(A3, 0);
        analogWrite(A4, 0);
        analogWrite(A5, 0);
        return 1;
    }
     
    else return -1;
}

[sarit_arora]

Thanks @Dave !

Anything that can be done to reduce this time lag?

[Dave]

If you’re triggering the recipe from another channel (Facebook, etc), then we don’t have any control over how quickly that site will register the event or tell IFTTT that something interesting happened, or how quickly IFTTT responds. You could always try to setup a webhook that requests the same kind of information, which might be faster ( https://docs.particle.io/guide/tools-and-features/webhooks/ ).

Thanks!
David

[Moors7]

Right, there’s two things I notice at first glance.
First off, you’re doing way to much stuff inside your function handler. These functions interrupt code execution. When you do a lot of stuff in them, taking too much time, everything else gets blocked. They won’t be able to send a return to the function that called them until it’s fully completed, which can take either 40 or 140 seconds, depending on what was activated.
That brings me to the second point: delays.
The delays you’re using are way too long. When you issue a delay, all other code gets blocked. During that time, the microcontroller won’t to anything. For short delays that might be acceptable, but yours are 40 and 140 second. That’s a long time. If you receive another function call during that time, your code wont be able to respond since it’s too busy waiting.

To remedy the first, try doing as little as possible during your function call. Set a variable (flag), which gets checked for in the loop. That way the function can return immediately, and won’t block.
To remedy the second, try using soft delays, using millis(). That’ll allow you to create long delays, without blocking other code. It also allows for new functions to be called in the mean time.

[sarit_arora]

Thanks Moors… this is very helpful!