Best practices for using Away Mode

You go back to the trigger for the regular mode and set it up so it will not occur if you are in one of the override modes. All the routines have the option of not running into certain modes so you can put your override modes into those settings.

Select the mode(s) for Don’t automatically do this if I am in one of these modes

Say you normally had your night mode come on at sunset but for whatever reason you don’t want to do that if you have guests.

You just set up the routine so that it will not run if you are in the mode of day – guests.

It’s a lot of stuff to keep track of, but you can do it. It’s easier to read your logic if you are using a piston and web core because you can keep everything together. But if you only want to use the official features, you can still do it with modes.

2 Likes

Very true.

I use ST routines to change the modes based on time. They will not change of the system is in away mode at the scheduled mode change.

I use CoRE for everything else, including a mode monitoring piston for those times the system fails to change the mode. It’s pretty rare these days, but it still happens. The piston checks the mode every 15 minutes and updates accordingly.

1 Like

Insightful thread. Here’s what I’ve pieced together. I set up a virtual switch (switch 13) for company mode, which just acts as an override switch to call on in pistons. It also has a tile on the actiontiles panel, so if anyone is housesitting, they can easily access it if they need to, and it’s easy for us to tap it on the way out the door. Sleep-Home turns off the house. We always manually enabled it via a minimote, so it should only be automated if we’re away. I have it this way because we have a few ambient lights in the house that shouldn’t be left on all night if nobody’s home (and to make it look like we’re here). I’ll eventually use the away modes for notifying me of things that happen while nobody’s home, as well as general reference.

3 Likes

The basics work well for me:
-Home (normal daytime), selected by auto-routines: GoodMorning and I’mBack
-Away (when everyone is at work school etc), selected by Goodbye auto-routine
-Night (when sleeping), selected by GoodNight routine via virtual switch for use with “Alexa, turn on bedtime”
-Vacation (activates random lighting when we are gone for more than a day or two), manually selected with vacation routine

I use this to set up SHM, thermostat, Arlo cameras. Other stuff done via webcore.

Haven’t found the need for bunch of morning/evening home/away combination modes. I can see need for a new ‘Vacation with dog-sitter’ mode now that I think about it though so I can have random lighting but not trigger SHM every time dog-sitter visits.

1 Like

I use her door unlock code to disarm SHM and then re-arm on locking.

I don’t trust any “smart” locks or door openers :fearful: I’m surprised so many people are using them…



How do you get it to see the time of the day?

I have some basic modes:
After Sunrise
After Sunset
Night
Away

The after sunrise is triggered by a routine
the after sunrise is triggered by a routine
The Night is triggered by "good night"
the away is triggered by “good bye”

The issue is if I leave in the morning, and come home for lunch, Im Back triggers and the mode can only change to one or the other (after sunrise/sunset), same as if I come home at night…

So how do I get it to change mode to after sunrise when I come home during the day, and after sunset if I come home in the evening?

Any input would be awesome

After reading multiple threads that had your exact same question I decide that I would just install webCoRE and use it to manage modes and presence. It’s very robust and a major upgrade from the standard apps.

However…if you don’t want to go down that path then what most people do to get around the dilemma you are in is to create more modes (which is what I didn’t want to do).

But you’d have to make things like:
After Sunrise-Home / After Sunrise-Away
After Sunset-Home / After Sunset-Away
Night - Home / Night Away

Then you’d need to make a routine which would change the Away modes as the day progressed as well as one to do the same for the Home modes. Then when you come home it would be in the right “time” setting and you could take the appropriate action.

Again, this all gets very cumbersome which is why I decided to use webCoRE since it is so much more powerful. Takes a little bit more time to setup and learn, but once you have it going it really makes things tick.

1 Like

Thank you for that answer! I think webcore is the way to go… Is this a
smartapp?

I am new to SmartThings and Home Automation in general, but in less than a week of owning my hub, I have quickly run into a wall with only being able to set one mode at a time. I need a way to stack modes.

