Are there scenes?

There is a sweet spot somewhere for a remote, but my leanings are toward simple. As to WAF, simple is always better. My wife knows how to use one button on the 4 button MiniMote on her bedside table: all off. I’m sure if I gave her more buttons she’d still only use one.

Again, I’m not convinced there is a need for a scene object in ST. I’m not even using virtual devices for most of my scenes (every room has at least three), and still I have ample control and flexibility. Scenes are easy. I readily see how people can be baffled by ST’s UI, where “scenes” aren’t obvious. But you don’t need to change the underlying engine to address a UI problem. As for save/restore, I just beg to differ: that’s a bad idea. Who saved it, who saved it first, who saved it last, was it me, or some other app? Good luck with that one!

The most essential “basic” use case (“requirement”) that I have for save / restore is for short term temporary events.

Example:

  1. (a) My outdoor lights are set to a pleasing evening level, perhaps even with a few colors, using a nightly Hello Home Action; (b) An intrusion detection device (motion or window sensor) senses someone on the property and a SmartApp subscribes to this, and as a results, brings the lights up to full brightness. This might even be an appropriate response for my car entering the driveway – bring up the lights on the driveway to make it safer to see the road.; © a few minutes after the intrusion is over, I want the lights restored to the level they were at prior to (b).

Of course there are a few ways to handle this, particularly since (a) is established using a Hello Home Action – i.e., it is possible in this scenario to simply re-run the Hello Home action that applies to the current Mode…

BUT: In the more general case, I may have turned on a set of lights MANUALLY for a particular reason. Maybe the dog went into the yard and I adjusted SOME of the lights to see him. Regardless, if a temporary event caused by some SmartApp which changes the current settings (the live scene), then I want that live scene restored after the event has passed. The event could be a smoke detector false alarm, etc., etc., etc…
2. The state of my Sonos player is an example of a scene element. If it is playing a certain song, that song should be resumed, on the same set of speakers, after any messages are spoken due to an alert (“Mom’s home.”).
3. The state of a door lock can be considered a scene element. If my door is locked and I temporarily unlock it to allow a guest in, then the door should return to the locked OR unlocked state if it is in automatic restore mode. This saves me from writing complex logic to reference what the state of the lock should be after the event (e.g., If Mode = evening and all kids aren’t home, then leave door unlocked. If Mode = night, then lock the door, even though I went outside to walk the dog and purposefully did not lock the door behind me because it was a short walk and I expected that to be the state when I returned) – sure I’m stretching, but I’m demonstrating that the possibilities are numerous.
4. How about the state of a thermostat? Bring up the heat for an hour because I’m chilly, then restore to the previous temperature setting.

To deal with your concern:

… it is sufficient to put rules on the restore process so that it only applies in specific cases. If it turns out that we compromise and scene restore is only needed for temporary actions, then a “saved state” should have a limited lifespan. Alternatively, as I suggested in another post, a “saved state” can only be restored if the Mode is unchanged since the time of save.

If multiple overlapping scenes or individual state changes occur, then it is reasonable to default to some sort of functionality, even if it isn’t the most optimal or intuitive. Is a stack of scenes appropriate, perhaps not. Is it sufficient to say that a restore scene is no longer possible if any overlapping scene is executed after the save, … ok, I can live with that. In short: I can live with elimination of complexity, but I strongly disagree that we should throw this baby out with that bathwater.

…CP.

I appreciate your input, Morgan.

I know much of this discussion is theoretical and a brainstorm as to the ultimate wishlist, minimal wishlist, and happy middle-places.

In my perception, at the minimal functionality level: Macros = Actions = Scenes, with the differences being subtle and possibly philosophical. I am obsessed with the idea of “Scene Restore”, and hope it perhaps sways a few opinions if it is instead called “Undo Macro” (with various reasonable limitations as to what can and cannot be undone and what circumstances block an undo).

Even if the participants insist that the basic functionality of Macros/Scenes are redundant with Hello Home Actions, I still think we can agree that the user-interface is insufficient. Hello Home can turn on a set of lights but they can only all be set to the SAME DIMMER LEVEL!. That is a ludicrous limitation that is easily overcome with the use of a user interface for scene capture, and the subsequent ability to “load scene” in any Hello Home Action…

