Thoughts on Modes

@Ingo
I left out the preferences. A significantly better example is on page 2 of this thread. I didn’t see it as I was exploring and came back. http://build.smartthings.com/forums/topic/thoughts-on-modes/page/2/#post-11725

@eckenroth
I did the same thing. I found two or three cases that had the same outcome for lights, locks, alarm, etc out of 8 or so.
And, since I work with world class rules, I can picture the decision table I’d like to have.
It does not scare me to see it expand and contract by user’s esoteric dimensions.

Again, what would solve it all is an array of Modes.
With a function to add, check or remove a Mode. Simple.
But, I bet the logic we want would be just as complex, just parameter controlled.

@foneguy2 with rules, one typically has consistency checking and testing with a suite of situations the system automatically runs for you. The system can tell you why any action was taken and which rules fired. Considering the amount of time this system has been out being coded from the ground up, it isn’t half bad!

I was thinking something along the lines of “mode groups” as well.

In my case, I’m on a time-of-use electric plan, and it would be great to have my A/C be aware of when my electricity costs me more or less.

Grouped modes would be a great way to do this, I could have one mode for [summer|winter] since the schedules change with the seasons, and one for [on-peak|off-peak]. Then the “cozy…” apps could be configured to set the temperature based on what mode the on-peak setting is, what the “presence” mode group is, and one that maybe tells it whether I’m asleep or not ( I like the house cold when I’m sleeping )

Someone apparently need to make the support guys stop coding around all their problems too, otherwise little pain-points like this aren’t ever going to get fixed.

I sure wish IFTTT could read and change modes.

Hey guys!

Tyler L. from SmartThings Support here. I just wanted to take a minute and respond to some of the questions and concerns in this thread.

First of all, I want to assure you that we here at support are not offering highly technical solutions or telling people to code when they email us or chat in at http://support.smartthings.com. We’re here to help regardless of your technical abilities, and we’d never tell someone that they need to code something if they hadn’t already expressed an advanced technical ability.

On to modes. There are a few different ways to think about modes. Perhaps the easiest way is to think of a mode as a setting for when certain configurations are active. You can set a configuration to work in a specific mode and then it will only fire in that given mode. For example, if I want my bedroom lights to turn on on 5PM, I might add to that configuration that I want it to only execute in “Home” mode.

The first way to control modes is in Hello, Home. In Hello, Home, you can tell certain phrases to execute mode changes. For example, the “I’m Back” phrase changes the mode to “Home” by default.

Modes get really cool when you start to automate them. If you enter Hello, Home, then click the gear at the bottom, you’ll be prompted to configure each phrase. Select a phrase like “I’m Back”, and scroll to the “Additional settings” on the bottom of the screen. There’s an option to “Automatically perform…” this phrase. I have my “I’m Back” phrase set to automatically perform itself when I arrive home. Once the “I’m Back” phrase is executed, the mode is changed to “Home”, and any automations I’ve tied into the “Home” mode happen, like lights turning on at a certain time or my door unlocking.

We have some really cool stuff coming up, surrounding modes and otherwise, that will allow you to build simple and complex rules that are more creative and custom than what we’ve imagined. These tools won’t require any coding knowledge.

Please reach out to us if you have any questions about modes or anything else. We’re available on live chat either in-app or at http://support.smartthings.com during business hours, and at support@smartthings.com if you would prefer email.

Thanks!

Thanks Tyler L. - Appreciate the post.
Quick question to summarize my ‘demands’.

Using a scenario similar to then one you mentioned…
If I want my bedroom light to turn on when motion is detected … but only if I am home AND it’s nighttime…
Yes - you can ‘program’ around this, but it would be nice to have multiple modes possible - home/away, day/night, etc. - so the same thing as your scenario but it would only turn on if home AND night mode(s).

Thanks again.

@tlange,

Thanks for that, would love to see the really cool stuff coming up.

When?
Will it be able to do the following?

Event-Driven HomeAutomation Language Requirements

