"Hold" app?


(Greg) #1

Hey guys,
Is there a way to put ST in a “hold” so that scheduled and or presence-based event will not run until I turn it off? Basically, I’d want a button that says keep everything the way it is… DON’T CHANGE ANYTHING.

something like that exist or is there a way to do it that i’m not seeing?


(Dan) #2

I believe the simplest way to do this is to create a custom Mode called “Hold” and then configure all of you apps to only work when the Mode is not set to Hold.

Then simply change the mode to Hold and voila!


(Mike Maxwell) #3

Don’t know if one exists, but it could be done.
Yes, new mode called hold, none of your smart apps use it.
Create a smart app tied to a virtual switch (or a physical switch for that matter)
The on method in the smart app for the virtual switch would be to get and save the current mode, then change mode to hold.
The off method would then change the mode to the saved one.
This would prevent you from having to remember the previous mode, as well as giving you an on/off button tile to activate/deactive it.


(Greg) #4

Thanks guys…

Would it be possible to take the app one step further and have it revert to the mode that ST is SUPPOSED to be on when you turn hold off? Does ST log events even though they don’t fire?


(Mike Maxwell) #5

How are you going to know the “supposed to be in mode”?, with the stock apps the mode changes are optionally managed via the hello home actions, and AFAIK there’s no way for two smart apps to communicate directly with each other.


#6

It’s going to depend exactly on what the OP meanS by “not change.” And on what’s set up.

The mode method suggested by @ogiewon and refined with a virtual switch by @Mike_Maxwell would prevent schedule triggers that check mode from being processed during the Hold mode.

It can’t prevent certain types of changes from occurring in your network, though. Or stop scheduled events that don’t check mode.

  1. local events based only on a single physical device will still occur. So a smoke alarm will still go off even if the hub doesn’t do anything about it.

The ST zigbee presence detector will still connect to the hub. The hub won’t do anything, but this means when you turn off hold mode, results using presence sensors may not be quite what you expect. If someone arrived during the
Hold period, and then you change the mode back to what it was, I’m not sure whether ST will count that as “arriving” or not.

  1. local events based on zwave association will still occur, as these do not use mode. That’s probably OK, but should be noted.

  2. I’m not sure whether runIn events, Delay events, or Scheduled events will still occur. (And I’m not sure what happens to their timers if they don’t run but their trigger time occurred during Hold Mode. They would probably just never occur, which might not be the desired effect.)

  3. events using a third party Man in the Middle, particularly IFTTT, will likely still run.

  4. anything done just by flipping tiles on the Things screen in the mobile app that doesn’t check mode will still run. Same with group shortcuts.

  5. it appears to me that the Everyone Leaves that can be added through the + sign on the mobile app is not checking mode.

All of that may be OK for the use case, but a new mode Hold is not the same effect as, say, unplugging the Hub.

FWIW


(Mike Maxwell) #7

LOL, and here we all are trying to toss code at this, when the simplest solution is to unplug the hub…


(Greg) #8

Right, that all makes sense. Let me refine the use case.

My “Good Night” Hello, Home phrase is scheduled to run at 11:45pm. But it’s 10:30, I have family visiting and we’re exhausted.

Normally, “Good Night” lowers the thermostat, arms the alarm, shuts off all the lights, and turns the Roomba on. :wink:

However, my guests being there changes things. Grandma is always cold so I turn up the thermostat a bit. Cousin Shelley is out visiting a friend and won’t be back until later. I don’t want her to trigger the alarm. My sister in law is sleeping in the family room on the pull out bed… So I don’t want the Roomba starting a cleaning cycle and waking her. Additionally, I want to keep the lights on in a few other rooms for my guests.

So I set this all manually before going to bed, but at 11:45pm, I don’t want the “good night” phrase to kick in and revert everything back. I just want to “HOLD” it where it is.

I guess another approach is to temporarily disable a Hello, Home phrase, if that’s possible.


#9

<—engineer thinking. :wink: “power off” is safer than “not now.” but it comes down to what you’re trying to do.

If I’m working on an alarm system with 50 different sensors, yeah, I’d probably just unplug the hub for awhile.

If I’m testing a bunch of Away features and I don’t want the hub to know I’m home, I’d put the presence sensor and my phone in a faraday pouch.

If I have a houseguest and want everything to work differently, I’d likely set up multiple new modes: Guest Home, Guest Away, Guest Night, etc.

So I guess my first step would be to back up and find out more about the use case.

edited to add

@ultrazero : we crossposted. :blush:


(Keith Croshaw) #10

I write in a big disable toggle around all of my SmartApps that I make just for that. Just make a boolean toggle bit in the preferences and wrap the code in it. Doesn’t help for ST internal apps though.


#11

What happens to future scheduled events like RunIn ?


(Keith Croshaw) #12

I haven’t written any smartapps with that function, Maybe just add a line to unschedule any jobs right after the if statement I guess.


(Greg) #13

Wanted to revisit this because it’s a constant annoyance to me.

Per @ogiewon’s recommendation, my solution was to create a Guests mode which prevents Hello, Home actions from firing automatically. It works for the most part. But it doesn’t allow me to get very granular. For example. I have a switch that is set up on a schedule. Every day it will turn on at 1:30am. Not part of any Hello, Home action. The other day I didn’t want it to go on, but the only solution was to dig in and change the parameters of the switch. I’d rather of just disable it with a flick of a button but there’s no way that I could do that that I know of.

Is it possible to build a smartapp that is sort of like a main switch board? It’d be able to look at your installed smartapps, switches, etc. and give you a dashboard to simply toggle apps on and off. Would this require smartapp developers to create a sort of hook in their own apps or can it be done without that?


(Greg) #14

Another thought on this because it bit me last night…

Some friends came over for a local card game. Normally, around 11pm the house kicks into Night mode and arms the alarm. Well we played past that, and because I forgot to manually set the mode to Guests, when someone opened my door around 11:30, the alarm went bananas.

I’m wondering how to prevent this from happening. There essentially needs to be a smartapp upstream of Hello, Home (Routine) which says if there is motion detected here, here, or here, switch to one mode (Guests or something else) or if all is quiet, switch to Night mode. Does something like this exist? Can it be done another way? I could have just set Guest mode manually, but it’s called home automation for a reason. :wink:

The other thought was to be able to schedule a mode change somehow. So when I put the card game on my calendar two weeks ago, I could have told it to set the house to Guest mode when it began and switch to Night mode when it ended. Possible somehow?


#15

For calendar-based events, there’s nothing in smartthings itself, but you can use the IFTTT channel for the Google calendar as a trigger and a smartthings virtual switch as the event. Trigger a mode change from that switch and it should work, but “should” depends on everything being reliable. I wouldn’t run an aquarium off of this, but it might be helpful for your guests situation.

I also like colored lights as notifications for this kind of thing, change a hue bulb to pale orange to indicate you’re in guest mode or whatever. Or even just that the alarms are on. It’s something you might notice if the automated rule failed to fire.