I am building a basic remote temperature sensor using IFTTT and s Spark variable. Basically, I created a spark variable that passes the current temperature in degrees fahrenheit to IFTTT and then created a rule in IFTTT to trigger an Android alert if the temperature drops below a certain threshold.
Things are working properly and IFTTT is capturing the results. However, there is an oddity. IFTTT keeps sending me alerts about the temperature even though it is above the threshold.
Specifically, the alert threshold is set to 60 and IFTTT is reading a temperature of 71. Curiously, even in this scenario, my phone beeps every minute indicating an alert. If I check the log at IFTTT, it says that I am triggering an alert. (Here is the rule: “Current_Temp on “First Core” is Less or Equal 60”
Why is it triggering? I am passing an INT through the spark variable and the temperature is clearly higher than the threshold. Is this a bug of some sort? Did I do something wrong?
I can share my code and such, but it is clear (looking at the IFTTT log that the data is being transferred properly.)
Did you once have a rule like the one that is being triggered? Sometimes it takes a long time for IFTTT triggers to go away. @Dave has mentioned that a work-around is to rename your Spark variable since then IFTTT realizes that this rule no longer applies.
Great point. For testing, I had originally set it to alert if temp was less than 90. Could it be that it has not updated the rule to the lower value yet?
IFTTT integration is a new feature and I think there are few kinks to be worked out yet. I know they have said that IFTTT does not have any other trigger points exactly like Spark so there is new code on both sides.
I would try renaming your core Spark.variable() and then change the rule to match and see if that fixes it.
Thank you. I am still having issues, but they are different. I modified the code and changed the spark variable to a new name. (e.g. it went from Current_Temp to Current_Temp2) I flashed and everything completed properly and then things go south.
If I go to CLI and put in “Spark list”, I see the spark, but the spark variable name has not changed! It still shows Current_Temp vs Current_Temp2. Is there something that I need to do to force the Spark cloud to update to the new variable name?
No after a few seconds the Spark cloud should know what variables your core has.
Are you sure the flash in fact succeeded? If it fails you can reboot and be running the old code. Some people like to have their core have a version Spark variable or publish a version string at startup to check for this.
Somthing like this would be a nice version of @bko 's suggestion. This page I made will show you all your Cores, their functions, variables, and can show you your published events. (It uses LocalStorage for your accesstoken, so that is saved on your computer only.) Might be useful for testing purposes.
void setup() {
//expose version function
Spark.function("version", pubversion);
//publish version on start-up CHANGE BOTH VALUES!
Spark.publish("version", "1.0");
}
void loop(){
}
int pubversion(String command){
//publish version. CHANGE BOTH VALUES!
Spark.publish("version", "1.0");
Serial1.write("version 1.0");
RGB.control(true);
RGB.color(255,0,0);
delay(250);
RGB.color(0,255,0);
delay(250);
RGB.color(0,0,255);
delay(250);
RGB.control(false);
return 0;
}
I sorted this out. The problem was that my variable names were too long and I was modifying the variables by lengthening the name. Hence, it did not take. Once I shortened the name, the problem was solved…
Back to the original question, BKO was dead on. Changing the Spark Variable name and then re-creating the IFTTT rule resolved the issue.
anyone have an idea why this is happening? It did the same thing to me, the IFTTT fires without ever passing the threshold. Mine is set to fire off a text if my temp variable is greater than 75, and instead fires once a minute and tells me the temp (69 now). I dont want to just change the variables name without understanding why this may work. Thanks!
The topic with the explanation is apparently private...
These are quotes from @Dave:
IFTTT doesn't tell us when a recipe is turned on or off, so we try to guess by measuring how often IFTTT asks us about a particular trigger. After you turn off a recipe, it takes about 6 hours before we can be sure it's off. Because your two triggers (one live, one old) use the same variable name, IFTTT is getting confused. It'll sort itself out in a few hours, or you can change the variable name now and avoid more notifications from the old recipe.
I've raised this issue with IFTTT, but they won't be able to address it for a while, since it requires them to make more information available to us.
Hmm. IFTTT doesn't expose any information about when recipes are created or destroyed, so we assume they'll ask about it every 6 hours or so. In that period if you're checking a function or variable, the cloud will continue to poll your device, and will continue to log events for IFTTT until the recipe times out. Once those events are logged, they take a few weeks (if I remember correctly) before they'll be cleaned up on our end while we wait for IFTTT to check back in.
I suspect this is what happened for you, the realtime aspect of the recipe kept running and kept logging events, and then they were all 'dumped' onto the IFTTT action when IFTTT finally came and gathered the triggered events.
I'm not sure what the best approach to resolving this sort of thing would be without changing how the IFTTT api behaves, any thoughts?
I found out what my issue was and the info may help others. I was originally using a STRING variable type and when testing “72.333” against 75 doesnt work as you would expect because they are NOT both numbers. When using a greater than or less than (in IFTTT) you must have a DOUBLE like this:
Spark.variable("temp", &temp, DOUBLE);
For mine I just had to change the STRING to a DOUBLE and it worked.
I posted this under a different topic, but this seems like a better location for my inquiry.
I’ve been playing around with the Spark IFTTT
channel, and I absolutely love it! However, I have found a bug with the
Spark.variable() function. I’m not sure if it’s on your side or IFTTT’s
side, but when I create two recipes monitoring the same variable
(temperature in this case), both recipes are triggered, even if the
variable isn’t meeting the condition of the second trigger.
For example, I have one recipe set up to text me if the temperature
is above 80 degrees F, and the second recipe texts me when that same
temperature variable is lower than 65 F. When The temperature rises
above 80 F, I get a text from both recipes, even though it sends the
current variable value, which is indeed above 80. Same happens if it
goes below the threshold: two texts, one from each recipe, printing the
correct variable value.
I have tried different comparison operators (greater than VS greater
than or equal to), and I have tried on two different Spark Cores, both
yielding the same results. I’ve also tried on two completely different
wireless networks.
Just curious if anyone else has experienced this same issue monitoring one variable with two recipes?
I’m using the OneWire Library, if that makes any difference.
Hey Jay,
I just purchased my Photon and this is exactly what I purchased the unit for! Can you possibly share your Particle App and any IFTTT details?
Thnx,
-TAC
Shouldn’t be too hard to make yourself. Kinda depends on what temperature sensor you’re using though. Once you figure out how to read that sensor, assign it to a Particle.variable() and monitor that using IFTTT.
I must admit that writing the monitoring code on the device allows for greater flexibility. You can make it much more refined. You can add time variables “if temperature remains above/beneath XX for a period of YY then act upon it”. IFTTT on the other hand will alert you as soon as it polls the device and notices it crossed the threshold. I also believe it will trigger repeatedly if it remains over the threshold (not sure on that one). Writing the logic on the device also allows you to change the threshold levels using a function call, which may or may nor be convenient.