Thoughts on Modes


(Eckenroth) #1

I got my smartthings last night and have been playing around with new apps today. My first instinct is that modes seem to be a little awkward.  Modes are mutually exclusive, so I need to define situations individually.  This means I need a mode for all possible situations. If I wanted to track both day vs. night and home vs. away, then I need four modes “Home - Day”, “Home - Night”, “Away - Day” and “Away - Night”. This is a bit cumbersome, but it would be alright if the apps could handle running against multiple modes. Instead I am limited to All Modes or a single Mode. Example: If I want the motion detector to send an SMS message when I am not home and it detects motion, I would need it to run in “Away - Day” and “Away - Night” but not the other two states. The only way I see to make this work is to install and configure the app twice, once for each mode.

 

Wouldn’t it be simpler to either allow for multiple mode to be set at once, or allow apps to run in a multi-selection of modes rather than one? Maybe that is just a short coming of the first waves of apps, not a design flaw.

 

Also, is it just me or is one of the most simple/powerful apps missing: an app to change conditions passed on a transition from one mode to another. Example: When moving from “Home - Day” to “Home - Night” turn on these 4 outlets. I know there are a couple apps that combine the two, but I would rather decouple the two. I want to set up the mode transitions seperately from the actions the transitions trigger.

 

Any thoughts?


How do you display current Phrase?
Devices we don't have
(Mj) #2

Glad to see that I’m not the only one who was trying to figure out the modes…

I too am trying to have a certain setting for day vs. night and away and home modes. For example: if I’m away from my home (regardless of time) I want notifications when movement is detected or zones are violated. When it turns night - I want lights to come on.

When I return home at night - notification alarms are disabled, but certain lights need to remain on, while others may turn-off when I go to bed.


(Eckenroth) #3

I think I am going to start by cloning the motion detector app and seeing if I can code it to work with multiple modes. I’ve developed professionally for a long time, but I don’t know Groovy or the IDE. This seems like a good first project. If I can get it to work with virtual devices, then I will try installing it in my apps.

@MJ - I’d be happy to share the code once I get it working, if you are interested.


(Eckenroth) #4

Ok, I’m a bit of a doofus on this on. Turns out the Motion Detection app already supports multi select on the modes. So if you set of distinct modes for Away vs. at Work or At Work - Day and At Work - Night you can track them both with the same motion detection app install. All you have to do is multi-select the statuses you want.

There still isn’t an app yet allows you to have the status of devices change when you enter/exit modes. I might give that a shot as a first development effort.


(French) #5

Call me crazy, but wouldn’t simply adding the ability to enter start and end times fix the issue?  It would for me.


(Arnold) #6

Adding an end time would be great and is much needed whenever I use the “Good Night” app. The “Rise and Shine” app changes the mode to Home after I wake up, but then when I leave the room for 5 minutes, the “Good Night” app switches the mode back to “Night” since technically it is after the configured time of day. This app definitely needs an end time.


(Tom Nguyen) #7

are these modes automatically chang based on time or location?

i can’t find anywhere to allow Home - Away to auto change based on my presence or geolocation. The same with Night. Where are the sunrise sunset or end time setting?


(Eckenroth) #8

@Tom - You can install apps to do this for you. On the iPhone, the apps are to the right. Under Convience, Sunrise/Sunset will handle transitioning modes (along with turning on/off lights). There is an app that will work on a time schedule called Once a day. Bon Voyage will work based on presence detectors.


(Anders Heie) #9

I think there is a fundamental flaw with modes, which will cause all manner of hacks and workarounds until it’s fixed. The problem is that you can in fact, logically, be in multiple modes at the same time (in real life). You can be away while it’s night or day, or be at home during the night or the day. However, you can’t logically switch between these combinations using just ‘one’ active mode at a time without major hoops (currently).

The problem is that various events compete for mode changes:

  • When I return home, I can change the mode, but to night or day? It depends on the time.
  • I may want some things to happen at night while I’m away, but other things when I’m home, and yet other things if I’m having a party, and something else while I have ‘guests mode’ on while guests are visiting the house.

What I think would be a great long-term solution would be this proposal for the team:

Allow the user to create mode groups, best illustrated with for example these groups and modes:

  • Group Daytime:
    • Morning, midday, evening, night (or just day/night)
      Group Presence:
    • Home, Away, Travelling
      Group Mood:
    • Party, Romance, mellow,

Within a group, only one can be active, so combining these, you could be in any combination of these, like Night + Away + Mellow, or Morning + Home + Romance

Allow any number of groups + any number of modes in each group.

Now, this allows easy and clear switching for each group, independently of the others. Home/Away switch is easy. Daytime switching is easy.

