For a Delayed Alarm Trigger off Entry Door to allow operation like old-school alarm where the Entry or Exit door does not immediately trigger, to allow time to Disarm:
This could be for Entry into the house when the Alarm is Armed, to give time to Disarm before it triggers, or perhaps from inside the house in the Morning, if your Auto Disarm has not yet occurred, and you need to let the Dog out and possibly forget to manually disarm:
Does this work? Am I missing anything?
Make a Simulated Switch for Entry Doors and set STHM to trigger on the Sim Switch and donât include the Actual Switch
Sharptools Rule
Trigger
Entry Door Opens
Flow
Turn Piezzo Buzzer On
Delay 30 seconds
IF (Arm Away is on)
THEN
Turn Entry Door Sim On
ELSE
IF Entry Door is Closed
AND
Disarmed is on
THEN
Turn off Piezzo Buzzer
Donât need a reset on the Door Sim since it wonât be set if disarmed before timer expires?
And wonât set the Sim under not-armed conditions ⌠?
And whether it triggers or not, you would still get a reset off disarmed to reset the door sim condition?
Hi @Bethel_Lane, I might have missed something, but why do you need the Entry Door Sim in this case? How about creating two separate rules like screenshots below to keep the logic simpler?
Rule 1: Alarm Siren with 30 seconds delay (Like the old fashion way)
Rule 2: Whenever the Alarm is disarmed, turn off the siren. ( I have the STHM Sim Switches PIN protected in the dashboard, so it works like the old fashion alarm too - I just need to tap âdisarmâ to turn off the siren.)
Thanks @James
The problem (as I see it) with your scheme is that you are not truly triggering the STHM Alarm, only operating the Siren. The STHM already has its automations for what sensors it triggers off and the resultant action when it triggers (whether that be siren(s), strobes or notification etc)
And you would have to delete the Door from the STHM list of triggers or it will trigger the STHM anyway, as soon as it opens.
My suggestion maintains the ânormalâ STHM trigger mode other than it uses a Simulated Switch rather than the Actual Switch.
@Bethel_Lane, thanks for the clarification and it makes sense. How about updating the first rule to the screenshot below? So it will be triggered when either the physical door is opened or closed. If the physical door is closed, it will immediately sync the Sim Door; otherwise if the physical door is opened it will delay 30 seconds to and determine it should turn on the siren and turn on Sim Door based on the STHM status.
I didnât have the Siren Off in this rule, because I think it makes sense to be turned off when STHM is set to disarm as mentioned in the Rule 2 above.
So Iâm not following need to have door change to either open or closed - you essentially want the trigger to occur in relation the sensor changing to open, that should initiate the trigger, even if it delays 30 sec before executing (i.e. itâs not a condition that it is in either particular state, only that it had even that momentary change) - why would it also need to happen if changing to closed??? Iâm confused on that one âŚ
Then - in your scenario, again, you donât need to add the siren, as the STHM will address that already
And for the If/Else, if STHM was not Armed (i.e. it had been Disarmed within the 30 s) then the Sim would not set therefor you donât need to reset it to closed. However it might need the Sim Reset for condition where STHM is Dis-Armed AFTER the 30 secs has elapsed (i.e. Alarm has been triggered)
I think this does it âŚ
So I can make sure the Sim Door is set to off immediately every time the physical door is closed. The logic is slightly different here. In my case, my STHM âalertâ will be ended whenever the physical door is closed because the Sim Door is turned off immediately, but my physical siren wonât be turned off until I manually turn the STHM Disarm to on.
In your case, once the Sim Door is turned on and tripped STHM alert, it needs the physical door to be opened again to trigger this rule one more time and wait 30 seconds to evaluate if the buzzer and the Sim Door should be turned off. But this may be what you wanted anyway.
My siren is a physical siren converted from the existing security system using Konnected board, and it needs an automation somewhere so it can be turned on/off based on STHM status in my setup.
Yeah I agree that an easier screenshot function should be provided in the Rule Engine interface to make the rule visual sharing easier. I just created a Feature Request for this, and feel free to cast your vote.
I use ShareX on my PC, and take âScrolling captureâ when I need to take rule screenshot, if this would help you in the short term.
I certainly donât mean to be argumentative - especially since I asked for review in the first place!
But I still donât get your logic with this flow.
I donât believe thatâs what your flow is doing
I find talking it out helps:
Your case - If EITHER the Door changes to OPEN OR the Door changes to Closed THEN, IF the Door Contact IS open THEN, Delay 30 seconds and IF the Armed Away is (still) ON, THEN Turn ON (Open), the Door Sim;. ELSE (If Front door contact is NOT open) Then Sim Front Door to Off (closed)
So digesting that
Your whole flow is based on the Door Sensor BEING Open - - it might be closed again but you still need the flow to take place (otherwise you just open and close the door and the flow never happens)
In my case, my STHM âalertâ will be ended whenever the physical door is closed because the Sim Door is turned off immediately,
But you donât want that - otherwise, that statement taken literally, says I can just quickly open and close the door and the alarm will never trigger.
In the first stage your setting of the door sim does not happen (only after 30 sec delay and only if, again, the door is STILL open AND the System is Armed - therefor the âElseâ statement is moot
Reading out just the âElseâ condition says If door contact changes to Open OR Closed, then if Front Door Contact is NOT open, then turn off the Sim (but again, would not have been turned on in this condition to begin with)
Mine is too (on Konnected Panel) - the Siren can still be set up in the STHM directly and of course the STHM still sends the signal back to the Konnected board to turn siren on when there is an âAlarmâ Trigger condition.
I actually just noticed the left side Security, Smoke, and Leaks are buttons and can be tapped to configure the Response, including turning on the Siren. I assume this is what you meant by the STHM will take care of the siren.
I see where the confusion came from. The IF condition checks the condition logic at the moment it is executed, and decides which path (THEN or ELSE) to continue. Once itâs in THEN/ELSE path, it doesnât care about the condition(s) in the IF logic any more but just continue to the next step.
In this example, if the physical door is opened, the rule will be triggered, and it takes just a few milliseconds before the IF condition decides to go THEN/ELSE. If the physical door is closed quickly then, the rule will be triggered again, and will evaluate & process individually without impacting the execution of the first trigger (door open). So if the STHM ArmAway is On, the first rule execution will continue to turn the Sim Door on, (and turn on the siren in my setup), even if the door is closed quickly afterwards.
Should have mentioned that it will be even faster to use Context Variable in the first IF condition, because it doesnât need to query the device status but just use the triggering eventâs context info directly.
I thought you might have been unaware of the response configurations - and of course you also configure it for your trigger conditions
(so for example for away you include motion detector; for home, not; and you can configure entry doors sim to be representing as many as you want - maybe front door, or door in from garage is good for âawayâ condition, but home you might also want to include back door, like for letting dog out when you forget alarm is armed and used to having it disarm on a schedule - someone asked regarding that very scenario on Konnected FB!)
OK - I think Iâm following your rationale
(Iâm not sure about the contextual variables - need to do some reading on that)
But I still see that (at your least initial) flow as:
Initial trigger is âdoor opensâ as Trigger and then also simultaneously presents the âIfâ condition (door is open)
So you will immediately get a Then action (because it is open at that very instant) so the âElseâ becomes moot at that point, right, from this flow action? (hence my saying the Else is misplaced at that point of this initial flow condition);
But also because your initial Triggers also incl Door changes state to Closed option, that would generate a NEW (second) Trigger which, because door is now closed, would create the sim closed Else condition - but again, it would not have been set to be open anyway.
So again the way I read that is
You would have TWO back to back processes activated
The first (door changes to open) sends it down the âThenâ path - delay 30 secs etc
The second (door changes to closed) THIS time sends it down the âElseâ path (I think this is misplaced here as it really doesnât achieve anything)
Meanwhile the initial âThenâ action is still proceeding -
Waits 30 secs and if the Alarm is armed, then set the Door Sim to Open.
But I donât believe your Door Sim will reset during this process because of the misplaced initial Else location in the flow - and I think mine addresses that?
Yeah, I think either setup would have a scenario that doesnât reset the Sim Door to Off depending on if the door is closed within the first 30 seconds or not. (If it the door is closed after 30 seconds, your rule wonât reset Sim Door; if the door is closed within the first 30 seconds, my rule wonât reset Sim Door.)
If the door is closed after 30 seconds is not a concern for you, then your rule may fit better. Otherwise, you may combine two to cover both scenarios.
The other alternative is to replace the Door closed trigger in my rule with Door stays closed for 31 seconds (to be larger than the 30 seconds window), so Sim Door will always be reset to off 31 seconds after the last door closed event.
Yes, youâre right
This has been good process just to talk through this
I think mine with a second rule that just resets the door sim after disarmed is another way to go (essentially just moving the very last piece of mine in that last âElseâ condition to a new rule)
Got around to empirical testing:
Amazing how things look good on paper, but the acid test proves how it really works - or NOT in this case
The first thing I found was that it was not resetting regardless of what I tried - finally, when looking at the âdisarmedâ condition, I realized that I had made that âsimulated switchâ actually a simulated LOCK!!! (that was so that I could put in an unlock code in Alexa for verbal command - you canât do that in Alexa with a switch, it has to be a Lock)
Changed that and now the Reset was working
(For those using a std simulated switch in SmartThings for the Disarmed, just use switch state here)
Then I found that even when I disarmed it (before the 30 secs) it still proceeded to turn on the Sim, although it did Dis-Arm and turn off the buzzer
That was a fundamental error in the Flow - as soon as it satisfied the initial armed condition, it immediately processed the Sim-On command after the delay, even if the disarmed subsequently takes place.
So I just added another âIfâ condition to check that is still armed (or actually NOT Dis-armed) before it turns on the Sim. Ergo if it HAS been disarmed it will not set the Sim
I have now tested all the permutations* with these changes and it works.
Dis-armed, door open and closes
Armed - Door Open and Close, Disarmed prior to 30 secs
Armed - Door Open & Close, not Disarmed until after 30 seconds and it Alarms
This is the final (I think!!!) rules
(incidentally - I made these images by the method I added to the Quick Rule Screenshot Feature thread - very efficient)
Hi my friend, I share how I would do it (now I have my ADT/ST Panel) connected to Smartthings, and its 100% handled in Sharptools I once handle delay but decided trigger siren immediately.
RULE 1 âALARM CHIME WARNINGâ (Triggers warning chime and switches simulated switch to ON to control delay before Siren goes full Off)
Trigger: WHEN any of these events occurs:
X Door Switch to OPEN
Y Door Switch to OPEN
X Motion Sensor to ACTIVE
Y Motion Sensor to ACTIVE
Flow:
IF all conditions are met:
MODE is ALARM AWAY
Then:
Switch CHIME_ALARM_WARNING to ON
Switch ALARM _SIREN to CHIME_WARNING
RULE 2 âALARM SIREN GOES OFFâ (Triggers full siren sound if simulated switch and warning chime stays On by 10 seconds)
Trigger: WHEN any of these events occurs:
Switch CHIME_ALARM_WARNING stays ON 10 seconds
Flow: Switch ALARM _SIREN to ALARM_SOUND
RULE 3 âDISARM ALARMâ (when alarm is disarmed and mode changes silence siren and set to off the simulated switch control)
Trigger: WHEN any of these events occurs:
MODE changes to HOME
Flow: Switch ALARM _SIREN to OFF
Switch CHIME_ALARM_WARNING to OFF
To change modes you can make the proper automation STHM->Mode in New App.
Hoping my idea helps.
I assume this is what you meant by the STHM will take care of the siren.
