Leading on from the Developer Call (21st Oct)
I would like to know other peoples thoughts / use cases / ideas etc on the subject of Room Modes . . .
It was mentioned by myself and @jody.albritton in the developer call and seemed to go down very well in concept.
@jody.albritton - Your use-case from the Dev call was a perfect example and a much more indepth version of what id outlined it for also, well worth sharing to show people the scope of this… 
If we were to treat rooms as objects it might allow developers to extend and add this features without heavily modifying the app.
There are three rooms in which to watch TV. Having one “TV Time” mode for the whole house does not make sense for me. I would need 3 watch TV modes to disable my lighting automations for each room, and multiple routines to switch in and out of the TV Time for each. Then there would be the conflict of only one room could ever be in TV Time at once.
It would make more sense if each room could have a mode. Routines could remain the same, but the house would have a mode.
In the drop down list for mode selection it could look like this
Home
Away
Room 1 - Watch TV
Room 1 - Normal
Room 2 - Normal
Room 2 - Watch TV’
Room 3 - ETC
Modes would only need to be a new attribute to the room object for this functionality.
And me! 
Post must be 20 characters.
^ This.
Why has the mode / scenes / routines discussion started up again? I’m not against any added functionality, but since SmartThings hasn’t even commented on the “Suggested New Capability Types” Category on the Forum (it’s abandoned), what makes folks think they’ll take our suggestions for new first-class objected and global variables (and similar)?
I don’t want to be in multiple modes. I don’t want to force everyone in my house to be in the same mode as I am. People are not robots and schedules change. My house is a living-breathing thing. What I propose would be optional. If one mode at a time works for you, fine; artificial limits serve no one.
This was also discussed last night and @yaimavaldivia has committed to working on it.
Absolutely, choice is good. I’m all in favor of power users having as many different state variables as they want. 
Remember I’m the one who put a fan in a box to trigger a motion sensor and bridge two unconnected control systems. If it works (and it’s not a fire hazard), I like it. 
That’s great news! Thanks! 
I have a post in that Category with a draft/suggested process. See y’all there.
@tgauchat worth joining them developer calls when you have needs / questions like that pal - theyd be answered in seconds on there as a pose to months on here 
And this was brought up in a conversation about changes developers would like to see in the system that would benefit the masses not a narrow group and we all fealt this made sense as a next step for the mode implementation (not meaning now or soon but eventually)
The idea of having Room Modes/Scenes for a smarthome is Smart, but ive always said/thought that One Mode for a whole house isnt a solution, its just simply on the path to being one . . .
It makes little to no sense why one user should be able to, or more so HAVE TO dictate a whole homes mode (for example someone wanting to sleep or watch tv etc) when other users may still be awake in other rooms or want to listen to music / cook etc but in other rooms . . .
I believe you should be able to create as many scenes/modes for a room as possible and also assign the editing/creation of these modes to specific or groups of users (once thats fixed) for instance teenagers can add modes/scenes to there bedroom but no other rooms (with permissions from admin user) as its there own personal space.
Then the home as a whole should have a master mode . . . For example when the first person wakes it sets it to morning mode whoch way affect the whole homes heating state and disarm certain alarm functions . . . if everyone leaves The home it then sets to away/arm . . . If its late and everyone’s home it sets to evening mode . . . and if every rooms seems to be in asleep mode then its sets to arm/stay mode Etc
This way the homes mode is more specific to the security / monitoring / state of the actual home
And room modes are more specific to the users within that rooms current activity and customisation of lighting and entertainment etc etc
It will then get very interesying when you can make rules dependant on multiple zones . . . For example:
Limit the Sonos in “Jacks Bedroom” to volume 30 IF “jennys bedroom” is in sleep mode or the time is after 9pm
if doorbell rings and “jacks bedroom” is in tv mode but jenny and phil are home, then please notify every other room except jack as to not disturb his film.
The idea of Room Modes/Scenes makes total sense to me. Before buying SmartThings I had started developing my own Home Automation system and my initial concept involved having Scenes per container (Room/Zone). I hope this gets implemented… having said that, there are so many other things that need doing sooner rather than later.
Just wanted to mention a use case came up in the forums that would be intuitive to pretty much everybody: somebody who has a M I L suite they rent out over Airbnb. They want it to have its own mode and its own SHM alarm status.
For that matter, anybody with a live-in parent, Attendant, boomerang kid, even Housemate if you have separate entrances.
So, as always, Choice is good. It makes total sense that an MIL suite might be in a completely separate mode from the Main house even though there was only one hub.
For now, in the forum, I’ve suggested the questioner consider getting a separate hub for the Airbnb suite and just run two locations. But long-term, zone modes would map very well to homes with physically distinct separate areas with different residents. As well as the previous examples given.
any progress on this, or workaround tracking via triggers/virtual devices?
Yeah, the overly complicated ways of using virtual this and virtual that seems to be the only way to get certain things done in ST. Nested modes and Rooms with attributes should’ve existed long ago.
sigh Imagine, Rooms as objects with attributes. It makes me wonder how a team with such limited scope can’t achieve in 2 years what the Alexa team managed in a few dev cycles after the need was shown.
It would’ve been nice to see rooms as actual things instead of simply dumb groups. I guess now I just have to be happy with Alexa being able to “turn off the lights in the living room” while ST can only turn off Living Room Lights.
Amazon has 5000 employees dedicated to Alexa / Echo.
SmartThings has fewer than 500 employees (but growing: I definitely think Samsung is “ramping it up”).
But then again; ActionTiles has only 2 people doing everything. Or trying to. 
Oh, I definitely understand the resource disparity, but the ST team only has to do ONE thing right (unless there are some hardware changes in the near-term pipeline).
The Echo and Alexa teams are focused on being everything to everyone with the least amount of on-boarding friction as possible. The fact that they even bothered to lay the foundation for room-based context is actually pretty amazing and forward-thinking.
On the other hand, the ST team has given us a UI overhaul and tighter Wifi integration in the same amount of time that Alexa has gone from telling jokes to multi-room audio, routines and understanding room-based context.
I know some think a OO hierarchy might be overkill or too complex, but I really don’t see rooms having properties (modes, lights, etc), children (devices), and actions (routines) being a horrible thing.
Honestly, I’m still kind of having issues with ST only having top-level modes instead of at least a layer of sub-modes. I hate having to go to the IDE to create this whole combination of possible modes to have it make sense.
I am now farming out things to Alexa and webCoRE that I wished ST at least attempted to handle.
Also, a CEO once said to me (in reference to startups) that being a smaller organization allows for great momentum via velocity (rapid iterations, feature dev, etc). Higher velocity is possible due to less friction (approvals, institutional hurdles, etc) and less mass (org/team size).
Small teams should be able to move faster than giants. That’s how they’re able to disrupt and keep the big guys on their toes.
But, of course, I’m completely ignoring the giant that is Samsung and the rollout of the competing products/services that probably stunted ST as a stand-alone.
I think it would be the opposite of “horrible” to us developers & power users, but that’s not SmartThings’s consumer focus.
The new cloud API will technically make it cleaner for 3rd party developers to add abstraction / objectification layers in their own intermediary clouds and apps. It’s not clear yet how SmartThings intends to divide processing between its own cloud and external. The new API, for example, allows addressing and controlling all authorized Things of the same Capability with a single command. This implies they could “easily” create other relationships between Things!
Honestly, I can’t wait to see what they deliver. I completely understand that impossible balance between flexibility, ease of use and power.
I am eagerly looking forward to what ARTIK brings to the table for us, but I’m guessing that it’s simply centralized backend services and single-point integration without additional functionality. But, that’s a bit of consumer cynicism.
ARTIK is just hardware. It used to have its own cloud (just for the convenience of ARTIK developers), but now that is to be replaced with the “SmartThings IoT Cloud”. [I keep adding “IoT” in there to not confuse it with the _old_ SmartThings Cloud].
LOL…right, those differentiating buzzwords help keep us up-to-date.
Ahhh, so I thought ARTIK went beyond the modules to actually provide high-level integration and services APIs with their cloud. Thanks for clearing that up. The wealth of knowledge found in this community still amazes me. 