ZWave Lock Jam with Elk

[johngalt]

I have two Yale ZWave deadbolt locks connected to my Elk via a M1XSLZW.
 
Here is what I have working:
 

• I can lock and unlock each lock
• I can view the lock status (locked vs. unlocked)
• I can check the battery status of each look
• If I press the keypad and a lock is jammed I view a message on the keypad and it will email/txt me

 
However, if I command the lock to lock via ZWave and there is a jam I do not see the notification anywhere.  This is important as I arm the system and walk away from my house.  After the 60 second exit delay the lock will lock and if there is a jam, then I want to know.  
 
Any ideas? 
 
I know the suggestion is usually to put a sensor in the deadbolt "chamber" to ensure the lock is fully engaged.  I plan on doing that for one lock as it is near a keypad and easy to wire.  However, the other lock is part of a french door.
 
Any suggestions would be greatly appreciated.

 

[drvnbysound]

Based on your 4th bullet I assume that you have the JAM string (JAMx^M) defined in the ElkRP TEXTS; where x is the number of your lock.
 
Have you tried...
 
WHENEVER THE FOLLOWING TEXT IS RECEIVED: "JAMx^M" THROUGH PORT [port number of your M1XSLZW]
     THEN SEND EMAIL MESSAGE ...

 

[johngalt]

Based on your 4th bullet I assume that you have the JAM string (JAMx^M) defined in the ElkRP TEXTS; where x is the number of your lock.
 
Have you tried...
 
WHENEVER THE FOLLOWING TEXT IS RECEIVED: "JAMx^M" THROUGH PORT [port number of your M1XSLZW]
     THEN SEND EMAIL MESSAGE ...

The following is my rule that works when I press the lock and cause it to close and create a jam.  However, it does not work if Elk sends the command to lock which causes a jam.
 
 

WHENEVER THE FOLLOWING TEXT IS RECEIVED: "<JAM2^M" THROUGH PORT 2     
THEN DISPLAY "Play Room Lock Jam" IN House (Area 1) INDEFINITELY, [*] CLEARS
THEN SEND EMAIL MESSAGE 5 TO xxxxxx@xxx (Email 5)    
 
 
  

 

[drvnbysound]

Based on your description it's really hard to say where the problem lies... it could be that the lock isn't reporting the Jam when the lock receives the automated command, or maybe your network is dropping that information because it's busy with something else. Again, really hard to say...
 
Assuming you have the typical Zwave setup with Elk (VRC0P + M1XSLZW) I would suggest that you connect to the VRC0P directly and see if it's receiving the JAM message in both cases. If not, then it would make sense that Elk isn't notifying you.
 
Curious, what locks are you using?

 

[johngalt]

Based on your description it's really hard to say where the problem lies... it could be that the lock isn't reporting the Jam when the lock receives the automated command, or maybe your network is dropping that information because it's busy with something else. Again, really hard to say...
 
Assuming you have the typical Zwave setup with Elk (VRC0P + M1XSLZW) I would suggest that you connect to the VRC0P directly and see if it's receiving the JAM message in both cases. If not, then it would make sense that Elk isn't notifying you.
 
Curious, what locks are you using?

 
I do have the VRC0P+ as recommended by Elk.
 
I have the Yale YRD240-ZW-619 and so far really happy with it.
 
I wish I could see who (what code was used) to unlock the door, but I believe that is a limitation of the Elk M1XSLZW.
 
Speaking of that I can check when I connect the VCR0P+ to my laptop via serial and see.  The only catch with this is when I disconnect the M1XSLZW I won't be able to have the Elk send the lock command automatically.  I can send it via the serial connection, but it isn't 100% the same.  I agree it is my best option however.
 
I will check and post back.

 

[drvnbysound]

Connect to the M1XSLZW directly and issue the command via Elk... that should show you the command that the XSLZW is issuing to the VRC0P.
 
Then connect to the VRC0P and issue the same command - it should activate the lock.

 

[johngalt]

So I don't think it is the lock...
 
I connected to the VRC0P via serial cable to my laptop.
 
When I touched the keypad to trigger the deadbolt and extend it sent the command showing a jam was present.
 
I then issued the lock command where a jam would not occur
 
>N002SS98,1,255
 
And it returned the following line
 
<n002:000,113,005,024,001
 
I then issued the same lock command when a jam was created and it returned the following.
 
<n002:000,113,005,009,000 which documents show is the error code for a jam.
 
Therefore, it looks like the correct code is being sent from the VRC0P when a jam occurs. It appears the M1XSLZW doesn't see it when the lock is trigger by a rule or maybe it recieves the jam code but for some reason my rules are not running.
 
Any other ideas?

 

[drvnbysound]

Just for troubleshooting purposes, try removing the email statement and change that to turn on a Phantom output (one with no physical connection) and check the status of it after the Jam condition. See how reliable that is. Note that you would need it to turn back off to reset... so maybe have it turn on for 30 seconds or a minute, giving you enough time to check it before it turns back off.
 
If that is, then there may be an issue with the email portion; hard to tell which side (XEP vs. server) particularly when it works under certain conditions, but at least it would help to diagnose where the problem may be.

 

[vc1234]

Hi,
 
Wondering what was the status the VRC0P unit returned when you caused the jam manually("it sent the command showing a jam was present").  As you showed, VRC0P does return a status when you cause the jam via a Zwave command. Is it different from the manually created jam status ?
 
Not being optimistic wrt all things zwave in general, I must mention that Elk surely contributed to the general zwave unreliability, e.g. thermostats. 
 
I am so frustrated by occasional thermostats not setting a setpoint(about once a month) and not knowing where the problem lies that I am  tempted to "invest" in an EZ-Tap serial sniffer to record traffic between M1XSLZW and VRC0P.  It won't help me much to fix the problem as I pretty already pretty convinced that it is Elk that loses the setpoint command but at least I'll know for sure.

So I don't think it is the lock...
 
I connected to the VRC0P via serial cable to my laptop.
 
When I touched the keypad to trigger the deadbolt and extend it sent the command showing a jam was present.

 

[ddennerline]

The jam detection does work for Kwikset locks as I left one door slightly ajar a few weeks back. You can contact Elk and provide them the strings that are being returned when you have VRC0P+3 hooked up to PC/Hyperterminal.  It’s possible that strings are slightly different for Yale locks.
 
Jam detection IMHO has minimal utility IMHO. I wish the lock companies would have implemented dead-bolt is seated sensing for their automated locks. To me this seems like a major oversight.  Over past few years, I found 2-3 cases where I believe the deadbolt should have locked. When I came home, the door wasn’t locked. I suspect either low-battery condition or "solar flares".

 

[ddennerline]

Just to be sure, you are creating “jam” by leaving the door slightly open. The dead-bolt will extend, but the dead-bolt’s spring will cause a “snap” or clicking sound.