This also would work great with apps, which could depend on any number of these, and ignore others (so keep the “any mode” for each group). An app could change lighting when in ‘party mode’ but only “at night”, or another app could turn on random lights if “away” and at night, but not during the day.

There maybe other ways to solve it, but this seems to me to be a flexible and elegant solution that has tons of applications, and make programming apps a lot easier and transparent. Mode changes would be simple, and no hacks would be needed.

Thoughts?


(Alex Christensen) #10

I also really need simultaneous modes to really be able to use my SmartThings to the fullest. I live in a house with 5 other people. Right now all my devices are in my bedroom and it works well. But what if I want my lights and heater to only turn on when there is motion in my room AND I am home, but the light in my daughter’s room only turn on when there is motion there and she is home? Ideally I would have a home/away/night mode for each person, and perhaps one for each car/room/appliance that multiple people use as well.


(Chrisb) #11

Alex,

I’m not sure if you want modes for what you’re talking about. Now, I haven’t played with modes much myself… but how I view them is as a way to activate or de-activate a group of programs.

For example: I have a number of automated things happening during a normal day… various lights or outlets turn on, etc. I have these setup to run in both night or day modes, but NOT in away modes. Additionally, I have various other things set to run to make it look like I’m home… various lights turn on/off. I also have a program that alerts me if something opens or motion is seen. These are installed ONLY for away mode. Now I can easily deactivate some apps and activate others with a quick mode change.

For things like “Turn on x, y, and z but ONLY if motion AND person-a is home…” that’s more of a program vs. mode. I don’t know if anyone as written an app like that, but it shouldn’t be too hard to modify something like the “lights follow me” app to also ask for a presence sensor.

Over all, I do like the idea of being able to conditionally activate/deactivate multiple groups at a time, but right now it can’t be done that way with modes. SmartApps will allow you to do this.


(Chrisb) #12

@themightypope,

What I think would be a great long-term solution would be this proposal for the team:

Allow the user to create mode groups, best illustrated with for example these groups and modes:

  • Group Daytime:
    – Morning, midday, evening, night (or just day/night)
    Group Presence:
    – Home, Away, Travelling
    Group Mood:
    – Party, Romance, mellow,

I like this idea a lot. I like the idea of calling them “groups.” Mode has a specific meaning in HA and I believe operates like SmartThings modes do right now: One mode at a time. Groups would be a nice way to differentiate between this ability and what people with “old fashion” :slight_smile: HA system are used to seeing with modes.

I would also think that groups could/should be installed with the same mode options that programs have right now. That way I can turn on/off groups with a mode change.

These is starting to get complicated now though… each program can be part of one, or several, or all groups. And each program and/or group can be part of one, or several, or all modes. Would could simplify this a little bit by saying that a program can only be in groups and groups can only be in modes. This would mean that if you wanted a program to only run when mode is set to away you would have to create a group (ie, AwayGroup) and put the program in there, then have AwayGroup only run when mode is away.

Another major complication here is how would group hierarchy work? One of your example says run groups: “Party, Romance, Mellow.” What if the party group includes a program to turn DimmerSwitch A up to 100%, but group mellow has a program that turns DimmerSwitch A to 75%. If both group Party and Mellow are running, which program wins?

Or let’s say that you have a group Susie for when your daughter is home which include a program to lock the side door. But for group Dad the program says to unlock the door. If Susie is home, then Dad comes home, which program wins? If Dad and Susie are home, but then Dad leaves, does SmartThings know to go back and look for conflicting programs between the Susie and Dad groups and now run the Susie ones that Dad group may have superseded before?

There’s a LOT of little things that need to be ironed out there before we can have reliable “overlapping” groups.


(Alex Christensen) #13

I think my problem is that the modes system really only works if you see the house as one large unit with one occupant. I live in a 2-story plus basement house with 5 other people. Someone is almost always home, but might only be using one or two rooms. If there is a break-in in the basement while my sister is napping upstairs while home alone. She wouldn’t be alerted since the whole system would have to be in “Home” mode since she is home even though no one should be in the basement in that case. That’s only one of many scenarios I can think of. I think to get the level of flexibility I’d need to get “family-acceptance” of whole-home automation would require much more granular control, such as having each smartapp have a set of proximity sensors and times tied to them directly. Most of the smartapps I’ve seen seem very single-minded, and would require significant hacking to generalize. An ability to set some while(proximity, time, etc) at the top of each app would go a long way. Of course a full blown If-Then-Else-While rule-builder would be best.


(Anders Heie) #14

Hi Chrisb,

