This may sound like a good idea, but in reality the scenes you push on slack will most likely become irrelevant by the time you start popping them back. It may have been daylight when you started watching a movie but it’s dark when you finished it for example. Now you pop back a scene that had all your lights turned off. I bet this is not what you expect.
1 Like
But wait! (Why am I replying to my own post… dunno. I guess I want to show a stream of thought…).
What about “stateless actions” (e.g., Play a message on Sonos … sure, there are states related to this, even a very short temporary state of “message currently playing”), but…
Nearly every “system” has two fundamental concepts: Data and Process … and these can be called by various aliases.
Let’s call them “States” and “Events”. NB: An Event can be triggered by an real-world action (button press, sensor detection) or an abstract construct or process chain (scheduled time reached, if this then that).
SmartThings has both of these concepts, but does not present or expose them consistently or comprehensively:
Mode is obviously a “State”. So is On or Off for a switch, Color for a HUE, Level for a dimmer, Open or Closed for a door contact, and Active or Inactive for a motion or activity sensor. And so on.
Hello Home Actions are “processes that cause Events to occur”.
An “Event” is any change in State or executions of processes. A process can be initiated by an Action, by another Event, by a SmartApp, by a Timer, etc. Some processes cause true State changes, others do not.
So what’s missing: Well, as @wackware points out, it seems that a Hello Home ™ Action could be used to set the State of a bunch of Things (as wells as do non-State-changing stuff).
Since a Scene = the State of a bunch of Things, then, Hello Home Action => Scene.
All good. Except: I really still want the ability to SAVE / RESTORE the State of a set of Things; in other words, the ability to UNDO a Hello Home Action. This is very very important to me. If this Undo / Restore functionality can be extra-Smart and use come conditional process based on Mode and default States, etc., then I’m headed to fantasy island.
And, if Hello Home Actions are globally available like sub-routines, then that makes them into the universal “Scene” concept I’m looking for.). Are they?
Finally: A wizard that automatically creates a Hello Home Action based on capturing the current State of a list of Things, is the ultimate Scene Creator (ideally with an editor to tweak the values to be set in the Hello Home Action). But since Scene is a special-case (a simplified case…) of a Hello Home Action, I still think SmartThings could provide the functionality as two concepts, with the overlap being acceptable for flexibility.
I totally agree, @geko. There certainly is some complexity that has to be considered.
So we end up with some sort of conditional restore, with lots of good or bad ways to implement.
One possibility that comes to mind is that a saved Scene-State is only valid to be restored if the Mode is unchanged. If the Mode is changed, then, exit-Scene has to restore some sort of default State defined for each Mode.
As you know, Mode conditionality is already an option in the Hello Home Actions interface, so Mode based conditionality for State activate (or restore) does fit the current SmartThings model.
That’s the kind of a “flexible chair” your professor was referring to. In other words it’s a hack. It may have taken you 5 minutes to do it, but try to explaint to your [insert your favorite older relative here] 
It may be a “horrible hack”, but heck, it works. And, it gives you what you want, namely, a way to invoke a scene from anywhere, since to invoke it you use a switch. You can use a real switch instead of a virtual one, and I do that in some rooms where there were several dimmers that had to be turned on to light the room. That method introduces some lag due to Z-Wave, but is useful anyway. It was actually @wackware that got me started on this method, as he used a virtual dimmer in his scene maker app. His method was pretty cool, as you just set the room the way you want for the “scene”, then update the app and it captures all of the settings, to be used later when the scene is activated.
My first impression of ST when I first started was that the whole thing is somewhat of a hack. After the past week, I still have that impression. I’ve been able to get it to do what I want (when ST works), sometimes after many iterations. Not obvious, not straight forward, definitely not ready to be a consumer product, IMO. It seems that most of us on these forums are techies of one stripe or another, and have some ability to cope with this mess. But Joe Consumer would return the hub pretty quickly and try something different. It shouldn’t be this hard.
The flexible chair always collapses when you want to sit down. I find myself checking every day that my wife’s closet light comes on like it should. Now that’s HA at its best!! Not.
1 Like
The sun just set (in Arizona), and my office lights (four dimmers) dimmed from bright to an evening setting, thanks to Hello Home Good Evening, a virtual switch, and a small app that fired. From one scene to another… It works. At the end of the day that’s all I want, is for the thing to work, even if it’s a hack.
1 Like
I think we’re in agreement on this one
Man, that’ s long winding post. 
My rule of thumb is if takes more than 50 words to describe it, it’ll probably not work 
I’d settle for a simple non-preemptive scenes akin to Hello Home actions but with additional flexibility to add arbitrary devices without resorting to virtual switches and an ability to invoke them directly from the dashboard, rather than navigating to a parallel universe of Hello Home. That’s my Christmas wish, but being a naughty boy I am, I have no hope of receiving it.
@geko, What you say you want is pretty much what I’m doing, but for my use of a virtual switch here or there. Interestingly, the virtual switch is available from the dashboard, so that’s one way to activate a scene. Because I’m using an app similar to @wackware’s, I can add arbitrary devices, unlike Hello Home.
I don’t think you should be so down on virtual devices. They have their uses, both as glue within ST, and as a way to refine real devices and to give real devices more intelligence than they ordinarily have. For being a fan of them, I only have a handful, mostly used in MiniMote fan controls (no pun intended).
1 Like
If I debated your response, I’d just be adding more words.
I don’t equate complexity with functionality and reliability – in fact, I believe there is an inverse relationship.
Well designed complexity in the underlying architecture is essential to both reliability and excellent user interfaces.
No offence. I was just joking…
1 Like
I would like the “macro” idea as well, just a set of macros that can run any set of conditions turn light on, turn light off, turn Hue to color, etc. It would it be like hitting play on some of the smart apps, but it would be nice if they appeared on the dashboard in a different place than things etc. I would want to specific some of them to show, and others to not show. I don’t want my SmartApp that changes my User Code for my Dock Lock to be on there, just the different macros that I would use for scenes.
I don’t feel like they need to have any idea of state initially, but it would be helpful but you might want it configurable like the Sonos smart app to continue playing after it is done and/or return volume level to the last set volume.
An easy way to hit macros that doesn’t even setting up virtual devices would be nice.
1 Like
Yet another Kickstarter home automation gateway…
I reference it here because the concept of “scenes” is inherent, as well as the fact that a designed PHYSICAL remote controller is central to the system.
They even highlight and use the terminology “state” prominently in the system description:
Droplit provides a single button on the app to turn an entire room on or off. While some other systems have a similar option, Droplit has the capability of remembering the last state that the room was in before the devices were turned off. When you turn the room back on using Droplit, all devices return to their previous state.
https://www.kickstarter.com/projects/596411405/droplit-the-simple-smart-home-solution
In other words: I think the concept of setting and returning to a scene or state is a valuable feature that other products in the HA space incorporate.
…CP (Terry).
I’m torn regarding the remote. I can see it having both a high and low WAF. High - I don’t need my smart phone, any guest can control it, etc. Low - Where’s the $#(%@!@ remote?
One thing I REALLY like is the ability to capture the state of a room to pre-program a scene. That is a much easier approach for most people. To paraphrase Ronco - Set it and recall it!
1 Like
The good news is:
- Someone ought to be able to devise and build an equally functional
remote control for SmartThings. Right now there is too much
fragmentation in the “innovative” HA marketplace. Sure: Basic
hardware is compatible, but where is the incentive to build a
specifically for “open” HA platforms – or, heck, specifically for
SmartThings if necessary. - SmartThings is fully capable of scene/state capture, as demonstrated
by the @wackware’s Scene Machine App. This forum thread is a lively
discussion with several tangents though. I believe that scenes/state
capture should a fundamental object available to the SmartThings
ecosystem (i.e., a scene is a meta object … just a special kind of
Thing, really, with possibly some optional complex features like
save/restore.
(BTW: Misplacing the remote is an issue; though an obvious feature of a “Smart & Open” HA system is that multiple alternative controllers can be in use simultaneously: phone, wall mounted screen, mini-motes, voice control, …).
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:
- (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.; (c) 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.