I’m trying to change mode when it is in a particular mode.
Eg When it is sunset and the mode is home - change to night. -versus- When it is sunset and the mode is away.
So:
Sunset + Mode Home = Mode Night
Sunset + Mode Away = Mode Night Away
I can’t do this because when I use a mode as a condition - I can’t set the mode. This seems a little counter intuitive.
First we have to ask a couple of questions, because those are now done differently depending on your exact set up.
One) what model of the hub do you have?
Two) which version of the mobile app are you using: smart things classic or “smartthings (Samsung connect) “
In either case, the trick is to set up an automation which only runs in a particular mode and runs at sunset.
If you are using SmartThings classic, you should be able to do this with a routine. You’ll find the sunset condition under “additional settings.” You would need one routine for each set of conditions, so in example that you gave, you would need two. The first routine would run in Home mode and change to Night. The second routine would run in away mode and change to Night Away. Each of the two routines would be set to run at sunset.
So…Set up a routine which changes the mode, runs when it is sunset, but runs only in a specific mode. That gives you the “and” stacked conditional that you were looking for. 
If you are using “smartthings (Samsung connect)” there are no routines, so it would have to be done differently.
I am not using classic, I just can’t see how to do it in the new app.
@JDRoberts I can’t seem to find the functionality we used to have in the classic app anywhere
Here’s the help page for the new app, you can try asking there.
https://help.content.samsung.com/csweb/ticket/createQuestionTicket.do
I’ll bring this up with the product team - agree the restriction here doesn’t make much sense and you have a perfectly valid use case.
Hey, any update to this? I have the exact use case in classic, but I just rebooted so I could be in the new app and I’m running into the same issue. Basically, for a custom automation, I need mode to be in the “If” statement AS WELL AS the “Then” action. Currently, it’s either / or.
I take it this is still not possible?
Since it still doesn’t seem to be available, the workaround would be a daisychain of two automations.
Automation 1: set up everything on the “if” side the way you want, but on the “that” side instead of changing the mode, turn on a virtual switch.
Automation 2: use that switch coming on as the “if,” and on the “that” side, change the mode.
You’ll also need something to turn the switch off again. I’m not familiar enough with the new app to know the options for that. In the Classic app, you’d have 4 choices:
A) set the virtual switch to always turn itself off after 1 minute
B) use a momentary switch
C) turn the switch off as part of automation 2
D) create a third automation to turn the switch off when the mode changes to the target mode in automation 2
I’m sure at least one of those methods is available in the new app. I’m just not sure exactly which.
@jkp or @Automated_House might know.
JD that is very helpful. I think I can make use of that thinking to do what I want. Many thanks!
@JDRoberts work around will work since you still can’t use a mode as a condition and an action. I know they’re still working on the custom automation creator, so maybe that will change in the future.
This is still not possible and it’s been a year.
Any chance an engineer can take this one and simply allow mode in condition and action at the same time? it must be like a 10min change - as this existed in the old app - so the platform supports it generally, and you can use a mode as condition, and you can use a mode as an action. All the pieces are there. It feels like it’s almost configuration/constants that need tweaking to allow it.
Staff has posted in the forum that the reason it was removed was to avoid race conditions which had occurred from time to time on the old platform. 
Fixing that would likely be considerably more than a 10 minute fix.
It was once suggested that there was a perceived issue with users being able to too easily create loops if something could be both a condition and an action in the same automation, and this seems like a valid concern.
However the frustrating thing is that if you specify a time range in an Automation it will be recognised as a filter/restriction rather than a triggering condition, and that is exactly the concept that is required to safely address the concern above.
Rather than preventing something being both a condition and an action, the condition should be degraded to a filter/restriction if also used as a action.
I am sure that isn’t a ten minute fix either.
Staff has posted in the forum that the reason it was removed was to avoid race conditions which had occurred from time to time on the old platform. Fixing that would likely be considerably more than a 10 minute fix.
To prevent the loops would be much more than 10mins work - I meant more to match like for like with what people had before on the existing the app. If anything, it’d be removing the code that adds that restriction, removing the unit test for that restriction. I guess some integration test would need to be updated to test the permutations, maybe that’s where it’d take longer.
re: loops/race conditions, it’s a bit annoying this particular one was stopped, as I’m sure other loops are possible, at the very least across two rules (if light A on, turn off light B, if light B off turn on light A, etc.).
Rather than preventing something being both a condition and an action, the condition should be degraded to a filter/restriction if also used as a action
Yeh that would solve it too. Agreed it wouldn’t be a quick fix.
This is a loss of functionality, and as Troy points out, there are legit reasons for having this functionality, so it’s very weird it was removed without a replacement. The two rules with a virtual switch workaround is an interesting idea, but it is hacky. I guess people will have to keep using the old app if they want to do this sort of thing?
Eugh… looks like it’s the same with security modes. So I can’t say, “if we’re already Disarmed, and there’s no motion in the living room for 10mins, to automatically change to Armed (stay)” 
Removing this functionality in the new app because of a concern of users creating endless “loops” is not valid, as they already introduced a guardrail limit, 250 actions, and the hub stops working anyway.