Input-device Events - when a sensor changes
Time-based Events - based on date/time
Count-down Timer Events - so a light can stay on for X minutes
Mode-change Events - abstraction layer to keep from having to repeat the same logic in every event rule and then update 20 different places if the base logic changes
SubRoutines - so multiple things can fire a single event without having to duplicate the logic
Scene Array - a place to save "scenes" so you can go back to a known state of being

EXAMPLES in un-debugged hodgepodge pseudo-code:

##Presence Detector device fires:
WHEN Presence:DAD==HOME OR Presence:MOM==HOME OR Presence:Child1==HOME
    DO RecalculatePresence
    

##Presence detector says someone's gone:
WHEN Presence:DAD==GONE OR Presence:MOM==GONE OR Presence:Child1==GONE
    #Wait 4 minutes, then inform the house I'm gone
    SET Timer:RecalculatePresence=4m
    

##Countdown Timer fires:
WHEN Timer:Presence EXPIRES
    Do RecalculatePresence

    
##This is a called routine
SubRoutine RecalculatePresence
    IF (Presence:MOM==GONE AND Presence:DAD==GONE) {
        SET Mode:PARENTS=GONE
        IF Presence:Child1==HOME
            Set Mode:ChildAlone=True
        ELSE
            Set Mode:ChildAlone=False
    } ELSE {
        SET Mode:PARENTS=HOME
        SET Mode:ChileAlone=False
    }

##Door Sensor event:
WHEN Sensor:LiquorCabinet==Opened
    IF Mode:ChildAlone==True {
        Picture=DoSub:TakeWebCamPhoto
        Device:Siren=OnWithTimer(15s) #Turn the siren on for 15 seconds
        Picture.SendSMSto(Mom,Dad)
    }

##Outside Motion happened:
WHEN Sensor:OutsideMotion==True
    IF (Mode:House==GoodNight OR Mode:NobodyHome==True) {
        #I'm only interested if we're in bed or gone away
        IF Timer:OutsideMotion==0
            Mode:AlarmLevel=Mode:AlarmLevel + 1
        Set Timer:OutsideMotion=15s #Ignore motion for 15 seconds
    }

##Countdown timer expires:
WHEN Timer:Alarm==0
    Mode:AlarmLevel=0

##Mode:AlarmLevel change Event
WHEN Mode:AlarmLevel CHANGED
    IF Mode:AlarmLevel==0 {
        #Turn Alarm off     
        Scene:BeforeAlarm=RESTORE
        Device:Siren=Off
        Device:BoomboxTunedToTalkRadio=Off
    } ELSE {
        #Escalating alarm: More actions if motion continues
        Set Timer:Alarm=5m #5minutes
        IF Mode:AlarmLevel==1 {
            #If this is the first alert, save the current state of the house:
            Scene:BeforeAlarm = (Device:PorchLight, Device:DeckLight, 
                    Device:KitchenLight, Device:FamilyRoomLight)
            Device:PorchLight=On
            Device:DeckLight=On
        }
        IF Mode:AlarmLevel>1 {
            Device:KitchenLight=On
            Device:FamilyRoomLight=On
        }
        IF MODE:AlarmLevel>2 {
            Device:BoomboxTunedToTalkRadio=On
            Set Timer:Alarm=15m
        }
        If MODE:AlarmLevel>3 {
            Device:Siren=On
            Device:PorchLight=STROBE
        }
    }

     

Thanks Tyler L.

I echo @foneguy2’s point. I totally agree the modes are perfect for describing the state of the house. I also completely agree with the idea that an event triggers the change in mode, which will trigger changes in the environment.

The problem is basically that when I have an event triggering a mode change, there is other information I need to determine what mode which to change to.

Most of us are using modes that carry the information forward:

Away - Day
Away - Night
Home - Day
Home - Night
Home - Night - Asleep

So you can use the current mode and the trigger to determine which mode to change to. If there was a way we could interrogate other “state” information when a triggering event happens, then we could create complex conditions and a simplier number modes.

