bamarayne
(Jason "The Enabler" as deemed so by @Smart)
23
Since my modes are used for basic level I don’t worry about things like guest mode and stuff. All modes except sleep and away basically adjust thermostat levels and determine brightness of lights triggered by motion and which lights turn on but motion.
For example, in sleep mode, only one bulb comes on in the bathroom at 5%, but during the day they all turn on at 100%.
Each family member has automatons based on their presence. So like if the teenager leaves, his room turns off. He comes home, the room turns back on.
1 Like
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
24
Oh yeah, and the guest room is controlled via motion, Minimote, and Alexa.
I have Alexa in every room of the house including the garage.
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
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
26
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.
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.
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.
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?
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.
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…
…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.
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.
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
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.
I’m surprised so many people are using them…