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.
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.
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.
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.
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.
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
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.
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?
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.
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.
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.
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.
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.
By the way, when you tested, did your Piston fire just by unlocking door from the inside using the deadbolt?
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.
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.
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.
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ā?
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.
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.