Rather than creating a byzantine list of modes like this (which grows exponentially every time I add a new “type” of mode because I have to account for every possible combination of mode types…

home-night-guests-weekend
home-night-guests-weekday
home-night-noguests-weekend
home-night-noguests-weekday
home-day-guests-weekend
home-day-guests-weekday
home-night-noguests-weekend
home-night-noguests-weekday
away-night-guests-weekend
away-night-guests-weekday
away-day-noguests-weekend
away-day-noguests-weekday
etc

…I think a much better way of handling this is to create global variables in webCoRE that represent various MODE TYPES:

  • LocationMode: Home, Away (This can be the built-in ST mode)
  • DayMode: Morning, Day, Evening, Night, LateNight
  • SleepMode: Asleep1, AsleepAll (Asleep1 means “at least 1 person is asleep” while AsleepAll means “everyone is asleep”)
  • VacationMode: Home, OnVacation
  • GuestMode: Guests, NoGuests
  • WeekendMode: Weekday, Weekend

The one main disadvantage here is that now I am forced to use webCoRE for everything, and thus all my automation tasks run in the cloud instead of locally, since all of the additional mode types I created aren’t visible to the native ST app… or are they? I suppose it’s not a huge deal, since the internet rarely goes out, and when it does, it’s usually because of a power outage so most of my automations wouldn’t work anyway.

holy cow. I’ve never needed more than 5 modes. What’s wrong with using days of the week and times?

One thing that might help you simplify is to use a virtual switch for guest mode, and a virtual switch for vacation mode. Then in your Pistons, organize things like:

If presence sensor is away, and guest mode is not on, then turn off lights.

You can easily just flip the switch when you have people over, or flip it when you leave for vacation.

2 Likes

I’m not going to go into the overkill with the number of Modes you are proposing that in my opinion is going to cause more frustration and chaos down the road, especially when you have that many Pistons trying to handle 4 x 4 (16) Modes, which doesn’t include things like Vacation, Pause, etc… While things are working , it will be like artwork, but the minute it fails, it is setting you up for a disaster. IMO look at adding 4 different Modes and then in conjunction with the 4 Modes (Home Day / Home Night / Away Day / Away Night), I would create a Virtual Switch for Weekend, Weekday, Guest, No Guest and work with that. Then you have a Mode set with a combination of any of the switches. LOL. Ok enough of that.

What I did want to address is the statement “The one main disadvantage here is that now I am forced to use webCoRE for everything, and thus all my automation tasks run in the cloud instead of locally”.

Even if you could run all of your Automations with Routines (which is highly doubtful based on the need for more complex qualifications), they run in the Cloud as well, so dialing yourself into webCoRE is not a disadvantage in this regard. There are additional values of having everything in webCoRE: Centralized and consolidated Automations all defined and grouped in one location versus spreadout out across Routines, Smart Lighting Rules and inserted into other SmartApps capable of scheduling anything. Makes troubleshooting easier as well.

One downside is if the cloud goes down, everything is on hold and that’s where backup plans come into play and potentially having Smart Lighting rules in place to be able to run locally in the event of a system failure, or knowing all the local devices (Bulbs, Switches that can be manually switched on and off so you aren’t in the dark).

The only thing you would be able to run locally is from the Smart Lighting SmartApp (pieces of SHM run locally as well) to create basic rules and even with this, every single device in the Rule has to be a Local device. If one device is Cloud based, this won’t run locally either.

Nothing, if that works for you. Those were just examples and I would only need LocationMode, DayMode, and SleepMode with the tasks I currently have set up, but I’m not finished. Your way would require duplicating code across several routines/pistons to accomplish the same thing, which means that if you want to change how an automation task behaves, you will likely have to change parameters in several routines/pistons, instead of one.

I do like the idea of virtual switches for things that are not easy to trigger automatically, like Guest Mode.

Virtual switches are really just a way of stacking modes as I proposed. They are the same thing as mode types, with a different name. You don’t need to address all 16 mode types in each piston, only the ones you care about for that task.

In a sense yes, but giving you a different level of Control, both Automated and Manually initiated for times that you want to override what would automatically run. So on top of setting the Modes you have your Armed states (SHM) working in conjunction with that. I just think it will be less painful to balance the actual Modes (Home and Away and combined with Day and Night) versus separating the conditions of those Modes that includes Guests, No guests, Weekends, or Weekdays. I believe that building your Pistons for Automations on this combination of things versus is it all shoved into Modes will allow you to also write Pistons for manually overriding when these Pistons would normally run. Having additional Pistons built where you want to change from Guests to No guests, you would just flip the switch and the secondary Pistons would check to see if the time is between Sunset and sunrise and what day of the week it is and then fire accordingly. Just some thoughts before you go too far down the rabbit hole. Glad you are thinking, mapping and architecting it out first instead of just building it and painting yourself into a corner like a lot of folks do :grinning:

Not necessarily. I split up my pistons so that I evaluate conditions to determine whether or not to run the piston that actually does the routine.

For example: I have a morning wake up routine that if I do nothing will happen every weekday at 6:30. However, there are times when I get up earlier than that…so I can tell the Echo to “start my day” and it will turn on a virtual switch in ST which will start the routine right away. Then when 6:30 rolls around I have it turn off that switch so that it does not run again until the next day. Or I can start the same routine by hitting the switch on my phone, or by double-tapping a light switch in the bathroom. It’s always going to do the same routine (same piston), but there are multiple ways for me to start it off. Heck I even have it so that if I have a Holiday switch on that it does not run at all. I just tell the Echo to start it when I feel like getting up.

But again, I built it in such a way that numerous events can all trigger the same piston. So if I ever need to tweak the routine I’m only changing one piston and not half a dozen.

1 Like

Mike, I know there are several ways to set things up, and that’s part of what I love about ST, but I think we’re not quite talking about the same thing here. You’re talking routines and triggers, I’m talking modes (which are like filters for routines).

Imagine that I have 5 pistons that I want only to run if it’s dark outside. Without modes, I would need to program each piston to run only between [30 min before sunset] and [30 minutes after sunrise]. Also keep in mind that this range might appear multiple times within a piston. Let’s imagine this range appears 2 times in each of the 5 pistons, so it would appear a total of 10 times.

Now let’s say I change my mind about what constitutes “dark”, and want it to be 15 minutes before sunset and 15 minutes after sunrise. I would have to go to 10 different places and change the number (really 20 places because it appears twice each time).

Instead, I could have a single piston that sets night mode based on sunset and sunrise offsets. That’s literally all it does. Then, my other 5 pistons only need to reference night mode. If I want to change the parameters that define night mode, it’s in 1 place and I don’t need to go searching all my pistons for the 10 places it appears.

Am I over-thinking this? Maybe. I’m an engineer, that’s what I do. Having the same information appear several places is a recipe for inconsistency and is setting yourself up for “why the heck did my automation behave like that – that’s not what its supposed to do”.

2 Likes

I’m a Developer in another industry as well. We all tend to overthink things.

So let me throw this out to you for a minute in a different way.

Just an example based on your requirements:

You have 16 total Modes that I’m calling 4 x 4 based on the examples you began in your first post.

So now that you have added these 16 Modes. Your Pistons initial IF qualifications are going to include time of day and days of the week to set the specific Mode automatically.

Now you mention adding variables in WebCoRE. What are you going to base these variables values off of if not a State of a Virtual Switch? Where is the variables value coming from?

So let’s say it’s Saturday and it’s after dark. How do you know if you are going to set the Mode to “HomeNightWeekendGuests” versus “HomeNightWeekendNoGuests”. If you don’t have Virtual Switches defined as a device, how is WebCoRE ever going to know the difference between Guests and No Guests on its own and what THEN or ELSE statements to fire of off?

Thats why I am suggesting that you slim this down to Modes consisting of Home day / Home night / AwayDay / AwayNight. Then create virtual switches for Guests / No Guests / Weekday / Weekend. This way based on these switches being invoked as On or Off it dictates what Pistons fire or what steps in a Piston fires. You can Automate these switches with a Piston based on day of the week and a default value for Guests or No Guests and things automatically run, but then you also have the ability to open the device in Things and say oh wait, we have guests coming, let me switch to Guests and the appropriate Piston or step in a Piston fires and sets up the appropriate Mode and the device Automations that are to occur. Maybe that will help in looking at it from a different angle.