So you are saying that IFTTT integration now honors mode restrictions? I still have an open ticket on this.
My statement has nothing to do with IFTTT honoring mode restrictions. My sense is that it will be quite a while before IFTTT allows this.
There’s a straightforward workaround for anyone who needs this functionality now. Create a virtual switch and include it in whatever the restrictions are. Then have the switch that IFTTT subscribes to follow the restricted switch. Or if the restricted switch is an actual physical device, have a virtual switch that IFTTT subscribes to follow that. Works both ways.
Same outcome as a mode restriction on the one that IFTTT subscribes to , doesn’t cost anything extra, just a little harder to track your set up.
Might be good idea if support have that one in their back pocket for when the issue comes up. 
1 Like
Then it should be removed from the integration if it doesn’t work and is not expected to work. This is what my open support ticket is all about! @JDRoberts provided me a workaround; why couldn’t SmartThings? And you wonder why people are frustrated and annoyed?!!
I slightly misunderstood this post. Sorry. This mode selection is being ignored I believe as it got tacked on after the fact. We are rai9sing this to the platform team for a fix.
Creating virtual/slave/dummy switches might not be very straightforward to some customers. Some SmartApps are mode aware while others are not.
If your aim is to do something more complciated than If This Then That, a custom SmatApp might be a better option. IFTTT itself does not have to functionality to do something when multiple conditions are met, like If This When It’s Then That. I think the Mode Restriction Option is just boilerplate code and it is up the the SmartApp author to take advantage of it. Maybe it should be disabled or hidden by default.
1 Like
Agreed, but if it gets as far as support, they could actually create the virtual switch for the person and even tie them together. 
Obviously not as good as including mode restriction in the IFTTT subscription, but I’m just saying it’s an available workaround.
IFTTT is a very valuable option for some people. So if you’re already using it, then being able to add mode restrictions can have benefit.
I agree that having a mode restriction might be useful but it could also add unnecessary complications. It would be an all or nothing thing right now. As far as I can tell, one can only have a single install of the IFTTT smartapp and restricting it to a few selected modes would then eliminate it as an option in any other modes. I completely agree that more control is needed in this area, but disagree about how it should be implemented.
This problem really should be solved on the IFTTT side by allowing multiple or secondary conditions such as a time restriction.
I don’t think we would block multiple IFTTT connect apps if it made sense, but IFTTT channels are a one time thing. In order to allow for multiple IFTTT connect apps to be installed we would need to have multiple (IFTTT1, IFTTT2, IFTTT3, etc.) channels to allow for this.
Makes more sense to work with IFTTT to get conditional statements into the rule logic.
I’m going to mention this to them and see what they think we could do to expand the functionality.
1 Like
Oh, I wouldn’t want the entire IFT TT restricted.
The use cases most people have been talking about is where they have a virtual switch which triggers an IFTTT recipe, and they include it in a routine which only runs in some modes, but the IFTTT recipe ignores the mode restriction and runs any time the switch comes on leading to unexpected results.
I do understand why fixing this is really really messy. Because the subscription is not to the routine, it’s to the switch. And there’s no way to add moves into the IFT TT recipe. Which probably isn’t what they want anyway if it’s for something like sending a text.
That’s why the workaround I use lifts the IFT TT subscription out of the routine. Anytime I trigger the IFT TT subscribed switch, that IFTTT recipe fires. Keeps it very simple on the IFT TT side.
What I do is restrict when that switch is fired by tying it to another switch. It’s the second switch which is restricted, and all of that happens inside smart things.
So I guess my fix suggestion would not be to add modes to IFTTT, but rather to create a feature in the mobile app that simplifies the creation and use of the restricted switch.
There’s some education involved in the use of these, but I think they preserve the architecture on both sides pretty well .
This is something that they have publicly stated they are working on. No time tables of course.
2 Likes
The issue with putting all the conditional logic on the IFTTT side, is that often IFTTT is just a connection between one event and another event. It’s available to run in all kinds of conditions.
For example, if I want to send a text to my neighbor, right now that’s one IFT TT recipe. If I had to add all my conditionals, I’d end up with a separate recipe for every condition set. A lot of work to maintain and easy to get wrong.
Consider people who are using IFT TT to turn their sprinkler on and off. Right now, again, that’s two recipes. Very simple. But give you a nice integration that you didn’t have before.
I’d rather keep all the conditional logic in smart things where it might also be running other stuff at the same time, and have that flip a virtual switch which then turns on the sprinkler through I FTTT. Otherwise I maintaining the exact same conditional logic in two places.
This is true if adding multiple SmartThings IFTTT channels made sense.
Since adding Multiple Channels to IFTTT is impractical making those restrictions on the IFTTT side is going to be the best bet.
Sorry, Tim, I’m not following this.
I can do this work around now. I set up a routine with all my usual restrictions, or smart lighting or a custom smart app or whatever.
It’s just that instead of actually flipping the switch that I have to TT subscribes to you, I flip sorry, Tim, I’m not following this.
I can do this work around now. I set up a routine with all my usual restrictions, or smart lighting or a custom smart app or whatever.
It’s just that instead of actually flipping the switch that I have to TT subscribes to you, I flip a Second virtual switch which is only there to allow the restrictions to be applied.
And instead of every putting my IFTTT switch into a routine, I just tie it to the restricted switch.
My IFT TT switch goes on, my IFT TT recipe fires. It’s unrestricted. But it only goes on when the switch which is restricted goes on.
So the restrictions get applied. They only have to be maintained in one place. The IFTTT recipes don’t have to be conditional, they just represent the execution link.
It works fine now, it’s just that you have to understand virtual switches in order to implement it. But you don’t need multiple IFT TT accounts or channels.
And that is where it breaks down. If you are comfortable/capable enough to implement virtual switches, then most of this logic would be better suited for a SmartApp rather than an IFTTT rule. The appeal of IFTTT is that with just a few clicks you can set up rudimentary automation with zero programming. That appeal is lost once you ask the customer to install and configure virtual switches that complicate the setup.
1 Like
Oh yeah, totally.
What if we could do without virtual switches though. That would be cool!
1 Like
This issue is moot to me now, since JD’s workaround works and is reliable. Simple Rules Engine also works, and does not require the virtual switch. As long as SmartThings doesn’t stop honoring mode restriction on virtual switches and/or Simple Rules Engine stays viable, my problem is solved.
I still expect ST to make the integration work as advertised though, or remove the inoperative modes menu.
2 Likes
^ This should be done regardless. Yes.
1 Like