Sigh. smh.

…CP.

Wow!

That’s a ton of complexity to attempt to automate things that probably don’t deserve automation. How can you automate exceptions? Why should you try to? How long does it take your dog to do his business? You’re gonna do something when he’s done, and that something might as well be to turn on the scene you want if you disrupted it for the dog.

Wow! Again, only Double Wow!!

Now there’s even more complexity plus lack of a determinant outcome. There’s no way to know in advance just what happens during “restore”? Cool.

Try this: “Honey, I know you hoped to maintain the mood after turning off your nightlight, but the system was confused so everything came on bright.”

Exactly. What if you have multiple exceptions? Scene A interrupted by B, which is interrupted by C. But B ends before C, so it restores A. Then C ends and restores B. This can get very ugly pretty quick.c That’s why no one does it in the first place.

Exception processing is inherent to automation – including many (most?) of the existing SmartApps and Hello Home Actions, even if the exception most common in SmartThings is “Mode”.

  1. Turn on the air conditioning, unless nobody is home or if a “peak power” alert is active.
  2. Turn on the nightlights, unless Mode is vacation.

Your multiple-exceptions example is a strawman. The user can have as few as zero exceptions or as many exceptions as they can reasonably comprehend. The SmartThings App engine is a general purpose compute engine and should be able to handle arbitrarily complex logic. The user interface can put reasonable restrictions on this logic … at the moment, it is parameter driven and that is limited and confusing (e.g.: For many SmartApps, I can have it send a push notification OR a text message, but not BOTH – the underlying app engine can do both, but most SmartApps are not programmed to handle the and/or situation of two parameters).

Similarly, why should I have to set all light bulbs in a list of selections to the SAME dimmer level? This is a UI limitation, not an app engine limitation. Is it confusing to design the UI to have a dimmer level for each lamp? Is it less confusing to save the current settings of a list of lamps as a Scene that can be named and recalled as desired? Is save/restore an option that would be useful to some SmartApp developers?

Time for some spinoff topics? This one seems relevant:

…CP.

1 Like

I did not imply that at all. The logic is deterministic: If Mode is unchanged, then Restore will reset the State of the affected devices to the State they were in at the time the last Save command was executed. If Mode is changed, the Restore command will reset the affected devices to their DEFAULT State for the defined Mode. If no default State is defined for the Mode, then the devices will reset to the default State for their Type.

I’m not arguing that there is no complexity here – I’m asserting that the complexity become “well defined” after sufficient discussion and detailed specification writing, resulting in deterministic and predictive behavior that developers can understand and decide how to expose to the User Interface (if at all).

I do not claim that a forum thread is the appropriate venue to develop or document these specifications.

1 Like

Shoulda… coulda… woulda… Right now I’d be happy if the smart apps could keep a simple time schedule. Arbitrary complex logic my @$$. :smile:

1 Like

You don’t have to set them all to the SAME dimmer level! There are multiple ways to do this: How about, for example, more than one Hello Home action that fires at the same time, each setting some dimmers to a different level? Or, a SmartApp that memorized a scene being fired from a Hello Home action? Or, etc. etc. If you are obsessed with Restore, maybe it blinds you to other ways to do what you want to accomplish.

I already agree that there are multiple ways to accomplish the functionality.

Nothing would force you or any user or developer to use Scenes (and, if available, save / restore).

But the requirement to use of multiple Hello Home Actions just to manage multiple lamps at different dimmer levels at the same time, is just very inefficient automation from a UI perspective.

The ability to “call” Scenes saved by another App is currently not possible without the use of virtual buttons, which is a layer of UI complexity that is also just an effective, though inefficient workaround that posters here have said is excessively complex.

Anyhow: I’m going to agree to disagree with you at this point. I don’t have the tenacity to continue this response thread.

Thanks.

1 Like

I figured out another way to do scenes: modify the Button Controller SmartApp (which I call Scene Controller). I use MiniMotes in four rooms, 5 remotes in all. The mods I made are to add turning on, turning off, and dimming (2 levels) groups of any switches/dimmers. There are 8 scenes available per MiniMote. Each scene can also change the Mode and run an Hello Home action. Momentary Button Tile devices can be linked to the app to activate any of the 8 scenes from the Dashboard. If you don’t want to use a MiniMote, the app can just define scenes for you that you activate with Momentary Button Tile devices.

