New App: Cannot Use Scenes in Automations if a device of a scene is also in the IF part of an automation? (Bug?)

Apps & Clients Features & Feedback
1

So, this is an odd discovery, maybe a bug.

Simply put: an automation cannot call upon a scene in the Then statement if that scene uses a mode or device that is part of the automation’s If statement. Dumb.

Example that led to the discovery: I have a desire to create scenes that can basically be the then portion of an automation. By doing this, the scene becomes a quick way to effectively force run the automation, but I only have to build it in one place and tweak it in one place.

Simple Notional Example:

Automation titled: Goodnight
IF mode = home, time is after midnight (12:01am), living room dimmer light is off
THEN run Scene Goodnight

Scene titled Goodnight
Do: living room dimmer light on at 10%, set mode to night

By creating this Then portion as a scene, I can force run this implementation any time I wish, by the click of it on the new app. But I’d also like it to autorun whenever the IF conditions are met. I could simply do the If Then and rebuild the contents of the Goodnight Scene explicitly into the Then portion of my automation, thereby having two instances that I’d have, which is not ideal for tweaking, but I should not have to do this.

The above notional example SHOULD work, except, if you build the scene, then go and build the automation that will use that scene in the Then statement, the scene will be grayed out. At the bottom of the scene selection page, it says, “Scenes that conflict with other scenes you’ve selected aren’t available.” Except, this is not a scene conflicting with another, it is really just nonsense, a bug I think.

Try it to verify I’m not crazy. In fact, in my notional example above, the fact that the mode query is in the IF, as well as the living room dimmer query, are both preventing the selection of the Goodnight Scene, since the scene also does something to the location mode and the living room dimmer.

It’s gotta be a bug, right? There’s no reason for preventing this, or am I missing something? If it is a bug and others can verify, some of you have a significant standing in this community: can you alert the right people at Samsung?

Thank you!
Derek

2

It was an intentional design decision by ST devs to prevent looping and racing conditions in automations. (weather it was a GOOD decision. Well, lets just say the jury’s out…

They have shown the potential for reversing some of this im location modes (you used to not be able to both trigger on and change a mode in ths same automation, this changed two versions ago in the mobile app.)

The discussion is buried in this thread: https://community.smartthings.com/t/get-ready-to-make-the-switch

2 Likes
3

As @nathancu says, there was a restriction on modes and devices appearing in both a condition and an action but it was lifted a while back (it was actually lifted for devices as well as locations). It seems it wasn’t lifted as completely as it could have been.

You get a related issue when a device appears in two scenes, even if the action is the same in both and there is no conflict.

Many users never had any desire to have locations or device changes to appear in both triggers and actions. They just wanted to be able to use them as restrictions when the Automations did trigger. The location modes can now be flagged as a ‘precondition’ to allow this. However it still prevents use of a Scene containing the location mode as an action.

Bug? Probably not. Overlooked? Possibly. Inconsistent? Definitely.

You may still be able to use the fudge of adding things to Scenes after creating the Automation. I haven’t tried that for a while. I don’t like relying on things like that.

2 Likes
4

I was about to say I thought that had been changed now!

5

Well, dang it. I’m foiled again. If it was a bug, I could have hoped for a fix. But if by design, this approach to effectively manually run an automation has been foiled.

I recently posted a discussion inquiring about forcing automatons to run, as I could do with routines in the Classic App, but as that discussion concluded, you cannot. Well, not natively. With WebCoRE you can. I haven’t graduated to that level yet.

So my hope of using scenes as the actionable Then statement of the automation seemed the perfect solution, given scenes are able to be run manually on demand.

But foiled again…

Is there no native way to get where I’m trying to go in the new app?

6

You can daisychain it. Have the event be a virtual momentary switch and then have A different automation have that switch coming on trigger the scene you actually want.

It’s not elegant, but it should work. It’s a method people sometimes use with Ifttt or other third-party integrations. :sunglasses:

1 Like
7

Just came to say I had routines and scenes that did this fine, all but one carried over OK in the migration. The ones that copied over actually keep working funny enough but the app won’t let me re-create the last one. Awesome.

1 Like
8

Well, I have no idea why but if you create a complex scene then try and run it with an automation it won’t let you attach it. But if you create a basic scene, create the automation, the update the scene, it works just fine…

3 Likes
9

That’s interesting!

Welcome to the community @TheCosworth

10

I just migrated to the new app and discovered this issue with conflicting scenes/automations. I was able to get around it by doing what you said, i.e. leaving the mode out of the scene first, create the automation, then add the mode back to the scene.

In my case, I have an “I’m Back” scene that will turn on some lights, adjust thermostat, and change mode to ‘Home’. I have two presence sensors. In the old app I had an automation that would run “I’m Back” IF anyone arrives AND the current mode is ‘Away’. This prevents “I’m Back” from running if someone arrives when someone is already home.

I’m really curious how I can get this functionality with the new app without performing this workaround. Has anyone figured this out? With the ‘Precondition’ option checked there shouldn’t be concern of conflicts between the automation and scenes, but the app still doesn’t allow it.

11

I guess not :frowning:

12

I asked this question over on Reddit and someone suggested a solution that doesn’t involve the workaround. Instead of putting the mode change in the scene, put it in the automation. Not sure why I didn’t think of trying this, but it seems to be working and I haven’t discovered any limitation of doing it this way.

1 Like
13

Cool, I’m going to test it soon…

14

EDIT: ignore my last, I forgot what I was talking about…

Yeah, it turns out I was doing this already :slight_smile:

In summary, the automations call scenes, which can have security and hub location mode changes without issue.

I’ve decided I like these functions there in scenes as well, since the app has a widget that allows you to have scenes available at the click of a button. Running an automation on demand takes more clicks.

So, bottom line, automations decide if a scene should be done, but all of the work of the automation goes in the scene for best results.

15

Err… i forgot what I was talking about here. Ignore my last. @jstluise your idea seems to work well though!

16

Okay, so I found another solution. I like having the mode changes in the scene because then, with the phone app widget, I can force run the actions of the automation when desired. Maybe this is not necessary if I thought through my automations more carefully, but that’s how I’m doing it.

So, instead of the work around of adding a mode change to a scene after it is already attached to an automation, the add’l solution is this: have mode changes done by virtual switches.

I created my virtual switches with the SmartApps > Virtual Device Creator. I know I added this SmartApp on the old classic ST app, and may only have it due to being grandfathered. I do not see it as an option to add to the new app outright, sorry.

With Virtual Device Creator, create virtual switches at will. I made 6 total (organized in a “Room” of my home called “Virtual” so that it appears in my room list at the bottom when alphabetized): A) v Mode Home, v Mode Night, v Mode Away; B) v Security Armed Away, v Security Armed Away, v Security Disarmed.

Each of these virtual switches are set up the same way with a matching automation of their own. For instance, the automation v Security Disarmed is: If v Security Disarmed (virtual switch) is On, Then Change the SmartThings Home Monitor mode to Disarmed and set the v Security Disarmed (virtual switch) to Turn off after a Delay of 10 seconds. (Thus, any trigger that turns on a virtual switch will, by these automations, run their action and then turn itself back off 10 seconds later, and so all my virtual switches are off by default unless in active use.)

It is more elegant in my mind than the work around of attaching scenes to automations then going back to edit the scenes. But maybe not. None are ideal. The ideal to me is full control in the automation to begin with.