Leviton Zwave lock support

[Frunple]

Anyone know if Leviton plans on fully supporting Zwave locks??
I tried asking them but they are apparently in a "no response" time I guess, maybe due to holidays.
 
What I mean is the ability to add codes, determine which codes unlocked a lock etc.
Right now they just lock and unlock, there's so much more these locks can do programming wise. 

 

[jlehnert]

No idea, but  I have big hopes now that Tom Morgan (formerly of Worthington Distribution) has been hired as product line manager.  It's been a few months, so any changes should start making their way through the pipeline about now.  The smartphone browser assist to the RF Installer Tool has the feel of something he would push.

 

[drvnbysound]

Plans to? No idea.
 
At one point, I thought I heard that the Leviton device (VRC0P) actually received that information, but as I read into it (the webinar video I was watching) it sounded like Elk was dropping (or not reading) that information into the XSLZW... basically saying there was nothing that would do with that information. At which point I was thinking.. WHAT?!?  1) I'd love to be able to manage all ~30 user codes as it's supposed to support (opposed to limited 2 that Elk supports as it doesn't act as a full controller for the lock) and 2) as mentioned above, I'd love to have Elk read in the code that was entered, allowing me to know what code was used to unlock the door, thus what user.
 
Part of what I recall from the webinar was that people could then program the door entry to also disarm the alarm, and that wasn't something Elk was "suggesting" be done; they didn't support that from a security standpoint. I don't disagree with that... because someone could stand outside my front door and enter codes until they got in, at which point it could also disarm the alarm if it was setup that way. However, I'd still like the capability of the things listed above. Right now, with 2 user codes, I'm limited to sharing codes among my family; not something I care to do. Maybe we should share bank account passwords too...    Having said that, I truly don't know where the limitation lies - whether with Leviton or Elk, but the way it sounded to me, that it was on the Elk side.

 

[swamiller]

I have a similar desire for my Zigbee locks. I was told the reason this functionality doesn't exist has to do with the power limitations and polling characteristics of the battery powered locks. Sending and receiving data like user code information uses to much battery.

 

[George M]

Leviton does indeed receive that info, but ELK does not utilize it. You can verify that be connecting via hyperterm. When I was having some trouble with my locks and we were doing troubleshooting with both Leviton and ELK, I was told by ELK that they had no plans to  include the user info.

 

[drvnbysound]

Leviton does indeed receive that info, but ELK does not utilize it. You can verify that be connecting via hyperterm. When I was having some trouble with my locks and we were doing troubleshooting with both Leviton and ELK, I was told by ELK that they had no plans to  include the user info.

 
That sounds like what I was hearing as well. I understand their lack of concern with integration of someone else's products, but that would be a VERY nice feature to have. I know I'd sure like the capability. It's a limitation that actually makes me want to switch to a Vera controller instead. I need to read more into the integration of Vera and Elk...
 
I have no interest in accessing Vera via WAN, and would prefer that it didn't have Internet access at all. I prefer the single interface (eKeypad) that I use now, for all of my needs.
Based on the above, I'd still want all automation logic (rules) to be activated and utilized via Elk. I haven't looked into this enough to know what the capabilities and limitations are.

 

[Dean Roddey]

The VRCOP does get that sort of lock info. We support reporting it in our VRCOP driver. Actually the Leviton just receives reports in general and passes them out through the serial port, so it pretty much reports out the serial port whatever the modules report to it (if they are associated with the VRCOP to send it async notifications.) I don't think it passes any judgment or restricts any of that info module status report stuff.
 
But, due to the battery thing, it's really only useful in terms of generating events, or whatever they are called in the system of your choice. When the automation system comes up, it can't read this sort of info from battery powered units (unless they stay awake all the time and most don't.) It really can only get the info when the unit is caused to wake up and send out something due to human interaction, motion detected, etc... The automation system can react to that info when it's received.
 
That's what we do with it. We have standard lock event type triggers and we send those out in response to lock status reports, which includes code (if relevant), lock event type, new locked/unlocked state, and of course the configured name of the unit. So all you need to react to it and do something useful. So you just configure our event server to react to these lock event triggers.

 

[drvnbysound]

Yeah, I figured it would. The main issue, is having a controller that will support/enable more than 2 codes to be used. With only having the 2 codes, it's pointless for me to even try and read in what code was used - even if I could custom program it based on the ASCII string received.
 
On a regular basis, I don't have a flood of people entering my home. However, I'd prefer that anyone who enters my home have their own individual code. It's really no different that having individual user accounts on a computer used for security applications. You don't want shared accounts, because you have no user granularity, particularly when there is a breach in security.

 

[Dean Roddey]

By controller, do you mean master controller in the sense of allowing for configuration? If you are using the VRCOP, the Leviton software doesn't allow you to do what you want to do?
 
Or do you mean the back end in some way only being able to handle two? The back end should just receive whatever is sent. I guess if it only allows you to configure some response based on two known codes that could limit it. But it certainly should get any that are sent by the lock.

 

[drvnbysound]

By controller, do you mean master controller in the sense of allowing for configuration? If you are using the VRCOP, the Leviton software doesn't allow you to do what you want to do?
 
Or do you mean the back end in some way only being able to handle two? The back end should just receive whatever is sent. I guess if it only allows you to configure some response based on two known codes that could limit it. But it certainly should get any that are sent by the lock.

 
Yes. As far as I know, the VRC0P does not allow you to use it to manage codes for any lock. The Leviton software (RF Installer Tool) is only used in conjunction with the VRUSB (or similar) to add/remove devices, set associations, and transfer the configuration to secondary controllers (such as the VRC0P).
 
I actually don't remember if there is a controller other than Vera that has this functionality... assuming the current version still does, I know they used to.

 

[picta]

Yeah, I figured it would. The main issue, is having a controller that will support/enable more than 2 codes to be used. With only having the 2 codes, it's pointless for me to even try and read in what code was used - even if I could custom program it based on the ASCII string received.
 
On a regular basis, I don't have a flood of people entering my home. However, I'd prefer that anyone who enters my home have their own individual code. It's really no different that having individual user accounts on a computer used for security applications. You don't want shared accounts, because you have no user granularity, particularly when there is a breach in security.

 
Why only 2 codes? I think Kwikset supports up to 30.  We are currently using 8 via VRC0P and homeseer.

 

[drvnbysound]

Why only 2 codes? I think Kwikset supports up to 30.  We are currently using 8 via VRC0P and homeseer.

 
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.

 

[Dean Roddey]

Yes. As far as I know, the VRC0P does not allow you to use it to manage codes for any lock. The Leviton software (RF Installer Tool) is only used in conjunction with the VRUSB (or similar) to add/remove devices, set associations, and transfer the configuration to secondary controllers (such as the VRC0P).
 
I actually don't remember if there is a controller other than Vera that has this functionality... assuming the current version still does, I know they used to.

 
The VRCOP is just a secondary controller. It wouldn't be involved in the configuration of modules, that is true. All that matters with it is that it report lock events, which it does. If the Leviton software doesn't explicitly provide support, and doesn't provide some means to send messages generically, then yeh, you would need some other bit of software that can do that initial setup of the codes.
 
Of course one problem is that, if it's batter powered and of the sort that only wakes up to report some human interaction, or wakes up only periodically to say it's alive, configuring it via the Z-Wave network would be a pain. You'd have to go turn the knob or press a button to wake it up, then run back to the controller and make the changes before it goes back to sleep. Or the software would have to remember the changes and the next time the thing wakes up to report its alive or to send a change, to quickly grab it before it goes back to sleep and send the changes.

 

[drvnbysound]

The Leviton VRUSB-1US is a primary (USB) controller that is used in conjunction with the Leviton RF Installer Tool software. The combination of USB stick and Leviton software are used to add/remove/manage Zwave devices. However, to my knowledge, there is no place within their software that allows for the additional user PINs to be programmed for the locks. [Why should they? Leviton doesn't manufacture locks.]
 
In the Leviton/Elk ecosystem, once the Zwave network is setup with the VRUSB and RF Installer Tool software, the VRC0P is then transferred the network information as a secondary controller. The VRC0P is connected to the Elk, via the M1XSLZW (serial interface), and the VRUSB is no longer used/needed (until you want to add/remove devices, and reconfigure the network).
 
The Kwikset locks are battery powered, and require other Zwave devices that support 'beaming'... which wakes them up when needed (e.g. sending the lock a lock/unlock command). The locks do, however, support instant status feedback. That is, if a user manually locks/unlocks, or uses the keypad to lock/unlock... it will instantly report that status. Having said that, Elk can easily track whether the deadbolt is locked or unlocked (via ASCII commands), but cannot tell me what code was used to open it... and only 2 codes can be used.

 

[Dean Roddey]

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.