Thoughts on Modes

General Discussion
21

I remember reading this thread a while back and have now returned hoping there would be a ‘solution’.
I think there is a very real need for multiple modes for lack of a better term.

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

I have events that need to occur based solely on day or night i.e. security lights.
And there are events that occur based on presence only too i.e. some motion.
Lastly, some events are based on both - if I come home at night, turn on a light and change mode to home - if I come home during the day, only change the mode to Home.

What is everyone else doing…?

22

@foneguy2 - I think a lot of these things can be accomplished with apps… for example, I do all of these things and I only use two modes (Home/Away):

  • I have an app that that turns on lights at sunset and off a sunrise (this functionality is now built in to the latest iOS app).
  • Turn on lights when the door from my garage into my house opens, but it only does this if it’s after sunset and me or my wife has recently arrived home.
  • Turn on my living room lights when the front door opens and I have recently arrived home.
  • Turn on my outside lights when I walk out the back door of my house after sunset and turn them off 5 min later (covers me walking to my garage which is detached).
  • When in “Away” mode, any contact or motion sensor will text me and set off my siren/strobe.
  • When the mode switches from Home to Away, all the lights shut off in the house.

Home / Away is determined by the presence/absence of my and my wife’s mobile presence. When I want something to only happen when I “recently arrived” I have the app check when the mode last switched from Away to Home and then take action (or not) based on that.

23

I’ve been trying to think of how to accomplish something similar, and I don’t think the current conception of modes can handle it.

Basically, I want to be able to change the bahavior of motion sensors based on where I am in the house. I would like to set up a motion-based rule for the basement lights, because my wife keeps leaving them on. But I also want to be able to watch television down there without the lights coming on if I move too much. So I want to be able to switch modes that only affect basement lights.

I guess I could set up custom modes – “home and watching television in basement,” “home and not watching television in the basement,” etc. – but that’s an overly complicated way of doing this.

24

Thanks @Steve28. Those are good ideas.
I guess if each app I use had the sunrise/sunset and the Home/Away options, that would pretty much solve my problems.

I’ll have to look into that…

@Gray Exactly what I was trying to avoid.

In other words - the alternative to multiple modes would be to have each application check sunrise/sunset, check presence, check etc. - every time it is run.

25

Yeah, I agree that it would be much better to avoid that @foneguy2. Maybe it would be possible to make modes non-exclusive. So that I could have it be both Night mode and Basement TV watching mode, or both Day mode and Basement Watching TV mode, or just Away mode, or whatever. The apps for stuff upstairs wouldn’t care about the basement-related modes, and I wouldn’t have to make explicit modes for every possible combination.

26

@Steve28 - can you please give some more details about how you accomplished these things? Specifically how you have it do things only if it’s after sunrise/sunset. For example, if I’m away and it’s after sunset, and there’s movement in the kitchen (pets), I’d want it to turn on a light near their food.

It seems like you have some nice apps that have AND/OR and IF/ELSE built in to them. Are these custom?

27

@mmerlina - yes, I wrote them (using what I learned from looking at lots of examples). I’ll paste the code below, but the general algorithm is:

  1. Subscribe to one or more contact switch’s “open” event
  2. When I get the open event, check if the current time is after sunset
  3. If yes, turn on a light
  4. If no, then do nothing

In your case, in step 1, you subscribe to a motion sensors motion event, then when you install the app, tell it that the app should only be active during “Away” mode.

The app below I use over and over in my setup. When a door opens I can have 4 different things happen with lights.

  1. lights that turn on permanently
  2. lights that turn on then off again 5 min later
  3. lights that turn on permanently, but only if I have arrived in the last 10 min
  4. lights that turn on then off again 5 min alter but only if I have arrived in the last 10 min.
/**
 *  Turn It On For 5 Minutes
 *  Turn on a switch when a contact sensor opens and then turn it back off 5 minutes later (but only if it's night).
 *
 *  Author: Steve Sell
 */
