IFTTT sending a variable change, variable already at the value, triggers logic block

485 views
Skip to first unread message

Apilio Group

unread,
Apr 18, 2019, 11:09:44 AM4/18/19
to Apilio
Below is the path happening:

  • I leave an area near home, that triggers IFTTT to "set variable left_home to true"
  • I enter that area coming home that triggers a "set variable arriving_home to true"
  • That variable becoming true triggers a logic block which runs the Negative Result (it's not night)
  • That triggers IFTTT to "set variable left_home to false"
  • That triggers a logicblock to send a request to IFTTT to "set variable arriving_home to false"
Any change to either left_home, or arriving_home triggers the logicblock to either request IFTTT to turn on portch_light (positive results), or to change left_home to false (negative results)

Now for the problem: the two variables triggering that logicblock (left_home, or arriving_home) are supposed to end up false, and they do. But the second variable changing to false triggers that logic block again which then has IFTTT send another request to set left_home to false, which is already false. I would expect it to all stop, but that again triggers the logicblock even though the value of the variable did not change. The command to change it to false did run, but no changes. 

So it just then runs again and again...

Am I misunderstanding how a logicblock works? Doesn't setting "Evaluate this logicblock when any connected variable changes" mean the variable must change, as opposed to the command to change being sent?


Philipp

unread,
Apr 23, 2019, 2:56:50 AM4/23/19
to Apilio
Hey there!
I'm not sure I can interpret your intended outcome correctly. I suppose you want the light to go on when you come home during night, and switch it off when leaving home at any time? Is that correct?

bruno...@gmail.com

unread,
Apr 26, 2019, 6:28:31 AM4/26/19
to Apilio
I think you need something similar to my setup.
When I leave home, turn off the light
When I arrive home, turn on the light

note: you can name the variables whatever you want.
note2: this can be a bit tricky to get on this but apilio is quite limited in terms of validating conditions so we have to create loads of applets.

in Apilio:
create a boolean variable "at_home"
create a boolean variable "away_from_home"

create new condition for boolean for "at_home", required state = True
create new condition for boolean for "away_from_home", required state = True

create new logic block name it "switch_light_on" and tick the condition: at_home, 
 Add IFTTT action and put "arriving_home" as the event name.
 Add IFTTT action and put "set_at_home" as the event name.

create another new logic block name it "switch_light_off" and tick the condition: away_from_home, 
 Add IFTTT action and put "leaving_home" as the event name.
 Add IFTTT action and put "set_away_from_home" as the event name.


IFTTT (create 4 applets):
Create a new applet:
IF WebHooks, 
[name the event "arriving_home"]
THEN
Webhooks 
[paste the "at_home" set True link from apilio] 

Create a new applet:
IF WebHooks, 
[name the event "set_at_home"]
THEN
Webhooks 
[paste the "away_from_home" set False link from apilio] 

Create a new applet:
IF WebHooks, 
[name the event "leaving_home"]
THEN
Webhooks 
[paste the "away_from_home" set True link from apilio] 

Create a new applet:
IF WebHooks, 
[name the event "set_away_from_home"]
THEN
Webhooks 
[paste the "at_home" set False link from apilio] 


Hope this help! 

Apilio Group

unread,
Apr 26, 2019, 7:52:02 PM4/26/19
to Apilio
Quite interesting, as that is pretty much exactly what I"m doing. But there is an occasion where a webhook is sent to update a variable that already exists with the same value, and given it is not changing the value, I expect the associated logicblock to not run. But it does run, even though there really was no change.

It's not messing up the work of the processes, it's just running a lot .

But since posting my issue, I saw the notification from Apilio that it is being abandoned so I'm attempting a move to using Tasker, along with Autoremote to talke to IFTTT. I don't know if I'll be successful with that, as the Autoremote is failing, and I"m getting no help at all with problems with that.

Bruno...I appreciate your input. Thanks!

Philipp

unread,
Apr 28, 2019, 4:45:26 AM4/28/19
to Apilio
Hi!
Where from did you get this bit:
"But since posting my issue, I saw the notification from Apilio that it is being abandoned"

Because that's definitely not true - very much the opposite! https://www.apilio.io/blog/a-word-on-the-stringify-service-shutdown

Apilio Group

unread,
Apr 28, 2019, 8:47:25 AM4/28/19
to Apilio
You are right. I was having a brain fart. That is in fact why I researched and found Apilio.

The reason I had decided to move to Tasker and Autoremote is because with Tasker I can control variables within Tasker and not have to rely so much on passing things back and forth to set variables. It's more like a programming language.

That being said, I may have to abandon that as Autoremote is erroring out and I'm getting no hello from attempts to get answers, neither from 3 different communities or the author.

Apilio Group

unread,
Apr 28, 2019, 9:37:32 AM4/28/19
to Apilio
Back on topic for a moment...

So does the logicblock interpret the fact that a web command from IFTTT as a positive trigger even if the variable was already at the positive value and did not change? That is what is happening.

My expectations were that the logic block did not fire unless there was an actual change from false to true.

Philipp

unread,
Apr 29, 2019, 4:10:05 AM4/29/19
to Apilio
So does the logicblock interpret the fact that a web command from IFTTT as a positive trigger even if the variable was already at the positive value and did not change? That is what is happening.

Yes it does, and that by intention. There are some other use cases where this makes sense.
To prevent unnecessary triggering of actions, you can select the option "only trigger actions when result changes" in the advanced options section on the logicblock.

Cheers
Philipp 

Apilio Group

unread,
Apr 29, 2019, 7:39:38 AM4/29/19
to Apilio
Thanks Phillip.
Reply all
Reply to author
Forward
0 new messages