How to Determine Which User Code Unlocked Door


#21

Your first line is a condition, not a trigger. The piston will not fire.

And that screen I showed you should only show the activity for the lock.


#22

So, what @davidag02 gave me wonā€™t work? Because itā€™s a condition and not a trigger? My original code did run. So, whatever I used in that code must have been a trigger. I did locate the screen you mentioned, but Iā€™m not sure itā€™s helpful, but here is what I have so far. I have to run and take care of some things, but Iā€™ll try to open and close using various codes and screen capture that.


#23

So, if I take out the first condition, I have the same problem as before (i.e., unlocking the deadbolt turns the alarm off). I did go outside and lock and unlock. Here is the screenshot. I am going to see if I can create the code that @davidag02 gave me exactly to see if it works. Itā€™s probably because I mucked with it a bit that it doesnā€™t. Thanks.


#24

OK, I tried @davidag02ā€™s code just about exactly as written. I think the Piston ran, but it never executed the middle IF command to disarm the system or send me a text. So, it doesnā€™t seem to know that I unlocked using one of the 5 codes I asked it to watch.


#25

I would highly recommend switching that CONDITION and triggerā€¦

IF lock #1 2 3 4 5 6 get unlocked
Then
      IF smart home status is NOT disarmed
      Then 
       do this do that

#26

@rcbjr2 @ike2018 @Mebejedi

Iā€™m the guy that responded on Reddit. The code I shared with you was written with help from 2 people on here. The original code did have the trigger first and the condition second. However, I could not get that configuration to work reliably. The problem was that if someone used the code to unlock the door and then immediately opened the door, the piston would not fire in time to disarm SHM, and the alarm would trigger. Reversing it was the only way to prevent this from happening.

The way it was explained to me was that if the condition is first, then once that condition is met, WebCore is constantly monitoring for the trigger that comes next, and when that trigger happens it is able to immediately take action. If the trigger is first, then when that trigger happens, it must test the condition, and then disarm SHM. That one extra step made all the difference.

I assure you, this works. I use it in my house for a very similar purposeā€¦ our housekeeper uses a specific code that then disarms SHM when they enter.


#27

I tried @rcbjr2 's original piston, and it worked for me. When using the code, Alexa would speak. If another code was used or unlocked manually, Alexa wouldnā€™t speak.

I will say thisā€¦I notice your RECENT ACTIVITY shows the names of the people associated with the codes. Iā€™m curious to know how you were able to label each one (as mine only gives the numbers), and Iā€™m wondering if thatā€™s affecting the piston. Are you running a smartapp in ST that works with the lock?


#28

Sorry, I canā€™t resist biting ā€¦

If we just consider devices for the moment, and ignore special cases, there are two significant differences between triggers and conditions.

  1. By default, the piston subscribes to changes in the device attributes used in triggers, whereas it only considers those used in conditions when there arenā€™t any triggers. It is these events being received that causes the pistons to fire. It doesnā€™t matter what the changes are (if any), only that SmartThings has generated an event.
  2. When the piston executes, both triggers and conditions are simply comparisons between values. For a trigger, the comparison looks at the event to see if it involved changes to the device attribute it is interested in. If it did, it compares the new value carried by the event to a cached copy of the previous value. For a condition, the comparison compares the current value read from the device to an archive of previous values.

So that is a long way of saying that there may be a reason why a particular order of the trigger and condition worked better, but the reason you were given was not it. The pistons would fire at the same time and at that point the ā€˜triggerā€™ has already happened. There may be small timing variations between the two orderings that are sufficient to make one way more resilient, but it seems a little precarious.


#29

If that stuff makes it to the event, it should make it to the $args variable. There will probably be $args.usedCode, $args.method etc.

Iā€™ve not worked with locks, but I believe that lock codes appeared in community handlers before they made it to ā€˜officialā€™ device handlers, and that the ā€˜Lock Codesā€™ capability used in the latter is completely undefined in the documentation. So there must be a significant possibility that you will get different results with different handlers.


