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.