Leviton Zwave lock support

[picta]

The lock only supports 2 natively.
 
That's what I'm saying. You need 'something' (e.g. controller / software) to manage the additional codes. With my setup, I'd prefer that Elk did it.... but they don't.

If by "natively" you mean the codes that can be entered at the lock, than yes, there are only 2. These are user codes 1 and 2, and I would not recommend using them at all, exactly because it is so easy to change them. We are only using user codes 3 and above, and the access for codes 1 and 2 is disabled at all times. Regardless of whether Elk can process user codes or not, you can (and IMO, should) configure the higher user codes from PC hyper-terminal, or any software that can send ASCII codes to the Leviton port. I use windmill software, it's free and easy. Frankly, the ability to set the codes should be provided by the lock manufacture, and not an automation controller. This is a part of device configuration, and as Dean said, it would be next to impossible to track all of the parameters of all devices.

 

[drvnbysound]

Actually they could allow for such things, where it's reasonable. The same with setting up associations, which is just module configuration. One of the reasons for going with a software master controller is that it's not limited like a hardware one. They could easily provide that functionality. Well, not EASILY, but it's not that hard to do. It is a little more complicated due to the fact that there are not really any required standards for how it's done. So they'd have to have some knowledge of the lock types available. But there aren't that many of them that a large company like Leviton couldn't support that fairly reasonably.
 
But of course you could use any software that knows how to send commands via the VRCOP and supports the setup commands you want to invoke. It doesn't have to be done by the Leviton software. We could provide support for that sort of setup, but only if we are the one attached to the VRCOP. We already support sending generic configuration messages, which is how a lot of setup of module options is done. But, as above, there's not much in the way of standards so having a pre-fab interface for doing it would be a bit of work, since it would require a sort of database of all of the modules and what configuration options they have and what the possible values are, etc... So we just allow you to send the config message and you have to know what to send.

 
I absolutely agree (other companies have already done it), they [Leviton] have simply failed to do so [yet].

 

[drvnbysound]

If by "natively" you mean the codes that can be entered at the lock, than yes, there are only 2. These are user codes 1 and 2, and I would not recommend using them at all, exactly because it is so easy to change them. We are only using user codes 3 and above, and the access for codes 1 and 2 is disabled at all times. Regardless of whether Elk can process user codes or not, you can (and IMO, should) configure the higher user codes from PC hyper-terminal, or any software that can send ASCII codes to the Leviton port. I use windmill software, it's free and easy. Frankly, the ability to set the codes should be provided by the lock manufacture, and not an automation controller. This is a part of device configuration, and as Dean said, it would be next to impossible to track all of the parameters of all devices.

 
I'd love to know where I could find a list of commands that are available for use with the lock. I'd have no problem doing this myself, but I've never see a list of commands, or even the command structure to do so.

 

[picta]

http://s7d5.scene7.com/is/content/BDHHI/ApplicationNote-UsingASCII-Z-Wave-Locks

 

[drvnbysound]

http://s7d5.scene7.com/is/content/BDHHI/ApplicationNote-UsingASCII-Z-Wave-Locks

 
Thanks for that. I'll definitely be giving this a shot, as it solves a number of things I've been wanting to do for a long time.
 
I've got a couple of follow up questions:
 
1) I didn't see a "disable user 1" command, but I see that you can set schedules for individual user codes. Is this what you are using?
 
If so, I don't know that I follow what's written very well.... or should I say, it's not written very well.
a ) What defines "sid" and "wd"? Is that starting day and ending day, for access?
b ) It says, "For days you want to allow 24hour access: Use 0:0 to 24:59 (24 hour format) to enable access." I assume that's actually supposed to be 23:59 (??), since there are not 25 hours in a day...
 
Following that, "For days you do not want to allow the user access: Do not set a schedule command for that day." I'm not following what's needed for this. Currently, my user 1 and 2 codes have 24-hour access. How would I disable that access.
 
I see this statement, "Setting any one week day schedule automatically disables access for non-scheduled days. So remember to set week day scheduling for each day of the week, based on access needs." Which leads me to think I could set access for 1 minute, on one day (e.g. 0200-0201 on Tuesday), and that would disable all access, except for that singular minute @ 2:00am. I assume this is a suitable compromise, but it's not "disabled".
 
--------------------------------------
Following all of that, I'm interested to see how the XSLZW is will actually handle any of this. Sure, I'd directly connect my laptop to the VRC0P to do the user programming and scheduling, but after that, during standard use, I'd like to Elk to read in what code was entered and create rules based on that. What I mean from this... is that the Elk commands are completely different.
 
In the manual provided the LOCK command is:
>N#,SS,#,#,#
 
Whereas, Elk (from the M1XSLZW installation instructions) uses:
<LOCK1^M
 
Obviously, there is some command conversion going on here... which is what I'm interested to see how that's handled for the other commands (e.g. lock un-secured by user at keypad).

 

[picta]

You will need to set schedules for all codes to "disable" any. Yes, there is a one minute gap, you can change it periodically if there is a concern (but given the default 24 hour access this is still an improvement). I think you'll need to use a separate serial port if you want to receive raw strings into Elk.

 

[johnlaroux]

Don't forget you have to set the clock in the lock also if you want the schedules to work properly.