For the past month or so I’ve been trying to track down why my Particle.publish() events would sometimes trigger and run an ifttt.com applet and sometimes they would fail. I think I’ve figured out, hopefully if my analysis will save others some effort and frustration.
Background, I have several battery (3 D-cells) operated Particle Photon sensors. My desire is to send a notification to my phone when any of them detect a notable event. To do this I issue a Particle.publish() event which ifttt.com triggers on to send a notification to the ifttt process on my phone. To get the longest possible battery life the Photon is in Deep Sleep most of the time.
I could always observe on the console that the events were reaching the cloud. Sometimes the ifttt applet would trigger and send the notification to my phone, but more often the applet would start and fail with the message that the Particle API was down (which was clearly not the case).
What I finally figured out (I think) was happening was that ifttt would receive the trigger. If it ran the applet quickly everything worked. But if the applet was delayed (often for several minutes) if would fail. What APPEARS to be happening is that ifttt is checking that the Photon that sent the event is still online when ifttt finally gets around to running the applet. If the Photon has entered Deep Sleep the applet fails.
To solve this situation I added a Photon that is always powered up to receive the events from the battery operated units and then create a new event that ifttt triggers upon.
Now, of course, my analysis, could be completely wrong. Comments? Suggestions?
I’m not sure what is causing the problem you are experiencing, however I will mention Stringify as a possible alternative. It’s especially good when you want your Particle devices to interact with a mobile device, and the latency is a few seconds instead of the occasional minutes with IFTTT.
I think you have might have found the root of the problem. The Applet recipe does call for the EventContents and CreatedAt from the event to be sent as part of the notification.
PERHAPS this information is not being sent in the initial message to ifttt.
As a result when ifttt runs the Applet, it calls back to Particle to get this additional information but as the Photon is now offline the information is no longer available.
I need to do some testing w/o these in the recipe and see if it clears the issue.
Thanks for the idea.
I am having the same exact problem - did you ever figure out the exact cause? I am trying to publish an event to IFTTT, then I have 2 applets, the first sends an email, and the second publishes an event back to my Photon. The sequence is:
Photon publishes the even to indicate a condition
IFTTT receives the event sends an email
IFTTT also publishes back to the photon
When the Photon receives the event from IFTTT, it goes back to sleep
In testing when there are just a few minutes between events, this works great. I have been having issues getting IFTTT to recognize the triggers after my photon has been asleep for 6 hours or more.
The issue I have is that if the originating Photon goes to sleep before IFTTT runs its script, then the script fails. It seems that IFTTT is asking if the originating Photon is still alive. Not unreasonable as I could see endless loops actions biased on long offline originators (zombies).
Sounds like we are seeing similar but not identical issues. How long is your Deep_Sleep timer? Mine works fine at 7200s, but when I bump it up to 6hrs (21600s) it stops connecting to ifttt.
If your issue is because the Photon is shutting down too fast, have you tried simply setting a Delay(60000) to make it wait a minute before shutting down?
I changed the sequence on my system but it still doesn’t work. Now I have ifttt listening for photon power (connected), then iff publishes an event back to my photon. Once my Photon receives the call back, it check a sensor and publishes the result. Then it waits 60s then shuts down. It may be time to test Stringify
Since there is usually no activity at night, my battery powered photon is in deep sleep for at least 12 hours overnight. I also set the deep sleep to wake up and send an “I’m alive” event after 24 hours of no other activity. More about this later.
I tried keeping it awake for a period of time after it sent an event to IFTTT. However, it is not unusual for IFTTT to not run for 5 to 10 minutes. As I’m on battery power (3 AA batteries), keeping it awake for 10 minutes after each event would greatly reduce the time between battery replacements.
What works well for me is to have 2nd photon that is AC powered receive the event from the 1st (battery powered) photon. This 2nd unit then sends an event to IFTTT. This is very inexpensive (one photon and a USB power plug). A single AC powered photon can support a huge number of battery powered photons anywhere on the Internet. As an additional feature, this 2nd photon reports to me if it did not receive an event from the battery powered photon in the last day (likely battery dead or other problem).
As events sometimes get lost, the AC powered photon sends an acknowledgment of the event back to the battery powered photon which causes the battery powered photon to go back into deep sleep. If it fails to get the acknowledgement in a few seconds, it will resend the event until it does, or gives up after a minute.
I had considered using 3 D batteries. This would have changed the battery replacement interval from every 6 months or so, to several years but the addition weight was a problem in my application.