Well no, I think maybe you misunderstood my suggestion, because you write " And each program and/or group can be part of one, or several, or all modes".

No. Each group (maybe I should call them mode-groups), contains a set of modes. So a group is merely a ‘collection’ of mutually exclusive modes, all defined within that group. This means a group can’t be ‘part of several or all modes’. A group contains modes, and that’s it. A Device can be set to be in a ‘set’ of modes, made up of one mode from each group, like Morning + Home + Party. Three modes here make up the overall state of the home. An application can be set to run in a combination of modes from groups, so a llight could be activated when the overall set of modes equals Morning + Home + Party, but may do nothing while in Evening + Home + Party.

Regarding complications like two different modes in two groups controlling the same light, that doesn’t seem so different from problems with two apps both trying to control the same light. It’s always possible to set things up wrong, this is no different, and I don’t think any worse.

You also have a great example: “Or let’s say that you have a group Susie for when your daughter is home which include a program to lock the side door. But for group Dad the program says to unlock the door. If Susie is home, then Dad comes home, which program wins? If Dad and Susie are home, but then Dad leaves, does SmartThings know to go back and look for conflicting programs between the Susie and Dad groups and now run the Susie ones that Dad group may have superseded before?”

Well, As with anything else, the last actions wins, so if it’s configured as you say, then when dad comes home, his presence is triggered and acted upon. However, with groups, you could have a group that has the modes “everyone is out”, and “someone is home”. This way, both the dad and daughters actions could easily be linked to the “everyone is out” mode, and each would only see their apps running when in fact they come home. Then the mode with switch to “someone is home”, and the dad’s arrival would trigger nothing. So your example is based on the old concepts, but with groups, you can easily avoid this problem altogether. You could even have a group that tracks ‘parents are home’ or ‘parents are away’, and link various apps to react to that for even better control.

Hope that clarifies it, and answers your concerns ?
Great discussion btw, appreciate the feedback !


(Chrisb) #15

@bazfum,

If there is a break-in in the basement while my sister is napping upstairs while home alone. She wouldn’t be alerted since the whole system would have to be in “Home” mode since she is home even though no one should be in the basement in that case.

Yeah, you’d have to approach this more on the program level than the mode level. I guess I’d recommend either writing (or asking someone else to write) a variation of the security program based on motion and presence or open/close and presence. The program would essentially work like this:

Each sensor that you want to monitor would get it’s own program. When you setup the program you’d select an individual sensor. Then you’d like any number of presence sensors that you have. You’d select the people who would typically trip these sensors. The program would then wait for the door or window to open, or for motion to be detected. When this happens it would check the presence sensors. If an associated presence sensor was listed as being home, it would NOT run the alarm routine.

For example, let’s say that Alex, Barry, and Chris share a three floor home. Alex only uses floors 1 and 2. Barry uses all three floors, while Chris only uses floors 2 and 3. They have a motion sensor on each floor, conveniently names motion 1 (1st floor), 2 (2nd floor) and 3 (3rd floor).

So we install the program and select motion sensor 1. We then select presence tags Alex and Barry. Next we install the same program for motion sensor 2 with all three presence tags. Finally we install the program again for sensor 3 just with tags Barry and Chris.

Now, when just Alex is home if he trips motion 1 or 2, nothing happens. Program 1 is looking for motion 1 to detect motion, but when it does the next test (Is Alex or Barry home) comes back positive (Alex is home), therefore we do NOT run the alarm. Program 2 is looking for motion 2 to detect motion, but likewise is sees that Alex is home and doesn’t sound the alarm.

But if Program 3 detects motion when it does it’s second test (Is Barry or Chris home?) it comes back negative (neither is home) and therefore the Alarm is sounded.


(Chrisb) #16

@themightypope,

No. Each group (maybe I should call them mode-groups), contains a set of modes. So a group is merely a ‘collection’ of mutually exclusive modes, all defined within that group. This means a group can’t be ‘part of several or all modes’. A group contains modes,

Yep, I did misunderstand that. I was putting groups below modes, but they should be above.

Now, where to apps fit in? What I mean is right now, obviously, we install our apps to when any of a select number of modes is active. I install program A and say “All modes.” Then if any mode runs, then my program runs. Or I say “Just mode A and Mode B (not C or D)” Then if either Mode A is running or Mode B is running, my app runs. But if Mode C or D is running, then don’t run my app. But how would this work in your system?

Are Apps tied to groups or modes or both?

Next, are Groups exclusive? That is, can only one group be running at a time or is it possible for multiple groups to be active?


(Anders Heie) #17
Yep, I did misunderstand that. I was putting groups below modes, but they should be above.

