SmartApp or Device Handler for Delayed Entry--peer review requested

So, I now have working prototypes of a SmartApp I call “Delayed Entry” and a Device Handler for a Virtual Switch I call “Simulated Door Sensor”. What I would like from the folks here is some input on which method you think is better for my custom solution to the delayed entry shortcomings of the built in Smart Home Monitor (SHM) solution in SmartThings.

Option 1) - Custom SmartApp “Delayed Entry” and custom Device Handler for Virtual Switch
The problem with using a virtual switch in SHM is you can’t select it as a sensor to monitor. I added the sensor and contact sensor capability to handle that. I also whipped up a quick SmartApp to control it instead of using something like the Smart Lighting app. The problem with Smart Lighting is that even though you can have a Virtual Switch follow a sensor, if you shut the door, then the virtual switch will close on it’s own. This app will send the on() command to the virtual switch after you open a contact sensor based on your set delay time. Then, it will automatically close it back (if you want) after a set delay. The catch is, the app will not turn the switch off when you close the contact sensor. It either stays open requiring manual reset or automatically closes AFTER it’s open. That way the bad guy can just shut the door behind him.

Option 2) - Getting Fancy with the Device Handler and use Published App
In addition to adding the contact sensor capability to the device handler for the Virtual Switch (VS) I got a little fancy with it. I basically added the logic from the SmartApp into the device handler itself. This way you can use the VS with either my custom app or any app that does a follow me type of logic. You can go into the settings of the VS that’s using this device handler and set options for “On Delay” and “Auto Reset”. So, now this VS just needs something to trigger it and it will wait for a delay to change the contact state to “open” and then optionally automatically close it back. The only tiles I have show the current state and a “close” tile to manually close it. I chose not to allow open so you can’t accidentally trigger your SHM Alarm. But, if you choose so, you can not have it automatically reset, so now you can close it back after it opens. I like this little guy because I added a third state called “timing”. When the VS is triggered and it has the built in delay set, it will change it’s state to timing to let you know it’s working. It will then change to the open state once the timer has expired.

Option 3 - Is simply to use my little app without the delays and just use the fancy device handler

So, what do you think about the Device Handler I created? Is that stretching beyond the tasks a device handler should perform? Should I forget adding that much functionality to a device handler and keep it in the App?

Sounds like an interesting project! I like the “timing” state as well.

Since there are several new threads posted to the forum each week from people asking how to do delays ( The usual answer is just use core), I did change the title on your thread to make it clear that you were looking for feedback on your ideas, as I think more people will read the thread then. :sunglasses:

1 Like

Thank you. Still learning the community ins and outs. It’s actually more complicated than groovy.

2 Likes

Hi Garrett, this sounds very similar to a project I did a couple of weeks ago. Also wanted an entry delay for the ST SHM. I use a smartapp (Alarm Proxy) where I can configure motion sensors/contact sensors for away and stay mode, and the delay of course. Then I also created a “multi” simulated sensor for contact and motion capabilities. This simulated DTH is also used to get some Ui possibilities for the system. So pretty much you hook up SHM to the multi sensor (I use one for contact and one for motion) and then in the alarm proxy you hook up all your sensors to the simulated ones.

Here are the links if you want to take a look:
Alarm Proxy
Virtual Multi Sensor

2 Likes

Thanks @tette I’ll check that out!

@tette, I didn’t realize you can subscribe to the SHM events, that’s very useful. I like this approach. I didn’t install the app or DTH to my location, but I think I get the premise. I like that you integrated the notifications into your app. I was using the custom section of SHM to alert me if one of the physical devices that I choose to delay is triggered in away mode. The problem with my method is I had to remember to setup each contact in both apps. I think your way is a bit cleaner. I was also debating on using a one to one physical to virtual relationship that way the SHM knew which device triggered, just a matter of preference I believe.
I was mostly curious how you reset the virtual device. It looks like you just use the same delay to reset it after it was triggered. I have been working on some logic to give the user some options. I didn’t want to lose the functionality SHM has built in that will warn you if you try to arm but you still have a door open. So, I’m working on making the virtual device follow the master at all times. I’m still testing but I think I’ve got this working. It’s a little tricky having a delayed trigger and not lose track of the current state if for some reason the sensor opened and closed rapidly a few cycles. I noticed you have used unschedule() I assume that cancels any runIn() schedules. That seems handy and something I may implement into the application for my keypad. I noticed the other day I set the alarm to stay using my code, but by entering my code and pressing the disarm key didn’t stop it from arming. Rambling now…sorry. Thanks for sharing.

Yes it is quite convenient with the SHM events. Im a bit unsure if they are considered as “officially” supported or not, but a lot of apps around is using them.

=) had the same issues with one to one or not, at some point I couldn’t be bothered with creating that many virtual devices (could be done automatically by the app also). I do miss at the moment that you can see whats going on in the house from the SHM view (including the sensor open warnings). Might send the warnings from the alarm proxy instead…hmm

I use the unschedule to cancel any run-ins so that I don’t update the virtual devices if the alarm is canceled. Useful in the scenario when you forget something in the house, cancel the alarm and then start the alarm again. When the alarm is started again I didn’t want to get any delayed triggers.

There are alot of good companion solutions to this topic on the forums: Zone manager, User lock manager, Smart alarm to mention a few, and of course Core…

1 Like