@jon, I see. So it seems that IFTTT is not reading the variable correctly or does not know how to handle/parse the variable value. I wonder if changing your recipe to 60.0 and instead of 60 would make a difference? Otherwise @Dave will have to provide some insight here. Your debug windows speaks volumes. 
@peekay123 it seems like IFTTT does not like having a THIS with a 65.0 value, nothing gets triggered when I set the rules with a â.â. IFTTT seems to favor âswitch1â on over off though. It tends to let that recepie take precendence (and itâs listed as the latter one of the recepies).
My C is rusty, help me out with printing with no decimals.
Are you setting new values every time through the loop()? Could that be creating a data firehose? I would think that IFTTT is only getting new values periodically. But perhaps not, and IFTTT is getting overwhelmed? I dunnoâŚ
Maybe try @Moors7âs suggestion of using SSE? Or just try slowing down the frequency of the variable updates?
@peekay123 @dougal I did not want to add to much logic but yes, for âproductionâ I would only update the variables on some significant change and also held over some time.
There is no way IFTTT could get stressed by updating the variables if it is connecting using REST, publishing a lot of connected events might but that is not the case.
I changed code and recepies to only use whole numbers for humidity and a log with no changeâŚ
My timezone tells me to take a break now, Iâll check in tomorrow and see if anyone came up with anything. IFTTT triggers are still at >65 and <45 for the results above.
Why is IFTTT so stressy (part from being indecisive), I mean calling âswitch1â âonâ so many times in a short period and all?
@jon, this is all great debugging info and your questions regarding the flurry of function calls from IFTTT is valid. Perhaps @Dave can help?
Keep in mind we donât have much control over when IFTTT decides to do things, even if weâre really prompt about when we tell them something interesting happened. IFTTT by its nature will be bursty, but any given trigger should result in a planned action within about 15 minutes max, and weâre shooting for something closer to 1 minute average response time.
Iâve been thinking about changing trigger behaviors for functions and variables to be single-fire only, until ifttt comes and checks on things, so itâd be a little less bursty, but wouldnât necessarily be more prompt.
Thanks,
David
@Dave I understand that your answer is more general but my guess (if I may be so bold) is that is something in âourâ integration with IFTTT. I mean lets say my that instead of triggering my function âswitch1â âonâ would be posting to Facebook, I dare to say I would not see a lot of duplicated posts.
Not to criticize but do you see my point? Also itâs the case where variables donât seem to be evaluated correct so that the THIS part of the two recepies gets evaluated wrong (causing both âonâ and âoffâ being called at wrong conditions) or the call from IFTTT to Spark gets messed up so it triggers the wrong functions or with cached parameters.
I am specualting wildly but from the logs above it looks like something goes wrong. Let me know if I can help or provide any more input.
Hi @jon,
That's why we're having this beta, so we can find and fix things that might be bugs on our side. That's why I said earlier:
Ooh, interesting! Thanks for posting, I'll look into it
Thanks,
David
2 Likes
Hi, I am having the same problem.
Did you fix the issue?
I created 2 recipes in ifttt:
- Variable less than 21
- Variable greater than 23
When one recipe triggers, the other one triggers immediately after.
I know I donât have a variable variation in between.
Can anybody help me?
Thanks!
Personally I wouldnât use IFTTT to set up boundaries like that, since IFTTT is slow, and these things are the result. Rather, set the boundaries on your device, and send a SSE that will trigger whatever you want it to trigger. That way you can check things on the device, and expand the ârulesâ.
Thanks! I guess it is a IFTTT bug?
Would have liked to be able to set different limits in recipes but I can set it in firmware too.
Not really a bug per se (I think), but it only checks variables on an interval, so it can take quite a while before it reacts. It also triggers repeatedly as long as itâs over the limit, which isnât that nice either 
I think handling it in firmware provides much more flexibility. You can still dynamically change though values though, perhaps even easier than with IFTTT, using Particle.function()s. Let us know if you need assistance.