Zwave lock not working on ELK M1

Ckerch

Member
Having trouble with setting up and getting the Z wave to work on Elk M1 system
Elk Configuration:
• M1KP2 with 485 address set to 1
• M1XIN with 485 address set to 2
• M1XIN with 485 address set to 3
• M1XIN with 485 address set to 4
• M1XSLZW with 485 address set to 2
• M1XEP
• VRC0P+3 Z-Wave Serial Interface as secondary controller
• VRUSB as primary controller
• (2) Kwikset Zwave locks
• Leviton Zwave switches and dimmers
• GE Zwave switches
 
I included all the Zwave devices with the VRUSB, set to association’s with RS232 Diagnostics and updated the VRCOP. Once that was done, I restarted the M1 to discover the Zwave devices. I created text variables using the “<ULOCK#^M” format and created a rule “sending text string on Port 2” command. I can control lights using the rule but not the locks. Also tried changing the port to 1.
 
Not sure what I am missing. Can anyone offer some suggestions?
 
Thanks
Carl
 
Ckerch said:
Having trouble with setting up and getting the Z wave to work on Elk M1 system
Elk Configuration:
• M1KP2 with 485 address set to 1
• M1XIN with 485 address set to 2
• M1XIN with 485 address set to 3
• M1XIN with 485 address set to 4
• M1XSLZW with 485 address set to 2
• M1XEP
• VRC0P+3 Z-Wave Serial Interface as secondary controller
• VRUSB as primary controller
• (2) Kwikset Zwave locks
• Leviton Zwave switches and dimmers
• GE Zwave switches
 
I included all the Zwave devices with the VRUSB, set to association’s with RS232 Diagnostics and updated the VRCOP. Once that was done, I restarted the M1 to discover the Zwave devices. I created text variables using the “<ULOCK#^M” format and created a rule “sending text string on Port 2” command. I can control lights using the rule but not the locks. Also tried changing the port to 1.
 
Not sure what I am missing. Can anyone offer some suggestions?
 
Thanks
Carl
I would try to connect the VRC0P to a notebook and issue the lock commands manually via a terminal application to make sure the VRC0P actually picked up the configuration from the Leviton stick.  E.g.:
 
 -- lock status
>N42,SS,98,2

-- Lock:
>N42,SS,98,1,255
 
N42 -- is the lock zwave node id.
 
vc1234 said:
I would try to connect the VRC0P to a notebook and issue the lock commands manually via a terminal application to make sure the VRC0P actually picked up the configuration from the Leviton stick.  E.g.:
 
 -- lock status
>N42,SS,98,2

-- Lock:
>N42,SS,98,1,255
 
N42 -- is the lock zwave node id.
I am having trouble finding a terminal program that can allow me to send the string,
I am running Windows 10 on a laptop that has a 9 pin 232 port.
 
Device ID is 10 and tried to enter "N10,SS,98,1,255 >COM1" and "10,SS,98,1,255 >COM1" in a cmd window. Both times I received "Access Denied". Not sure if that is coming from my laptop or the VRCOP.
I also tried running the cmd window with admin rights.
 
Can you recommend a terminal program that will work on Windows 10?
 
Thank You
Carl
 
Ckerch said:
Can you recommend a terminal program that will work on Windows 10?
 
Thank You
Carl
I use strangely enough 'putty' which is a free ssh client for windows but it also can do serial connections.  It's simple to use. You'll need to disable hardware flow control.
 
Also, you need to type '>' as in the example above:

>N42,SS,98,2
 
It's not a prompt but rather part of the command.
 
vc1234 said:
I use strangely enough 'putty' which is a free ssh client for windows but it also can do serial connections.  It's simple to use. You'll need to disable hardware flow control.
 
Also, you need to type '>' as in the example above:

>N42,SS,98,2
 
It's not a prompt but rather part of the command.
 
I was able to able t send the N10, SS,98,1,255 command and would get a E000, response from my lock and finally a X000 saying command was accepted but locks would not lock or unlock.
I also issue N10,SS,98,2 to get status of the lock but status was coming back with either 231 or 66 instead of 255 and 0. Even though I did the RS232 associations through the Leviton installler tool,  I was starting to think it could have been something to do with that. I tried to issue an association through the command line using Putty terminal program but it did not fix my problem.
The other thing that was interesting was when including my Zwave devices, it skipped over ID 9 so I might have had some other problems with my setup.
 
So I decided to start over. 
  1. Excluded all devices on the zwave network
  2. Reset my Leviton USB controller to erase everything
  3. Created a new network file
  4. Included the VRCOP (ID2) in new network
  5. Added the Kwikset locks (ID3 and 4)
  6. Setup RS232 associations with my controller (ID2)
  7. Tested locks by issuing N3,SS,98,1,255 and N4,SS,98,1,255. This time they did work!!!
  8. Added a couple of my Leviton switches to the network
  9. Retested locks by issuing N3,SS,98,1,255 and N4,SS,98,1,255. This time they did not work
  10. Went into associations and remove and readd associations RS232 to the controller (ID2)
  11. Tested locks by issuing N3,SS,98,1,255 and N4,SS,98,1,255. This time they did work again
Not sure why I lost my associations but when I added additions switches it continued to work. Not sure if this is a bug or I did something wrong. 
Still a little shaky on associations but from what I understand is the association are at the lock, switch...etc rather than than at the controller so you need to be close to the device when making these association. Does that sound correct?
 
