IFTTT = Google assistant to Particle integration. Ghost events

Cloud Integrations
1

I’ve been using IFTTT to turn on and off my room’s lighting by google assistant voice command.

After changing the hardware from Raspberry pi to Particle Photon, the delay between the voice command and actual relay turn on/off is less than a second.

So, it’s working really fine.

However, around a certain time, the relay turns on/off by itself without a voice command.

The overall system design is below.

Voice command --> Google server --> IFTTT server --> Particle server --> Photon

After looking into three servers for logs, I found that both Google server and IFTTT have no logs of executing commands, but somehow the Particle console says it’s getting event from somewhere.

Since I only have one device in my account, without any “publish” commands, I don’t know where this event is coming from.

One more note. These ghost events are thrown two or three times a day, with exact timing.

At first, I thought this was the reset issue, ( for Arduino if you use timing function, the clock goes back to 0 after around 30 days) but the time interval btw the ghost events is too short. (12hours?)

Also, I disabled the auto-update to eliminate the possibility of the device reboot.

Any advice will be really appreciated.


const int Light_main = D0; 
const int Light_kitchen = D1;

bool Light_main_state;
bool Light_kitchen_state;

void setup() {
    System.disableUpdates();
    
    pinMode(Light_main,OUTPUT);
    pinMode(Light_kitchen,OUTPUT);
    
    pinSetFast(Light_main);
    pinSetFast(Light_kitchen);
    
    Light_main_state = false;
    Light_kitchen_state = false;
    
    Particle.subscribe("MainLights", mainLightsHandler);
    Particle.subscribe("KitchenLights", kitchenLightsHandler);
    Particle.subscribe("Lights", lightsHandler);
    
    Particle.variable("Light_main_state", Light_main_state);
    Particle.variable("Light_kitchen_state", Light_kitchen_state);
    
}

void loop() {
}

// IFTTT event handler
void mainLightsHandler(const char *event, const char *data){
    String temp = data; 
    if (temp == "off") { 
        pinSetFast(Light_main);
        Light_main_state = false;
        Particle.publish("Main Lights OFF");
    }
    if (temp == "on") {
        pinResetFast(Light_main);
        Light_main_state = true;
        Particle.publish("Main Lights ON");
    }
}
void kitchenLightsHandler(const char *event, const char *data){
    String temp = data;
    if (temp == "off") { 
        pinSetFast(Light_kitchen);
        Light_kitchen_state = false;
        Particle.publish("Kitchen Lights OFF");
    }
    if (temp == "on") {
        pinResetFast(Light_kitchen);
        Light_kitchen_state = true;
        Particle.publish("Kitchen Lights ON");
    }
}
void lightsHandler(const char *event, const char *data){
    String temp = data;
    if (temp == "off") {
        pinSetFast(Light_main);
        pinSetFast(Light_kitchen);
        Light_main_state = false;
        Light_kitchen_state = false;
        Particle.publish("Main & Kitchen Lights OFF");
    }
    if (temp == "on") {
        pinResetFast(Light_main);
        pinResetFast(Light_kitchen);
        Light_main_state = true;
        Light_kitchen_state = true;
        Particle.publish("Main & Kitchen Lights ON");
    }
}
2

You are registering your event subscribers as PUBLIC (default) so anybody who sends out a MainLights (or any of your other) event will also hit your subscription.

You should use MY_DEVICES for the subscription and PRIVATE for Particle.publish().

However, there might currently be a bug (under investigation) where even PRIVATE events go public and/or PUBLIC events may hit MY_DEVICES subscriptions.

You may have noticed your main lights flicker just a few minutes ago - that was me, sending public events

That’s why you don’t want to use the defaults PUBLIC/ALL_DEVICES :wink:
Especially not with common terms like Lights or MainLights that may well be used by others as well.

You can check whether there are other events that also use your event names like this

particle subscribe --all Lights
2 Likes
3

In addition to what @ScruffR mentioned, you also don’t want to the running much inside subscription handlers, especially not publishes.

Treat them like interrupts, and keep them as short as possible. Set a flag/state, and deal with that accordingly in the loop.

4

Wow, I never imagine that events are monitored altogether not seperated by users. (Now I understand why the doc said public event are “Twitter”)

However, I think this is not a perfect solution for me, because if I setup the event evoked by IFTTT as private, my particle device can not listen to that event.

I guess I have to come up with an unique event string to communicate IFTTT and my photon.

Thank you a lot!

5

Thanks for the advice!

The publish script I inserted was only for the monitoring purpose.
At first, I thought the weird behavior was generated by my relay module or the photon, so I wanted to monitor whether light state change was due to event or just hardware malfunction.

Thank you!

6

I don't think so.
Although I don't use IFTTT I'm pretty certain that you need to (or at least can) have a Particle account linked to your IFTTT in order to use the Particle recipe and hence you should be able to send PRIVATE events to that (your) account.

But why not just try, instead of assuming?

7

You’re right, I remember I have to login into my Particle account to link IFTTT service.

I already tried using “PRIVATE” events before I start the thread, but didn’t get the proper result.
(IFTTT evoked private event was shown in the particle console, but the device didn’t catch the event)

After your last comments, I tried again and it works like a charm!

I figured out the unsuccessful result was due to the failure of the flash command.

I’d better always check the flash successful message from the event log.

You really saved my day. Thank you a lot!!

1 Like