@foneguy2 & @Eckenroth

Definitely possible right now without needing to touch a line of code. It’d be done with a combination of mode changes and Dashboard configurations.

  1. Select the gear next to “Lights and Switches” on the Dashboard.
  2. Add a new light/switch and name it. Select the device and assign it an icon.
  3. Select the configuration for “Turn on when there is motion.”
  4. Choose the mention sensor and any associated options.
  5. Scroll down to “More options”.
  6. Configure “Only during a certain time” so that this configuration is only active at night. 6:00PM - [choose your end time] is a good start.
  7. Configure “Only when mode is” to “Home”.

The last thing to verify is that you’ve automated your Hello, Home phrases to initiate the “I’m Back” and “Good morning” phrases to turn on “Home” mode.

@ingo

I’m pretty rusty with my coding, but if I’m parsing this correctly you’d like to activate an alarm when a cabinet is opened and a child is alone at home. Additionally, you want to monitor for motion and activate an alarm that escalates if motion continues (e.g. lights come in, then radio comes on, then siren/porch lights come on). Feel free to tell me I’m completely wrong!

Just to be up front with you, this seems to be a very complex automation. There might be a clever way to get close with modes and the Dashboard, especially with the new siren capabilities in the Motion module. The main problem I see is the escalating alarm. The closest I think you could get, and I’m just spit-balling here because I’ve never attempted something like this, would be initiating a series of mode changes that have a prerequisite of the prior mode, like this:

If motion detected, change mode to “Alarm 1”.
If motion is detected and current mode is “Alarm 1”, change mode to "Alarm 2"
If motion is detected and current mode is “Alarm 2”, change mode to “Alarm 3”

You would then tie in your device actions to the mode changes in Hello, Home. The biggest problem to overcome is that most/all motion sensors have a timeout window of 30 seconds to 1 minute. This means that if motion is detected once, it’ll report “No motion” after that timeout period. If motion is detected once, then again during that timeout period, it’ll continue reporting motion until the timeout period has lapsed with no motion. Hope that makes sense.

TLange - thanks again for being involved here.
No one is saying that just about any given scenario could not be programmed using current ST methods/modes etc.

The issue here is ease and flexibility.

Using the same - scenario - motion turns a light on only if Home and ‘night’…
If I have 4 lights and each have their own motion sensor to turn them on when motion is detected and home and night - currently, i would do as you say and set them to only come on when ‘home’ and after 6:00pm. that works great now in March, however in a few weeks, at 6pm it will still be pretty bright outside, so I’ll need to change it to 7pm. So I go back and edit each light to change from 6 to 7pm. Then a month after that, same thing all over again. If multiple modes were allowed, I could go to one location and change 6 to 7.

This is a simple example of the benefit to having multiple modes - other examples have been discussed. Even a way to set ‘flags’ would help i.e. Kids Home/Kids Not Home, Asleep/Not Asleep, Vacation/Not Vacation, etc…

@tlange wrote:

First of all, I want to assure you that we here at support are not offering highly technical solutions or telling people to code when they email us or chat in at http://support.smartthings.com. We’re here to help regardless of your technical abilities, and we’d never tell someone that they need to code something if they hadn’t already expressed an advanced technical ability.

I’m maybe immodest but I think this is at least partly a response to me. First off thanks for addressing this. I never meant to suggest that “Just code something” was official policy of Physical Graph. I was instead trying to point out that, at least at this stage of ST’s development, it’s a prevalent attitude.

A natural one, when of course most of the development team are coders. Many of the early adopters are too. Maybe I’m unique here in that I’m very technical, but not at all a coder. Sure, I’ve puttered with Applescript, but when I took a PHP course it went in one ear and out the other, and while I have UNIX command line skills, I wouldn’t dare try to write a shell script for production without another person with actual programming skills looking at it.

No, I was talking about an attitude here in these forums and also as reported to me second hand as being the attitude of the devs. (Damn if I recall where but I’m sure it was here in some topic, not even one I was initially involved in.)

