In my mind’s eye, that is the advantage of Hue and GE Link… simultaneous WAN and LAN control.
1 Like
But isn’t “hello home” mutually exclusive? For example you can only be home OR away, but not both.
For scenes you may need to have more than one run at once. In addition, it seems you need some stack type logic where you push and pop scenes on and off a stack.
Granted, managing states with a stack type logic may be outside the initial need for scenes. However, it seems state management will be needed for any sophisticated home automation. Scene management seems like a natural first step.
Close, but not quite. Scenes should be “first class” objects, so they can be easily added to apps just like other devices. Currently HH actions require “special treatment” with respect how they are added to the app and how they are invoked. Also, invoking actions from the mobile app requires additional steps and is inconsistent with performing other actions.
1 Like
Defining a scene could have an app like “hello home” as a way to set it up, but scene/state logic seems to be needed at the code level. I haven’t dug into groovy to describe where, but it basically needs a simple way to save state of specified devices and apply this saved state.
Most of what you have on the Internet is stateless so I can see how this has failed to take hold at SmartThings.
I’ll go out on the ledge and predict that the home automation system that creates a functional scene and state management will ultimately win out in this space. Months ago, I stated SmartThings had everything in place to dominate home automation regardless if it moves to a hubless architecture. Now I tend to think this missing piece may open a wedge for someone else (Nest?).
Don’t confuse Hello Home actions with modes. Modes are mutually exclusive, but Hello Home actions can run in any mode from any number of triggers. Personally, I think there is a tendency to over-think scenes and then over-engineer solutions for them. I understand the concept that Wackware is describing where specific settings are memorized as a “scene”. I messed around with Wackware’s app that does this, and discovered that I was setting the dimmers for a scene at only one of a small number of settings, and that very rough justice in this works fine. Thinking that simple is better, I moved from that approach to one where I just use an app to set more than one dimmer level for groups of dimmers. Using this approach, I never found a need for more than two different levels for any one scene (my app originally had three different possible levels). So rather than capturing and remembering some levels, I just set them when the app is installed. I make use of modes to select variations of a scene (e.g. bright during the day, mid-dim during the evening, and very dim at night). This approach is quite simple.
The issue for me about scenes boils down to how one invokes a scene. The method I don’t use is the ST app on my iPhone or iPad. My scenes are triggered instead by some combination of (1) motion detectors, (2) scheduled mode changes (once they start working again), Minimote remotes (I have one on my desk in my office, and my wife and I each have one on our bedside tables), and lastly, by turning on a designated dimmer or switch (these entail a slight lag due to Z-Wave propagation, now running a few seconds since the upgrade). A dedicated wall panel (a la Lutron) with buttons for several scenes would be nice, but isn’t really any better than a Minimote for most circumstances. As I’ve gone deeper into ST, it’s become clear to me that the whole concept of light switches near the entry of a room is an anachronism. For example, if we are watching TV and put on a movie, and hence want the “watch a movie” scene, I don’t want to get up and go to some wall mounted device to set the scene. I want to use my remote (Harmony), and that’s now what we can do.
So I don’t see any need for “scenes” to be some new major addition to the ST system at all, and I certainly don’t think you need to stack and unstack scenes – that’s way overthinking the problem. Start by figuring out how you want to invoke a scene, and work backwards to how you set that up. Having lived for years with scenes in a Vantage controlled house I know that scenes tend to be quite static – that is, once you have them set, they rarely change. And the key variable is how they are invoked.
I’m guilty of this. However, discussion of scenes got me thinking of states.
I was with Ben that scenes are just a different way to do what you already can do with SmartThings. And I agree with him that just because that is how other home control and automation systems did it does not necessarily mean it is the best in SmartThings.
However, beyond scenes, there is a need to manage states. The alarm case I cite is one among many others. A scene is basically a state of devices. Once you can save and recall scenes (states), the next step is to manage them. Thus, providing scenes gets you to the next stage of managing states.
If we agree there needs to be state management, then why not provide scenes and you are one step closer.
Sorry for overthinking this as I should really spin this state discussion to a different thread.
1 Like
As @bravenel said, “Hello Home” items are not mutually exclusive. You can set them up to additive or inclusive as they just apps themselves that can run a script of actions.
Modes are not exclusive either. They are just logically used in a different manner. An example is that I can have several modes; “Todd’s Home”, “Wife’s Home”, “EveryOne’s Home” and Nobody’s Home". Now the ST user interface usually makes you pick “all” or one of them to use as a filter for triggering apps, I can in code use several modes to filter on at the same time.
Example pseudo
App #1 - Music in Room 1
If motion in room 1 and nobody’s home then play dog barking
else if motion in room 1 and everybody’s home then play Al Green
else play dubstep
App #2 - Lights in Room 1
If motion in room 1 and nobody’s home then lights full bright
else lights dim 50%
You can see above that the actions/apps will run using inclusive modes logic.
I don’t think of any of this as a scene or mode. In even simpler terms: “I want to tap one button and have everything goto or do whet I want”. An IFTTTTTT. If this, then do that, and that, and that…
Tap button, then
Disco ball drops
Bar rises from dresser
Bed comes out of wall
Al Green starts playing
Ya, it’s got me thinking about states also. In one sense, Mode is a state, or at least ST treats it like a state. It is a very powerful concept, and I think ST has it right. But it’s not enough. I’d like some global state capability. I suspect this is fraught with software problems, such as garbage collection et al. In the meantime, I’ve used virtual devices as global state holders, and have to do my own garbage collection (as in when the app has changed and I don’t need the virtual device anymore). For the most part, anytime I find myself thinking I need global state for something, then I think I must not be thinking about it right, yet.
There’s so much to be said for simplicity as a primary virtue… Having said that, there’s even more to be said for people who code remarkable non-simple things, like ActiON and Smart Alarm.
Ah, but you shouldn’t have to tap the button. Some yet to be developed sensor detects 2 warm bodies, pheromones, etc, then the Disco ball drops and bed comes out. Too geeky to have to grope for the button when there are more compelling things to grope.
Inclusive modes are cool.
It’s ok to challenge status quo if you can offer a better solution. Unfortunately, that is not the case here. What @ben is saying is “we don’t get scenes or cannot implement them within constrains of our architecture, so we’ll pretend they don’t exist and see if we can get away with it”. At least this is what it sounds like to me. 
BTW, it’s the same refrain being repeated about the “if-then” rules.
Scenes are a user interface issue, not a platform issue. ST implements scenes beyond anything imagined before! But, there isn’t a good UI for scenes, YET. Just like @625alex did with ActiON, a great UI is possible for scene creation also. Nobody has done it yet, but it is certainly doable.
What is the “definition” of a scene? How is it different from Hello, Home actions?
Please enlighten us. Where’s a scene object in the SmartThings API?
What is the “definition” of a scene?
I think that question is causing a lot of confusion. When I started this thread, I probably shouldn’t even have used the word “scenes.” I should have just asked for what I was looking for and for what my vision of scenes is: macros.
All I’m asking for is a simple macro. I want to be able to have a bunch of things happen in precisely the way I want them to happen. That might be just lights, or it might be every single connected device in my home. But that’s the entire point of home automation and why the promise of SmartThings was so appealing to me. I loved that ST proposed to tie together more connected devices than other platforms, but I would have had to sacrifice too much for it.
The fact is, the ability to simply tell a bunch of lights to turn on to the exact levels I want them to should be a bare minimum requirement for any home automation platform I’m using. That was the entire reason I got into home automation to begin with: I hated having a single bright light in the corner of a room, and I hated having all the lights turned on to their brightest setting. I wanted even lighting for a variety of settings.
This shouldn’t be a difficult thing, and installing apps on ST is, I’m sorry to say, a difficult thing. It took me forever to figure out how to do it, and I consider myself an experienced IT person. This should be baked into the platform and it honestly shouldn’t be much of a challenge or any sort of difficult thing to figure out. All I’m looking for is a macro.
1 Like
I’m obviously missing something, or we are just talking past each other. What do you need a scene object for? What would you do with such an object? In a Lutron system, a scene is nothing more than some preset dim levels for a preset selection of loads, triggered by pressing a button tied to that scene (or some other trigger such as motion). The only thing one can do with a scene is “turn it on”, and maybe “turn it off”. That’s it.
That very basic functionality is straight forward to do in ST, although there is no decent UI to set it up. I could write a little chart by hand that described a scene, with a list of loads, their corresponding levels to be set, and some triggering device or event. I’m not adept enough at coding in Groovy to put that chart into a UI, but it isn’t difficult to get that functionality through more crude and awkward means.
So I certainly can relate to someone coming into ST wanting to do this most basic of lighting control tasks in a straight forward way, and being stumped by the evident absence of a simple means to set it up. ST certainly is remiss in not creating a simple UI to define scenes. That’s why I say it is a UI problem, and not a platform problem. I have “scenes” all over my house using ST, and for the most part they work pretty much the way a Lutron system does (but for the running off to the cloud bit). These scenes are triggered by light switches, motion sensors, Hello Home phrases, etc.
A computer science professor I had once said, “Being flexible is a good thing, but have you ever tried to sit on a flexible chair?” ST is certainly a flexible system. But its usefulness as a chair is in serious doubt these days.
Behind every UI button or a function however small or insignificant it may seem, there’s an object or an API. Yes, a “scene” can be a very simple object with just a few methods - “add device”, “remove device” and “activate”. But it still has to be there. You said that it’s just a “user interface issue” and what I’m saying is that it’s a design flaw in SmartThings API. “Hello Home” is a workaround that essentially uses smart apps to emulate scenes. But it’s a canned app that cannot be extended or modified. Try starting audio playback (e.g. Sonos) or changing Hue color from the Hello Home action.
1 Like
OK, having a scene object is one way this could be done. But obviously there are other ways to do it, as I am doing it left and right without such an object. Touching a SmartApp is one way to “add device” or “remove device”, in fact an easy way. That same app carries the dim level settings, so those are easy to adjust also. “Activate” is a whole other thing, and I have scenes being activated by numerous methods.
FWIW, I just spent 5 minutes getting Hello Home to start/stop Sonos playback. You are correct that it’s a canned app, but it can be extended by using a virtual device as the mechanism. Hello Home turns on my virtual switch, that Sonos Control has subscribed to, so Hello Home can control Sonos. Etc etc…
I will be the first to admit that this is less than obvious, even though it is pretty simple to do. I can’t tell if the API has a serious design flaw, it very well could. But “scenes” work, just not in the most obvious way.
My opinion is to compromise:
There are two types of “scenes”:
- An “permanent” Scene which “takes over” the list of Things and sets them to the scene’s State. There is in no undo, reset, or protection from other events that change Things after the Scene is activated. This is a common and useful scenario, of course. Activate a “movie watching” Scene that dims the lights, turns on the projector, lowers the screen. After the movie, you might activate a “romantic scene” that raises the screen, shuts off the projector, turns on music, shuts off some lights, turns on candles.
- A “temporary” Scene which first saves the states of all the Things in its list so that that statecan be restored with an exit/off command. This probably lends itself to a stack structure, such that temporary scene are pushed unto the stack and are popped off at restore time. To me, this handles two types of scenarios: (a) Go back to normal: After setting all the lights and lowering the screen, etc., for a movie, the obvious thing to do after the movie (before the user optionally decides to activate some other scene) is to FIRST restore the environment to pre-movie settings (screen up, lights could have been brighter or or maybe they were actually OFF, etc.)., and (b) interrupt mode: Some lights in and around the house are dimly lit for a nice atmosphere and as nightlights; but when an alarm is tripped (motion sensors, door sensors), then bring a set of lights temporarily up to full brightness to scare away intruder; after a few moments, run “restore” … again, this would automatically restore to the last state for the list of Things. But yes – this is a more complex situation: What if “Daytime” mode activated while the Temporary Scene was still active? Meh… I’m sure we can come up with reasonable behaviors. Perhaps conflicting changes to a Temporary Scene have to be queued up to execute after the Temporary Scene has exitted.
To avoid confusion, it would be good to have distinctive terminology for these two types of scenes. Instead of “Temporary Scene” is it an “Action State”?
Dunno: Best I can think of are “Permanent Scene” and “Temporary Scene”.
Frankly, I have very list use for “Permanent Scenes”, since activation of a new Scene can always be done “immediately” after the exit/restore action from the previous Temporary Scene. But I love the discussion.
Macro = Put a set of Things into a State.
A set of Things in a certain State = Scene.
Finally: Undo Macro = Restore State which was saved by Scene Activation.
(mic drop)
1 Like
And what I want is once I have created a scene, I should be able to use it from any smart app the same way I can use any switch. It’s not currently possible with Hello Home actions, unless the app is specifically written to enable them. Using “virtual switch” to invoke actions is a horrible hack that just shows how little thought was put into scenes at the design phase. Has to agree with a flexible chair metaphor.