preferences {
	section("Triggers..."){
		input "contacts", "capability.contactSensor", multiple: true
	}
    section("Temporarily Turn on..."){
		input "temp_switches", "capability.switch", multiple: true, required: false
	}
    section("Turn on..."){
    	input "on_switches", "capability.switch", multiple: true, required: false
    }
    section("After arrival, temporarily turn on..."){
    	input "temp_arrival_switches", "capability.switch", multiple: true, required: false
    }
    section("After arrival, turn on..."){
    	input "arrival_switches", "capability.switch", multiple: true, required: false
    }
    section("Time Settings") {
    	input "turnOffDelay", "number", title: "Turn-off delay (s), [default 300]", required: false
        input "recentArrivalTime","number", title: "Recent Arrival time (s), [default 600]", required: false
    }
}

def installed() {
	log.debug "Installed with settings: ${settings}"
    initialize()
    //sendNotificationEvent("PorchLight Installed")
}

def updated(settings) {
	log.debug "Updated with settings: ${settings}"
	unsubscribe()
    initialize()
    //sendNotificationEvent("PorchLight Updated")
}

def contactOpenHandler(evt) {
	def sunRiseAndSunset = getSunriseAndSunset()
    def timenow = now()
    def isNight = false
    def justArrived = false
    
    // Check if between Sunset and Sunrise
    if (timenow > sunRiseAndSunset.sunset.time  || timenow < sunRiseAndSunset.sunrise.time) {
    	log.debug "$timenow is not between sunrise: $sunRiseAndSunset.sunrise.time and sunset: $sunRiseAndSunset.sunset.time"
    	isNight = true
        
        //  Also Check for recent arrival
        if ((timenow - state.timemodehome)<((recentArrivalTime?:600)*1000)) {
        	justArrived = true
            log.debug "Just arrived"
    	}
        else {
        	log.debug "Did not just arrive"
        }
    }
    else {
    	log.debug "$timenow is between sunrise: $sunRiseAndSunset.sunrise.time and sunset: $sunRiseAndSunset.sunset.time"
    }
    
    if (isNight) {

		// Turn on the on lights
        on_switches?.on()
        
        // Turn on the temp switches
        temp_switches?.on()
        
        // schedule the temp_switches to turn off
        unschedule(turn_off_temp_switches)
        runIn(turnOffDelay?:300, turn_off_temp_switches)
        
        // Check to see if someone recently arrived home
        if (justArrived) {
           	// turn on the arrival lights
           	arrival_switches?.on()
           
        	// Turn on the temp switches
        	temp_arrival_switches?.on()
            
            // schedule the temp_switches to turn off
			unschedule(turn_off_temp_arrival_switches)
        	runIn(turnOffDelay?:300, turn_off_temp_arrival_switches)
        }
	
    }
    
}

def turn_off_temp_switches() {
	temp_switches?.off()
}

def turn_off_temp_arrival_switches() {
	temp_arrival_switches?.off()
}

    
def modeChangeHandler(evt) {
	if (evt.value == "Home")
    {
		def timenow = now()
    	log.debug "Loging switch to Home at ${timenow}"
    	state.timemodehome = timenow
    }
}

def initialize()
{
	subscribe(contacts, "contact.open", contactOpenHandler)
    subscribe(location, modeChangeHandler)
    state.timemodehome = 0;
 }
1 Like
28

@Steve28 - Awesome! Thanks very much. I’ll give it a shot later tonight.

29

Modes are supposed to define a situation when we want things to be a certain way.
There are many attributes that define the situation, presence, ToD, Light, DoW…
Some of us care about abstracting this logically.
Some of us use what they give us and code the rest.
The solution above is the latter.
I feel the whole object/action model here is evolving.
I object to ST ignoring this and hoping we code… They simply meant it as “a flag…”