Another way to think of this app is that it creates macros. There are a set of actions to be taken all in response to touching the button for the macro. To put a handle on the macro we use a Momentary Button Tile device, or a MiniMote, linked to the app. Push the button, the macro runs. Macro = Scene

1 Like

I’m doing something very similar - it makes a lot of sense to me. The only downside is you need 1 app per scene but I only have 5 scenes or so so far so no big deal.

When I get some time I’d like to build something a bit more robust that allows per light dimming, and colors. Ultimately, a scene should be able to change anything SmartThings knows about into a predetermined state, but using this approach it would take brute force coding to add all of this - it would be very nice (as has been discussed elsewhere) if a Scene was a first class object that handled all of the complexity for you and could just be activated either programatically, or by a virtual switch or remote.

For now though this works for me as I am concerned mainly with lighting.

1 Like

Just for the reference, Wink has very simple and elegant Scene API:
http://docs.wink.apiary.io/#scene

The API allows creating/updating/deleting and activating a scene. Could not be more straightforward than that. It’s not a rocket science.

1 Like

For my very simple scenarios, the Aeon Minimote (2nd generation) with Button Controller just works fine but do understand that it is totally dependent on the ST hub being online.

YAAAASSS! (and ditto to @aimc).

Coming in late here, but I’m seeing some confusion between scenes, limited option scenes, and scene recorders. So maybe this will help.

In most automation standards, including factory installations, the definition of “scene” is dead simple: a series of actions from multiple end devices that take place because of one command.

The UI definition is the ability to associate actions for different individual devices to the same trigger using any of the parameters normally available for each device.

So with a full scene you can tell a thermostat to do whatever you would tell it to do individually at about the same time that you tell Lamp A to do whatever you would tell it to do individually at about the same time you tell Lamp B to do whatever you would tell it to do individually (which might be different from what you’re going to tell Lamp A) at about the same time that you tell your music system to do whatever you would tell it to do individually. You have access to all the possible parameters for each individual device.

A limited option scene is one which limits the actions, parameters, triggers, or the end devices the user can choose to add to the scene. So maybe the user can only set the parameters for lights, but not the thermostat or the alarm system. Or maybe the lights can only be treated as a group, not set individually.

Routines (formerly called Hello home actions) are limited option scenes. They don’t allow the user to set all the parameters for each individual end device. (Dim is the obvious example.) But they do allow the user to define actions for multiple devices that will all be done at about the same time.

SECONDARY CONTROLLERS

Scenes tend to create their own traffic jams, because you’re sending out a bunch of action requests at about the same time. This can create lag or lost signals, which tends to defeat the whole purpose of a scene, because it quite commonly means one or more end devices won’t get their request when the others do.

The usual way around this has been to rely on secondary controllers in close proximity to the specific end devices you want to control, especially lights. (People hate standing in the dark waiting for the lights to come on.) A local secondary controller will have less lag, less drop out, and may even use a different technology than the primary. So far, so good.

The problem is that scenes by definition are multiples of the usual action requests, and they have to be able to handle all the parameters for any allowable end device. Which means it takes a lot of memory to be able to handle the worst case scene allowed in the installation, and even in more typical instances uses a lot more memory than just issuing one action request to one end device. So many secondary controllers limit the total number of scenes they can handle to a pretty small number, usually 4 to 8.

Another option is to limit the types of scenes a secondary controller can handle to ones with a small parameter set, typically lighting.

Anyway, secondary controllers are good because they increase the likelihood that user perception will be that everything happens “at once,” and they reduce the drag on the network overall, but they are often much more limited than the hub itself.

TRIGGERS

In some standards, only specific types of events can start a scene, typically a button/tile press or a specific time/date schedule. In other standards, including zwave, any controller-recognized event can trigger a scene. So a smoke detector going off or a motion detector or a door unlocking can trigger a set of actions by other end devices.