Yes, exactly. Groups contains modes. Glad to get that clarified :slight_smile:

Apps works just like before. When selecting which modes to work for, the app can select modes from each group, PLUS a “any mode” for each group. The UI would look almost as it does now, shown here with my sample groups from earlier:

Select modes to run in:

Group Daytime:

  • All Modes in "DayTime"
  • Morning
  • Midday
  • Evening
  • Night

Group Presence:

  • All Modes in "Presence"
  • Home
  • Away
  • Travelling

Group Mood:

  • All Modes in "Mood"
  • Party
  • Romance
  • mellow

… etc

So a user can select “Morning” + (Away + Travelling) + “All modes in Mood”, and that it. Pretty much same as before, yet infinitely more flexible.

Note that all groups are active in the sense that all groups have a mode at any given time. Same as it is today.

Also note, that I have no idea if anyone at Smartthings are listening to this thread, and actually will build this. I’m just throwing out the solution, as I think it’s pretty neat. :slight_smile:


(Ingo) #18

I’m absolutely having major issues working with a single mode-set. Coming from MisterHouse, I was able to setup unlimited mode-sets (global status variables) to monitor many different states:

HomePresence: ParentHome,TeenagerAlone,NobodyHome
TimeOfDay: Day, Night,Dusk,Dawn
Security: Disarmed, Arming, Armed, Tripped
HomeTheaterMode: On, Off
QuietTime: On, Off

Is there ANY way to do global variables with the current ST setup?

Has everyone who hit this limit opened a ticket with support@smartthings.com ? I have, and it seemed like nobody’s complained about it yet.


(Chrisb) #19

@idean,

I have no familiarity with Mr. House. How does there system work? Can you create new “mode groups” or are you stuck with just the built in?

Do you run programs with MisterHouse or is it more that the devices are just tied to the a mode change (ie, if mode HomePresense changes to NobodyHome, then turn off these switches and lock these doors?)

I worry with some of these very complex mode setups how apps would would be triggered or not. I guess SmartThings would have to have two different methods: AND or OR method. Using your examples:

HomePresence: ParentHome,TeenagerAlone,NobodyHome TimeOfDay: Day, Night,Dusk,Dawn Security: Disarmed, Arming, Armed, Tripped HomeTheaterMode: On, Off QuietTime: On, Off

Let’s say I want an app to run only when each mode is: DAY, ARMED, OFF, OFF. In the mobile app when installing my smart app I’d have to say:

  1. I want to install for specific modes.
  2. I want to run when ALL conditions met.
  3. I would open up each “mode group” then select the mode in question for each individual mode group.
  4. I would install the program.

Alternately if I wanted the app to run when any specific mode was active. That is, if it was DAY or ARMED or OFF or OFF (or any combination of those four), then I’d say:

  1. I want to installed for specific modes.
  2. I want to run when ANY condition is met.
  3. I would open up each “mode group” then select the mode in question for each individual mode group.
  4. I would install the program.

That could work. It’s a pretty big change from how SmartThings is handling modes right now so I don’t anticipate it would happen anytime soon, but it could work.

Now, two other points:

SmartApps can do much of what you want to do with mutliple modes. Granted, so of these SmartApps might need to be pretty complex and interact with a lot of different devices. Or it might entail installing the same app multiple times for different devices. (See my example on the end of page 1 for a way to tackle one aspect of this problem.)

Multiple mode groups, if implemented like this, would provide a “poor man’s method” of writing code. If you combined some simple, existing programs with these modes methods a user could create some pretty dynamic, complex home automation scenarios without actually needing to write code. Now, the user would still need to understand the logic involved… these could become complex quickly, but he or she wouldn’t need to actually do any programming. Just pick and choose selections.

For example I could installed an existing “Alert me when motion is detected” app to run when motion is detected on the upstairs stairway. Then I only want this to run when: Homepresence = childhome and TimeOfDay = Night and HomeTheaterMode = On and QuiteTime = Any. The text message sent would say: A child is coming down stairs. I’ve now “written” a program that alerts me if I’m watching a movie with my wife at night and a kids starts coming down stairs. If I happen to be watching a horror movie or a movie with a less than child friendly scene, I can turn off the TV before the child walks into the room. I’ve “written” this program without actually touching any code.

This would be a nice way to make SmartThings even more powerful to the non-coder.


(Ingo) #20

Mr. House or Misterhouse was/is a PERL-based system that you would run on a Linux box. It’s got a long, long history, but is really due for a total rewrite.

http://misterhouse.sourceforge.net/

It’s based on a series of PERL scripts (.pl files) which the system scoops up and executes as one large program. Loads and loads of power, but also loads and loads of complexity.