I actually wish they used a commercial rules engine so we’d at least have consistency checking.
I have already coded some unintended situations and I started this week!
Expanding modes/situation is consistent with their direction in the new iOS app.
Hope they continue in this vein.

Of course, having two month lags in platforms is so ten years ago…
So? They force us to code today.

30

Modes took me a while (and some online chat with tech support) to get my head around. I was thinking modes trigger actions, but it’s the other way around: Actions trigger modes. Modes filter what actions happen when. They restrain actions, they don’t cause them.

Allowing IFTTT to change the mode would also be quite handy.

31

I object to ST ignoring this and hoping we code… They simply meant it as “a flag…”

This, this. A THOUSAND TIMES this.

I’m not going to learn Groovy to make my house work. To expect users to do so is to permanently limit ST to people comfortable with coding.

I’ve had one technical job or another since 1989, and I’ve played around with simple coding in Applescript enough to know it is not something I should be doing. And it is not something any consumer-targeted product should require to get good results!

32

Well, a little out of context, but, sure… I agree and understand the sentiment. This could be even more automated when the model gets refined more.

I evaluated all alternatives I could find and this is the closest to consumer grade with the least programming I could find GA. The coding we can do to fill the functional gaps is very small & simple compared to both the hobbyist alternatives and the consumer/retail, but non-functional offerings. It’s all about trade-offs.

I can code, but don’t have time for it. Still, after a week, I wrote my first SmartApp to text me if I left any lights on in the garage. And, I read much of the docs. There exists a subscription for apps to Mode changes! Not very well known apparently! All those who tell us Modes can’t cause action haven’t read that… What is missing is multiple attributes per Mode w/o code.

But, I fully believe that either ST will address what Modes need to be when they can find time to pick their heads up, or someone here will create a workaround before long. I.e. Multiple attributes per mode with coding. What will limit that is all the hobbyists here who not only don’t mind coding,but prefer it. When I corresponded with support, they admitted to me they’d don’t use modes because they’d rather code. That is telling too. Very telling.

33
When I corresponded with support, they admitted to me they’d don’t use modes because they’d rather code. That is telling too. Very telling.

Oh dog, yes. This worries me. A LOT. ST really needs a non-coder advocating for other non-coders on the development team!

34

Just tested it. Apps can easily subscribe to Mode Changes.

def initialize() {
// TODO: subscribe to attributes, devices, locations, etc.
subscribe(location) // for Mode Change
subscribe(app) // for AppTouch to test
}

// TODO: implement event handlers
def changedLocationMode(evt){
log.debug "--------------------------------------------"
log.debug "Successfully subscribed to Mode Change Event!"
log.debug "MODE TRIGGERED: changedLocationMode: $evt"
log.debug “--------------------------------------------”
}