For none leviton devices, do you have to always set the associations?
 
I also have a 4 scene controller (Leviton VRCS4) that I have not added. Are there anything special things that needs to be done when adding an additional controller to the network?
 
Thank You for the help
Carl
 
You are correct in thinking that associations reside in the device itself rather than in the controller.  However:
 
1. Associations are needed for status notification, e.g. instant status capable switches should know what controller they should notify about their status change.  Likewise, with locks, thermostats and sensors. 
 
2. Associations can be modified manually from the terminal, there's a command to establish/erase associations inside VRC0P.  The Leviton installer program makes it easier, but sometimes it is more convenient to do from a serial console.  You do not need to be in close proximity to the device unless your network is not optimized, and the controller cannot communicate with the lock.
 
3. Associations are not required to operate the lock.  Without any association, the lock would work just fine, it won't notify the controller about it's status change, though.
 
4. Your trouble with locks was likely caused by a sub-optimal network topology inside the installer USB stick. The routing map may have got sub-optimal  when you added additional devices. You may want to run network repair to optimize routing, probably with the installer stick located close to where your VRC0P is going to be permanently located so that the routing table were built accordingly. In fact, the route refresh exercise would be useful with any topology change.
 
vc1234 said:
You are correct in thinking that associations reside in the device itself rather than in the controller.  However:
 
1. Associations are needed for status notification, e.g. instant status capable switches should know what controller they should notify about their status change.  Likewise, with locks, thermostats and sensors. 
 
2. Associations can be modified manually from the terminal, there's a command to establish/erase associations inside VRC0P.  The Leviton installer program makes it easier, but sometimes it is more convenient to do from a serial console.  You do not need to be in close proximity to the device unless your network is not optimized, and the controller cannot communicate with the lock.
 
3. Associations are not required to operate the lock.  Without any association, the lock would work just fine, it won't notify the controller about it's status change, though.
 
4. Your trouble with locks was likely caused by a sub-optimal network topology inside the installer USB stick. The routing map may have got sub-optimal  when you added additional devices. You may want to run network repair to optimize routing, probably with the installer stick located close to where your VRC0P is going to be permanently located so that the routing table were built accordingly. In fact, the route refresh exercise would be useful with any topology change.
 
 Went through and did the manual association from the Putty terminal to make sure my associations were set and repaired the network. That definitely helped and now I can use the ELK to lock/unlock the doors. Thanks for the help.
 
The problem I am having is I have setup a rule to lock all doors 1 hr after sunset and thank works 90% of the time but ever now and then one of the two locks will not lock. I use the <LOCK^M command. Is better to issue individual lock commands?
 
Also, I am using Homeseer HS3 but cannot figure out how to issue those commands to the ELK M1. 
 
Thank You
Carl
 
Ckerch said:
The problem I am having is I have setup a rule to lock all doors 1 hr after sunset and thank works 90% of the time but ever now and then one of the two locks will not lock. I use the <LOCK^M command. Is better to issue individual lock commands?
In Elk, I've used individual lock commands without issues so far -- I automatically lock only one lock.  It may be possible that Elk loses one of the lock commands occasionally, it has to convert its lock all command into two or more VRC0P commands because VRC0p does not have a lock all equivalent.
 
If you feel motivated/curious, you can get an RS232 tap (https://www.google.com/search?q=rs232+tap&ie=utf-8&oe=utf-8&client=firefox-b-1) to capture the elk-vrc0p exchange commands until a loss happens to make sure who is the culprit.  That's what I did with my thermostats when they were losing set commands. To my dismay, I discovered that in every rare case it was Elk that was losing a command rather than zwave as I originally suspected.  Obviously, this knowledge did not help me much as I can do nothing about the loss.
 
Ckerch said:
 The problem I am having is I have setup a rule to lock all doors 1 hr after sunset and thank works 90% of the time but ever now and then one of the two locks will not lock. I use the <LOCK^M command. Is better to issue individual lock commands?
I know nothing about Z-Wave, but with Zigbee, battery operated devices are a type of node that require a nearby line-powered node to assist them. This line powered node keeps the lock status for them since they often shut down to save power.  Zigbee locks are a "Zigbee End Device (ZED)" and they do not perform packet relaying. A "Zigbee Router (ZR)" performs the heavy lifting.   I have no idea if Z-Wave operates similar, but if so, you may want to make sure you have some line powered Z-Wave devices near your locks.
 
The key thing is to also make sure whatever line-powered devices you use near the locks support "beaming" and secure (encrypted) mode.

Beaming is a Z-Wave term that allows wakeup of battery-powered devices

Secure mode I believe is also required in the repeater since the locks are all using it.
 
giesen said:
The key thing is to also make sure whatever line-powered devices you use near the locks support "beaming" and secure (encrypted) mode. Beaming is a Z-Wave term that allows wakeup of battery-powered devices Secure mode I believe is also required in the repeater since the locks are all using it.
Beaming, yes, encryption support by intermediate nodes is not required as the frame is already encrypted.
 
The OP can lock/unlock, it's just that "lock all" does not work when issued by Elk.
 
It took awhile because I had to get a RS232 Y cable to monitored the 232 line. Sure enough, I caught the ELK not sending the command to all the locks when using the "All Lock" command. Since then, I changed the rule to use individual lock commands instead of the "All Lock" command and that seems to fix my problem.
 
Thank You for the help
Carl
 
Back
Top