That said, at the moment in ST’s development, to get what seems to be relatively straightforward inputs turned into outputs, coding IS required. Follow this link to see what I mean. I asked a question and was immediately pointed down the Groovy rabbit hole.

I had already started writing down my thoughts about this, and now that we’re into it here, I’m going ahead and publishing it with the warning that I haven’t really polished it and I’m sure there’s more to expand on, but here it is.

I’m happy to read you have more complex Mode actions/triggers in the works. Any chance mode changes/states could be exposed to IFTTT?

A conversation about the post I linked is also taking place on Reddit here. It seems useful to post here because it is not full of people who are on ST’s “side.”

One specific reason I could use multiple modes and/or flags. Vacation. If I am gone for 2 or more days, it would be nice to have a ‘vacation’ flag. Then some of my day-to-day apps would be set to not fire if on vacation and conversely, some security apps would only fire when on vacation. Vacation is different than ‘Away’ in this case…

Another reason, entertaining mode. In this mode, some of my apps set to occur at a specific time of night would not fire because we are entertaining people…

That’s it - I have said all I can to make my case for multi-modes/flags :slight_smile:

1 Like

Has anyone received any updates on this need from SmartThings?

What a great discussion. From all I read, it appears as if my suggestion from October last year (Scroll up), which involves the creation modes as groups (much more detail at the start of this thread), would in fact solve all the problems mentioned in the thread.

I’m considering starting to code a generic mode device, which can handle dynamic modes. The downside would be that it’s a lot of work, and I prefer if Smartthings would simply re-think their mode handling to actually support it as a standard feature. The crux we all come back to is you can be at-home at night and at-home during the day, and with a few more of these, the number of ‘pseudo’ modes becomes unmanageable quickly. Also, while you theoretically can code your way out of pretty much anything, that’s not a solution.

It’s a pretty forward problem to solve, I believe my outlined solution would satisfy all the requests, so my question to Smartthings is: What are you building? When will we have it? And what will it support exactly?

2 Likes

Couldn’t agree with this suggestion more. I have edited my modes more times than I can count, and I still can’t get them the way I want. There are too many apps that are trying to deal with this lack of ability.

The problem is that I can’t conditionally change to a mode based on multiple inputs, I only get one mode choice. So if I arrive home and it’s day or night I lose track of that. Yes I could ignore day/night as a mode, and try to use triggers, but then I lose the ability to restrict based on that mode.

ST becomes much more powerful when it implements multiple mode sets as described, Night/Day, Home/Away/Vacation, etc.

I’ve managed to code around some of the more obvious ones like coming home and setting a mode based on the light level, but I could’t agree more - multiple mode sets and multivalue logic to operate on them is IMO the way forward for folks to be able to configure this without needing to program. Although I get a kick out of programming my house, I recognize it’s a niche thing, and for HA (and hopefully ST) to go really mainstream, we need this kind of flexibility baked in without the need for coding (but keep the ability to code too please!!!)

And by multivalue logic I mean the ability to use and/or, relative comparisons, and multiple clauses with the ability to group. The multivalve logic needs to apply to the “If This” as well as the “Then That” so we can say something like:

If (presence.mode changes from “Away” to (“Someone Home” or “Everyone Home”) and (house.mode is “Away” or “Vacation”)) then (if the light level from the sensor < 300 lux turn on the lights and set house.mode to “Evening” else set house.mode to “Day”)

Not a great example but you get the idea …

I have seen this kind of interface done well in other applications and it can be made pretty intuitive, yet can be really powerful.

I use 4 modes and they have always worked great for me: Home - Day, Home - Night, Away - Day, Away - Night. I use Hello, Home actions to have them automatically switch based on presence and day/night.

It takes 8 actions for this to work right: Come Home Day, Come Home Night, Leave Home Day, Leave Home Night, Sunrise Home, Sunrise Away, Sunset Home, Sunset Away.

