Whoever your source is, they are grossly misinformed. I led the charge to get rid of IFTTT and cost was not a factor in that decision. Here are the actual reasons IFTTT support was discontinued:
Low usage. Less than 2% of active Particle users used IFTTT and that number continued to drop year after year.
The webhooks experience is better for educators. The free version of IFTTT had initially been a useful tool for teachers but changes had been made so that free users were only guaranteed a response within one hour, removing it as an option for most teachers.
We needed to upgrade our Node version and our IFTTT integration wasn’t compatible. The migration work would have been intensive so our Director of Software Engineering and I met with IFTTT to see if there were options that required fewer months of labor. There weren’t.
I have been paying for the premium IFTTT service, too. Prior to the planned drop of service, I found notifications from IFTTT service often late or entirely missing. So, I can understand the move by Particle.
About a month before the planned cutoff date, I felt I better get my act together and implement the workarounds available using Webhook Integrations. @Colleen and others have posted the information/solutions needed. Thanks for that, btw!
I wish I had done it a lot sooner than I did. What I find now is: notifications are being received within a few seconds of a trigger. Very Nice! At this point, I don't worry about it.
We need to understand a bigger picture of what Particle did with us, the developers
Is like buying an Electric car that has charging stations at home and all gas stations , and suddenly , they disable the stations, and their answers is " do it at home". under those circumstances Ive never buy the car in the first place.
I cannot fix my 20 firmwares with their webhook tutorial, I need to pay someone to do it
If its a cost issue, they need to consider a fee to keep IFTTT service up
That analogy seems flawed to me. In my mind it’s more like buying a car years ago and then learning that it doesn’t meet new emissions standards so you must bring it up to the new standards or be unable to use the car. Except in this case multiple transition guides and months of notice were provided to help you.
What issues are you having with the tutorials? Have you tried to follow them?Happy to help!
As previously stated, it is not a cost issue and a pay-to-use option will not be offered.
I can say that the ifttt shut down has helped me. My fix was to use web hooks to trigger a sending of a WhatsApp message.
The last time I tried ifttt and I was expecting an up to one hour delay, I never got the message at all.
So your mileage may vary but I found it was an opportunity to learn something new.
I too have found IFTTT to often be slow and sometimes unreliable. We (Team Practical Projects) originally used IFTTT and Blynk to get started with IoT, but these services have proven to be costly (over time), not reliable enough for real applications, and ever changing (forcing us to revise otherwise completed projects even when we were happy with the results). Over time, we have evolved our own ways of doing IoT which we have fully described in the document:
The solutions described in this document are fast, reliable and have the benefit of requiring only 3 vendor accounts: (1) Particle (which you already have, being a Particle customer), (2) Account with a mobile provider (which you already have since you have a cell phone), and (3) Google (which you already have because you are breathing). I can appreciate @jxoco solution of using WhatsApp messaging, but we use sms texting which does not require any app to be installed on your cell phone and, in fact, doesn’t require a smart phone at all (an old style flip phone works fine). The aforementioned document also describes how we control and status our Particle devices (writing our own Android apps in MIT App Inventor – we supply a link to a project that shows you exactly how to do this), how we log sensor data (to a Google sheet – free and no-code for graphing and other post processing) using Google Apps Scripts, and how we use webhooks and PHP/SQL to communication with external databases.
IMHO – it is worth a small investment in time to read through this document and look through the completed-and-deployed projects are are referenced in it. The learning curve is small and shallow and you will thereafter be able to create and deploy fast and reliable IoT projects without ever having to worry about some third party service being suddenly changed, suddenly priced when previously free, or suddenly going out of business altogether (unless you are concerned about Google going out of business).
@BobG, Great document.
My only critique is that, for me, none of the links are ‘live’. I had to type in all of the link if I wanted to go to one.
I am new here, about 10 days in. I had given up on the particle ecosystem 4 years ago and switched to the ESP8266 and ESP32.
What brought me back, for now, is the Boron 404x cat M1 chip.
I have gotten my project done with it.
But what I really want to add is, there should be a place here to collect all of, “This is how I solved it” solutions. Maybe there is, and I haven’t found it yet.
And that would be the place for you to expand on your solutions.
@jxoco: Sorry about the links. They are indeed links, but it appears that GitHub’s pdf reader doesn’t support them as such. If you download the repo and open the document in a pdf reader or a modern browser (e.g. Chrome), the links will work just fine.
We have looked at ESP8266 and ESP32 but have not found support for any IoT communication other than MQTT. MQTT is fine, but you need to sign up with some MQTT server and then you need to “roll your own” application protocols on top of it. Particle’s “big 4” (Particle.variable(), Particle.function(), Particle.publish(), and Particle.subscribe()), along with webhooks, make this soooooo much easier. And, as you point out, the fact that you can develop products with options for WiFi and cellular and the same code works for both is a really big benefit (IMHO).
We created this document in order to put all of our solutions “in one place” as you say, but I agree that a standard place to do this that is supported by Particle would be helpful. Particle does have a channel on hackster.io and we always post something there whenever we release a new project or solution on GitHub.
