Simple SHM Entry Delay With Sonos Announce

#1

Another simple piston that hopefully others might find useful. There are a lot of fantastically complex and genius example pistons on this forum but thought it would be helpful to share an easy one for people still getting used to webCoRE like myself.

It links a virtual contact sensor to a physical one. Physical door sensor opens… virtual one opens with a 30 second delay. The virtual one is what you put into SHM to trigger the alarm. If SHM is disarmed before the virtual sensor opens, nothing happens.

To round it out, Sonos announces when the entry delay is active.

It works for me, but feedback or criticism welcome.

SHM entry delay
SHM entry delay.png1178×1267 208 KB

#2

The reason for the two IF statements is I have two different doors being monitored (front and back door).

#3

Just for clarification would you mind sharing which are the virtual contact sensors and which are the actual ones?

#4

Yes, of course! That’s the only thing I don’t like about the green snapshots, sometimes it’s hard to tell what is what.

The real contact sensors in the doors are Contact Sensor 1 and Contact Sensor 4 (acting as the triggers in the IF statements).

The virtual contact sensors are Contact Sensor 4 and Contact Sensor 7. These are what SHM is monitoring when ARMED / AWAY, and what would actually trigger the alarm. When in ARMED / STAY mode it monitors the physical ones so the alarm will go off instantly (like at night when asleep).

In my case this piston rarely executes fully because I have SHM disarm with presence, but on one occasion that failed and the Sonos announce in this piston saved me from the alarm going off and the entry delay gave me time to disarm manually.

#5

Nice!

I did something similar. The spoken notifications come from my android control tablet, and my Schlage lock functions as the security keypad so I don’t need the 30 second delay to disarm.

I have the virtual contact sensor report as ‘open’ four seconds after the lock is unlocked with an appropriate code, while the piston tells SHM to disarm immediately after the code unlocks the lock. And the announcement occurs four seconds after the door’s contact sensor opens… it announces who came in, based on the code that was used to unlock the door.

#6

If your Contact1 opens and starts the 30sec timer, does disabling SHM actually stop the timer and contact2 open? I don’t fully understand how WebCoRE handles re-entering(?) the code.

I think you meant 1 & 4 are real contacts, as they initiate the speech and wait. Contacts 2 & 7 are virtual which you use in SHM Away if/when they open after 30sec wait. Correct?

#7

Sorry for the delayed response, but you are correct. 1 & 4 are the physical door contact sensors, and 2 & 7 are the virtual that are monitored by SHM.

Because “SHM changes to disarmed” is subscribed to as a trigger in the “else if” section of the conditional, it will cancel what the first half of the piston was doing if the “else if” becomes true. So yes, if you disarm during the delay countdown, the virtual contacts will never open. But even if they did, SHM would be set to disarmed so they wouldn’t trip anything, anyways.

It’s a pretty simple setup and has worked well for me for about a year.

#8

Perfect! This is just what I needed. I was on the right track last night, but I couldn’t quite get the logic right.

#9

Be careful, the piston will cancel is the contact sensor changes to closed. You need a never cancel statement. Also, I don’t understand why you have the async. Theres only one a action in the async group.

You also don’t need two virtual contact sensors or two statements. Should be all grouped together so they don’t interfere.

#10

I believe he’s doing that on purpose which is why he has the ‘else if’ statement to close the sensor after he disarms the security system thereby stopping the countdown. However, if he closes his physical door before disarming the system then the countdown will also stop since the original trigger changes. So it is actually better to do a ‘never cancel’ anyway and as long as the security system is disarmed before the virtual sensor opens then the alarm won’t go off.

#11

I think Ryan780’s point was that if the physical door was closed it would cancel the alarm. This would not be good if an intruder broke in and could simply disarm the system by shutting the door behind them.

I thought the cancellation policy was based on condition state changes, i.e. if SHM status changes, and not triggers. I thought triggers were just passed to the piston as an event. I could definitely be wrong about that but I’m almost positive the alarm has gone off by mistake even after the door was closed.

The async is probably just a misunderstanding on my part, too. I thought it meant the piston won’t wait for whatever action has async assigned to it, and continue to proceed with the rest of the actions. I didn’t know the rest of the asynchronous actions had to be lumped into the same “with”.

The reason I use two virtual sensors and two statements is I label the virtual sensors “Front Door Alarm” and “Back Door Alarm” in SHM so when I get push notifications it tells me which door the intrusion happened on. Not 100% necessary and maybe there’s a more elegant way to do this. I’ve actually updated this piston and added some motion sensors that combine to a single virtual motion sensor, similar to as suggested.

If I’m wrong about the trigger state change canceling the piston and how async works that would be awesome if you could clarify more on how to use properly. I’ve always felt like the piston worked as expected so I never questioned it. Thanks!

#12

Look at the task cancelation policy. Conditional state change is the default.
Also, why would you want the alarm to not go off if the door was closed? The whole point is that once the delay has started to disarm the system, nothing stops the alarm from going off than disarming the system. Otherwise it would be very easy to break into your house. Just don’t leave the door open too long.