#30

Weā€™ll, it worked at 10 pm when my stepson came home. I got a text that it turned off the alarm. I think the problems I was having at first are related to internet connectivity and latency. I use rboyā€™s LUM app to set codes and turn off the alarm, but it wasnā€™t always working, so I am trying other options to ensure the alarm turns off. I have a scene in the New App that sends an off command to the alarm. I was pressing it last night while testing and it didnā€™t turn off the alarm, which makes me think thereā€™s just a big delay in the commands being sent from my phone and reaching the alarm. When I open a door, the SimpliSafe app sends me a notice immediately. Thereā€™s just a delay between SmartThings and SimpliSafe. Thanks.


#31

My other code worked later in last night when my stepson got home from work. Weird. As I wrote in another message here, I think itā€™s latency/delay in connection between SmartThings and SimpliSafe. Anyway, with respect to named codes, I use @rboy Lock User Management app. Gives me a lot of control over the locks. It is set to Disarm SHM when a lock is opened with a code and run a routine that directly turns off SimpliSafe, but lately it doesnā€™t always work. Itā€™s not LUM, but rather the delay between ST and SS I mentioned above, so I was trying to see if WebCore could do it faster, but I think it has encounters the same latency issue. Oh well. Anyway, thanks for checking this out.


#32

Ok, thanks for the suggestion.


#33

By the way, when you tested, did your Piston fire just by unlocking door from the inside using the deadbolt?


#34

Nope. Only with the code.

It sounds like youā€™ve run several different programs. I hope youā€™ve remembered to turn off everything else when trying your piston.


#35

Ok, thatā€™s interesting. Iā€™m going to flip the condition and trigger later per @ike2018 suggestion to see how that goes. I donā€™t turn off all the other options because Iā€™ll know if the Piston runs by the text notice. And I got one last night when my stepson came home (and I heard SimpliSafe announce ā€œoffā€ twice). Thanks.


#36

I tried switching it up. See below. Lines 16 to 28 didnā€™t seem to work. This is the same issue I had last night about this time. Iā€™ll see what happens when my stepson gets home to see if it works. Maybe our neighbors are stealing all our internet connectivity? ;-). Anyway, I assume that the image below is actually showing that lines 16 to 28 did not activate since there is no ms indicator next to the lines. Thanks.


#37

If I had to guess, Iā€™d say the fact that ST labeled each code with a name might be your problem. Itā€™s seeing ā€œRCBā€, ā€œRLBā€, and ā€œBlakeā€. Did the RBOY app label them? You might need to change those back to ā€œ1ā€, ā€œ2ā€, and ā€œ3ā€ (if possible)

Also, couldnā€™t your Disarmed line simply read ā€œIf Smart Home Monitor Status is Armedā€?


#38

Weā€™ll, strangely, it worked fine when my stepson got home last night at 10 pm. I saw the push notice that webCore Disarmed the system. I guess itā€™ll work sometimes but not always.


#39

Hereā€™s an interesting thing. My stepson got home from school around 315 pm today. He had to turn SimpliSafe off using the keypad because my Piston didnā€™t run. I just now realized there is a logging feature, which I have turned on to check in the future. However, I looked at the Piston, and the Trace, and it looks like it started at 337 pm, over 20 MINUTES later. Is that what the Trace means when it says it started at 337? If that is the case, then the problem is the web and lack of speed in the connection. Or is it that I looked at the Trace at 337 and when it said it ran 22 minutes ago, it really ran closer to 337 but didnā€™t turn off the alarm because by that time my stepson had already turned it off and based on my IF statement that the system be Disarmed before turning it off, it never got to that part? Iā€™m having trouble reloading the Piston here on my phone while at the office, so I canā€™t double-check, but in essence all I need to know is if the Trace shows 337 PM, is that when the Piston started? Thanks.


#40

I would turn on Full Logging. That will tell you exactly when everything ran.