In a multiplatform installation like SmartThings, this difference in capability may greatly complicate scene implementation. In addition, some devices send their state change to the controller while others have to be polled.

SCHEDULES

Not all protocols implement schedules, but these days most do. Schedules are a control layer that takes precedence over event triggers. So you could have a motion detector trigger one scene on Mondays and a different scene on Saturdays. Or have a set of scenes that only run on Halloween or after sunset or the 4th of July.

If scenes run great in an installation before schedules are implemented, then schedules tend to be the area with the greatest potention for user error. It’s even worse if multiple users have control center access to modify schedules. Basically people set up something that will never run, or runs at the wrong times, because they only think about one schedule at a time and not how they’ll overlap. (Like Halloween on a Saturday.)

So it’s not unusual to see UIs that offer limited option schedules to most users, just to keep them from hurting themselves. Only the primary user can do full schedule parameters. Many alarm companies work this way–the home owner can’t create overlapping schedules without master access.

END DEVICE AWARENESS

Note that end devices usually have no idea what schedule is in operation. And in many protocols the end device has no idea what scene is in operation. Or what trigger started it. All they do is initiate the action the controller asked them to do when the controller asked them to do it.

MANUALLY SETTING UP A SCENE THROUGH THE UI

To manually set up a scene, the UI collects information from the user about what trigger should initiate what actions from what devices using what parameters for each device.

To manually set up a limited option scene, everything is the same except that the UI only allows the user access to a subset of triggers or actions or devices or parameters.

Some UIs include the schedule for the scene in the initial scene set up. Others have the user create the scene first, then offer a separate scheduler panel to schedule it.

Users get more flexibility with the separate scheduler option because they can use the same named scene on different schedules. But there are usability arguments both ways. Again, it’s usually the schedule where users trip themselves up.

Vera has a typical zwave installation UI for scenes with a schedule embedded in each scene. Note that you have full granularity to set each action’s parameters for each separate device.

SCENE RECORDERS

Manually setting up the parameters for every end device can get pretty tedious. So some installations do offer scene recorders. You get everything (typically lights) set just the way you want, then you “record” the scene so you can use it in the UI and associate it with triggers and schedules.

Scene recorders, unlike scenes themselves, require that each individual end device be able to report its state, OR that you can check the controller logs to see what the most recent command sent to each end device was.

This is where things get very tricky. Maybe the desired scene is really the result of multiple actions done over multiple days. Maybe the most recent command for a particular end device was to join the network, because the factory preset levels were just what you wanted. Maybe one or more end devices were set using manual or nonnetworked switches. So the truth is checking the command logs tends to be fraught with problems.

Absent that, though, the scene recorder has to be able to poll every end device as to its current state for whatever parameters you want the scene to include. Including secondary controllers who might need to have a scene tell them what state the end devices that it controls are in.

Any end device, like many motion detectors, that has an interval control may need the scene to be able to set the interval control to right where it was at the time of recording, or later initiation of the scene may go haywire. Scenes that include motion detectors typically “break” because the motion detector doesn’t know it’s supposed to have been triggered at the start of the scene.

Networked door locks are another potential area which tend to break scene recorders, because many of them have their own interval management.

Then there’s the whole issue of schedulers. Suppose the current setup will only work under specific schedules. Is the scene recorder going to know that? Be able to capture it? Be able to reinitiate it correctly?

Anyway, scene recorders are great if you can make them work, but with the exception of lighting-only installations, they’re pretty uncommon.

GROUPS

If a protocol allows for groups, then scenes can use them to do a number of things, including reduce network traffic and simplify manual scene definition. But the use of groups is separate from the base concept of scenes. Typically groups associate devices with each other while scenes associate action requests with each other.

You do run into some of the same user error problems as with schedules, though. Users manually setting up a scene may try to send one action request to a group and a conflicting action request to one individual end device that’s in that group, and things get messy. From a usability standpoint, if a group is being included in a scene, then the UI should probably prevent an action being defined for an end device that’s included in that group. The user may get annoyed, but at least the ultimate scene will work the way they expect it to. You can argue that both ways, though.

There’s also the issue of an end device that has its own actions in an existing scene and later gets added to a group. Or was previously controlled by a group and then removed and assigned to a different group and now the pre-existing scenes “don’t work.” So groups do complicate scene management over time.