These allow the modes to cycle automatically. For them to work right, though, it’s real important to specify which modes each action is NOT supposed to trigger the change to occur under. This is specified under the “Don’t automatically do this if I am in one if these modes…” field. Let me know if anyone would like to know how I set this up more specifically.

I’d like to know, but was afraid it’d come to this…

@bridaus, no problem! It does take about 20 -30 minutes to setup correctly, but once you have it set it’s good to go. Also, the steps are pretty repetitive so once you get the hang of my logic it goes by pretty fast. Here are the steps:

  1. Go into the screen where you add/remove/rename your modes
    1a) Change Home to Home Day
    1b) Change Away to Away Day
    1c) Remove Night
    1d) Add a new mode called Home Night
    1e) Add a new mode called Away Night

Now you should have all four modes: Home - Day, Home - Night, Away - Day, Away - Night.

  1. Go into Hello, Home
    2a) Create a new Action called Come Home Day. Under “What do you want to happen?” set “Change the mode to” Home Day. Under “Additional settings” set “Automatically perform “Come Home Day” when…” to occur when Someone arrives. Under “Additional settings” in this same section check the boxes under “Don’t automatically do this if I am in one of these modes” for Home Day, Home Night, and Away Night.

2b) Create a new Action called Come Home Night. Under “What do you want to happen?” set “Change the mode to” Home Night. Under “Additional settings” set “Automatically perform “Come Home Night” when…” to occur when Someone arrives. Under “Additional settings” in this same section check the boxes under “Don’t automatically do this if I am in one of these modes” for Home Day, Home Night, and Away Day.

2c) Create a new Action called Leave Home Day. Under “What do you want to happen?” set “Change the mode to” Away Day. Under “Additional settings” set “Automatically perform “Leave Home Day” when…” to occur when Everyone leaves. Under “Additional settings” in this same section check the boxes under “Don’t automatically do this if I am in one of these modes” for Home Night, Away Day, and Away Night.

2d) Create a new Action called Leave Home Night. Under “What do you want to happen?” set “Change the mode to” Away Night. Under “Additional settings” set “Automatically perform “Leave Home Night” when…” to occur when Everyone leaves. Under “Additional settings” in this same section check the boxes under “Don’t automatically do this if I am in one of these modes” for Home Day, Away Day, and Away Night.

2e) Create a new Action called Sunrise Home. Under “What do you want to happen?” set “Change the mode to” Home Day. Under “Additional settings” set “Automatically perform “Sunrise Home” when…” to occur at Sunrise. Under “Additional settings” in this same section check the boxes under “Don’t automatically do this if I am in one of these modes” for Home Day, Away Day, and Away Night.

2f) Create a new Action called Sunrise Away. Under “What do you want to happen?” set “Change the mode to” Away Day. Under “Additional settings” set “Automatically perform “Sunrise Away” when…” to occur at Sunrise. Under “Additional settings” in this same section check the boxes under “Don’t automatically do this if I am in one of these modes” for Home Day, Home Night, and Away Day.

2g) Create a new Action called Sunset Home. Under “What do you want to happen?” set “Change the mode to” Home Night. Under “Additional settings” set “Automatically perform “Sunset Home” when…” to occur at Sunset. Under “Additional settings” in this same section check the boxes under “Don’t automatically do this if I am in one of these modes” for Home Night, Away Day, and Away Night.

2h) Create a new Action called Sunset Away. Under “What do you want to happen?” set “Change the mode to” Away Night. Under “Additional settings” set “Automatically perform “Sunset Away” when…” to occur at Sunset. Under “Additional settings” in this same section check the boxes under “Don’t automatically do this if I am in one of these modes” for Home Day, Home Night, and Away Night.

That’s it! Your four modes should begin switching automatically now based on presence and whether it’s day or night. Now just be sure to go into any of your lights, door locks, etc. that you have programmed to turn on/off, lock/unlock, etc. and select which of the four modes you want the actions to occur under.

Let me know of any questions.

9 Likes