def appTouch(evt){
log.debug "appTouch: $evt"
log.debug "--------------------------------------------"
if (location.mode == “Home”) {
log.debug "currentMode = Home"
setLocationMode(“Away”)
log.debug “--------------------------------------------”
}
if (location.mode == “Away”) {
log.debug "currentMode = Away"
setLocationMode(“Home”)
log.debug “--------------------------------------------”
}
}
******************************************* :LOGS: *******************************************
7417d39d-654c-4203-b629-35cc43f29a55 11:19:35 AM: debug --------------------------------------------
7417d39d-654c-4203-b629-35cc43f29a55 11:19:35 AM: debug MODE TRIGGERED: changedLocationMode: Evening
7417d39d-654c-4203-b629-35cc43f29a55 11:19:35 AM: debug Successfully subscribed to Mode Change Event!
7417d39d-654c-4203-b629-35cc43f29a55 11:19:35 AM: debug --------------------------------------------
7417d39d-654c-4203-b629-35cc43f29a55 10:32:47 AM: debug --------------------------------------------
7417d39d-654c-4203-b629-35cc43f29a55 10:32:47 AM: debug MODE TRIGGERED: changedLocationMode: Away
7417d39d-654c-4203-b629-35cc43f29a55 10:32:47 AM: debug Successfully subscribed to Mode Change Event!
7417d39d-654c-4203-b629-35cc43f29a55 10:32:47 AM: debug --------------------------------------------
7417d39d-654c-4203-b629-35cc43f29a55 10:32:47 AM: debug --------------------------------------------
7417d39d-654c-4203-b629-35cc43f29a55 10:32:47 AM: debug MODE TRIGGERED: changedLocationMode: Home
7417d39d-654c-4203-b629-35cc43f29a55 10:32:47 AM: debug Successfully subscribed to Mode Change Event!
7417d39d-654c-4203-b629-35cc43f29a55 10:32:47 AM: debug --------------------------------------------
7417d39d-654c-4203-b629-35cc43f29a55 10:32:47 AM: debug --------------------------------------------
7417d39d-654c-4203-b629-35cc43f29a55 10:32:47 AM: debug currentMode = Away
7417d39d-654c-4203-b629-35cc43f29a55 10:32:47 AM: debug --------------------------------------------
7417d39d-654c-4203-b629-35cc43f29a55 10:32:47 AM: debug currentMode = Home
7417d39d-654c-4203-b629-35cc43f29a55 10:32:47 AM: debug --------------------------------------------
7417d39d-654c-4203-b629-35cc43f29a55 10:32:47 AM: debug appTouch: touch

35

So, bottom line - I believe that is what the Home (“Hello House”) Actions do, but they try to be a jack of all trades and miss some.
I think what would help would be some more granular App Templates based on Modes in the library that we could use individually.
Thoughts?

36
Just tested it. Apps can easily subscribe to Mode Changes.

Followed by a solid page of code.

A coding requirement is NOT a reasonable answer to this!!!

37

LOL. I knew as soon as I posted it. I understand. Needs to be configurable. Hence my second response above.

38

For the last week when i drive down my street at night heading home, my phone alerts me that the mode is changing from Away to Home - awesome. Then the outside lights turn OFF - not good. I am fairly technical and I can’t for the life of me figure out the lights for anything! No idea what is turning them off… And I code for a living :slight_smile:

Love ST … hoping for a shake out and shape up as far as apps and modes go.

39

I’m glad this topic is getting more attention.

Here’s my take:

Mode = A State (Lights On, Motion Detection Armed, etc…)

I use the current mode for two things. The first is when a mode changes, I trigger changes in the state (turn lights on). The second is that when an event happens, I select the modes in which I want an action to happen (mode determines if motion detection is sent as an alert).

The kludgy part of this is that I am forced to have multiple aspect modes: Away - Day, Away - Night, Home - Day; Home - Night; Home - Asleep.

I drew up a little finite state diagram and figured out the triggers that move me from one mode to another. The key was to figure out the trigger and use the current mode to figure out the transition. For example, it is after sunset…you have to have to transitions…the first is restrict to the current mode being Away - Day, which would transitions to Away - Night. The second is restricted to the current mode being Home - Day, which would transition to Home - Night.

When the mode changes, that is what triggers the lights to come on.

I think this is better than spreading everything over multiple apps. When you do that, you run into problems like what foneguy2 is running into…YOU CAN’T FIGURE OUT WHAT IS TRIGGERING AN UNWANTED CHANGE.

I think this gets unwieldy if you add things like weather conditions. Can you imagine multiplying the number of modes by four weather conditions??? (Sunny, Rainy, Snowy, Cold) If you had 3 groups with 2, 3 and 4 modes respectively, then you need 24 modes to express every combination!!

I think you have to allow users to define groups of modes and apps to trigger or one or more of the groups, it would make setting things up much easier.

40

@iotdit, For that code, I get an error:

3:17:55 PM: error ModeTest DOES NOT RESPOND TO UPDATED HANDLER

Is “app” something I have to create/define elsewhere before using this example to build from?