Also, scene recorders run into some real problems with groups, especially if the entire installation depends on the use of groups to reduce network traffic. If you’re depending on end device polling to capture states for a scene recorder, you’ll lose all the group information. Which may mean scenes created through a scene recorder become, from a user’s point of view, very tedious to tweak since the devices are being issued commands individually rather than in groups. And the scene will also generate much more network traffic than a manually created scene that used groups.

BACK TO THE ORIGINAL QUESTION

So, does ST have scenes? It has limited option scenes, called Routines, which do allow the user to define a single command that will cause actions to occur on multiple devices at approximately the same time with some scheduling abilities built in.

However, it does not have full scenes which would allow a master user to set every parameter for any action on any individual end device.

And so far it only lists one secondary controller, the Aeon minimote, which does not require custom coding–and it’s only able to trigger the limited option scenes available through the regular UI.

Other secondary controllers will likely need custom coding and may still not offer full scene functionality.

I think scene recorders are a great idea, but I think for discussion purposes it will be helpful to separate the requirement for full scene implementation through manual scene set up from scene recorder requirements, as I think you’ll find they’re quite different with different issues to solve.

3 Likes

Hi JD!
Thanks for your input and the tremendously informative post and definitions!

IMHO, as you can tell from my earlier posts in this Topic thread, “Full Scenes” (to varying degrees of fullness (excuse the oxymoron)), should be a fundamental part of the SmartThings platform, not only because of the basic “power” of this function, but also because I think it is an intuitive Home Automation expectation, especially for lighting systems (Lutron, Insteon, …), and is explicitly present in other HA systems.

The Community, however, cannot successfully prescribe the individual priorities and road-map of SmartThings – the platform is complex and going through a major overhaul in a few areas, the most visible being the SmartHub V2. Our feedback and suggestions here are heard and considered, but from the Developer Office Hours open conference calls, and other posts from their engineers, I can make a pretty good guess as to what issues and features are pulling attention and resources.

I’m confident, though, that a custom SmartApp(s) and likely some “Virtual” SmartDevice Types, we can implement something much closer to “Full Scenes”, and overcome the “Limited Option Scenes” implied by Hello Home Actions.

Some of my peers may disagree … although I think we partially agree on many of the parts of the “definition”:

Fact is, there are many ways to solve the problem, but, personally, I would like to focus on the value of following that “intuitive” need and definition. In other words, I would like to implement Scenes as closely to the definitions you have provided as possible.


We can clarify and discuss here, spin off a focused Topic with practical implementation as the goal, and/or Private Message or offline email.


Next, just a small point… you state:

Please note that there is at least one other working controller (with 7-Buttons), and discussion for scene or action actuator keypads (especially traditional in-wall ones) is popular.

Thanks again,
…CP / Terry.

This can be done with a SmartApp that presents the user with the list of Devices and then, on further Dynamic Pages, provides inputs to set every applicable (every supported SmartThings) parameter.

I’m willing to write this SmartApp (and there are some variations already bouncing around the Community), but I am discouraged a bit by the discussion above that claims this functionality is not required or desired. Encourage me?


[Emphasis mine.] – I agree … Groups are a good thing, but are a “distinct” concept especially from a Platform architecture perspective. Native protocol Groups are an especially onerous impact.

I think it would be beneficial to separate the work on Groups from Scenes, and prefer that we focus on Scenes first.

I, of course, remain unconvinced about scenes being missing or needed in some new way in ST. I do think that ST has a complete scene capability, and can meet the above stated definition. Of course, this is only possible with SmartApps of some sort, and I would grant that the current UI is sorely lacking for people looking for “scenes”. Hello Home actions are merely simple SmartApps with a special UI in the mobile app. For me the issue boils down to defining a scene and the mechanism chosen to invoke a scene, both of which are quite tractable in ST.

1 Like

I’m not technical enough to understand everything in this thread but it does have me worried.
One thing I would like to accomplish would be to press a button (Aeotec minimote) that would turn on lights (10-30% dim) in the hallway and nursery to light the way at night. This would be the “fussy baby” button that would help build some major WAF points.