Premise Zwave sensors

[etc6849]

I finally figured out the secret generic class number (no thanks to Kwikset support). It turns out all that is needed is more brute force (e.g. Premise doing many iterations for me)

As you can see the secret constant no one wanted me to know is 64 (big deal). I'm assuming Schlage locks use the same constant for a generic device class, but I won't know until someone tries it. I'm not going to be purchasing a Schlage lock, but plan on purchasing two more Kwikset deadbolts as they are motorized and the Schlage are not.
>?FI0,64,0,1
>?FI0,64,0,1
<E000
<F002 - the lock is node 2

The new module with lock support is attached. It has been tested thoroughly for a Kwikset deadbolt. It tracks which user did what, lets you add or delete users, etc...

How to set things up for a VRC0Pv3:
Delete old module.
Add new ViziaRF to Custom Devices
Enable the check box VRC0Pv3 and input the node id under the ViziaRF device.
Select correct port.
Discover devices like normal (go to Devices then Discovery and toggle discover devices).
Wait a few minutes as the module will clear all UserCodes in the lock for users not being managed by SYS. Comment out the last part of sys://Schema/Modules/Leviton/Classes/User/OnChangeUserNumber if you don't want this to occur.

If your primary controller's software/firmware does not support encrypted associations and routing (mine did not; I use the Leviton RF Installer Tool), toggle AssociateWithVRC0P (necessary for two-way status to work) and SetRoutes (if you have other nodes that support beaming), but only after a successful discovery. These Boolean properties are found under the Device properties for the Lock object.

You can run two Z-Wave networks (two different home IDs), one VRC0Pv3 and one with a VRC0P. I recommend putting the locks, VRC0Pv3 and other beaming devices on their own network until the first firmware update for the VRC0Pv3 is released. Most devices you have will not route encrypted transmissions anyways, so currently there is no benefit to having everything on one network. It's better to have the VRC0Pv3 in line of site (or close by) the deadbolt, unless you have a routing slave that supports beaming. Schlage makes a lamp module that will route encrypted transmissions, but I don't have one to try. I plan to buy more deadbolts and this will take care of any signal issue I might have when I move the VRC0Pv3.

 

[etc6849]

Same directions as before. This update includes AlarmType = 23 for the case where the lock fails following a z-wave command to lock, but is optional. Now, following any failed command, the module will assume that the lock is unlocked.

I also added a tamperproof class.

Classes that I plan to add in the future: Clock class (will also be used for the trane thermostat as well as the lock) and Schedule class. Not sure when I'll get to these.

 

[etc6849]

I made a few minor improvements to the lock class (again).

I added a few more features:
1. now tracks when too many bad entries have been tried at the keypad (this was a much needed feature). You can add scripting to disable the keypad if the property TooManyBadEntries is set to true (via the tamper class I added).
2. sets events for too many bad entries and also for lock failures (you can set up Premise to email or text when events are set... there's an example on event handling in Builder's help files)
3. I modified how the lock behaves on a failure. It no longer sets unlocked to true, but sets an event instead. It's just a philosophy change. It wouldn't have actually unlocked the door before, but would only set the unlocked property to true (due to the receiving feedback flag).

 

[etc6849]

I discovered a new alarm state today:

112 - new user code is set
>N5SS99,1,1,1,50,49,51,49,50,49,51,49
<E000
<N005:152,128,162,239,024,049,014,093,190,107
<X000
<N005:152,064
<n005:000,113,005,112,001

 

[pbeaulieu]

Now that you mention it, I did notice this, but I haven't fixed it in the driver yet. This actually appears to be more correct than the old method as it appears it is no longer a leviton specific implementation of scenes: http://wiki.micasave...Command_Classes I'm willing to bet this was forced on them by Zensys.

I fixed the significant change in how FI is handled though. For the Premise module, I added a check box so that the user tells Premise which one they are using. I'm assuming Leviton will release a special firmware for users like you, but who knows. Hopefully HAI comes through and adds a check box functionality to toggle between the two protocols!

I'm still trying to get door logging to work. I've discovered some more status modes too. I'll post them in my other post above.

Here's how user codes work (I'm able to manage the locks from Premise now):

delete code for user 2:
>N4SS99,1,2,0

set code for user 2 as 1132 (NOTE: each pair 1|2, 3|4, 5|6, 7|8, 9|0 shares a button. 1132 could also mean 1232 etc...)
>N4SS99,1,2,1,49,49,51,49

Request user 1 data, returns user not set:
>N4SS99,2,1
<E000
<N004:152,128,214,112,063,035,141,000,157,114
<X000
<N004:152,064
<n004:000,099,003,001,000

Request user 2 data, returns user data from before:
>N4SS99,2,2
<E000
<N004:152,128,153,091,137,164,226,215,181,240
<X000
<N004:152,064
<n004:000,099,003,002,001,049,049,051,049

get max number of users (30) for the kwikset:
>N4SS99,4
<E000
<N004:152,128,063,087,073,050,089,041,022,201
<X000
<N004:152,064
<n004:000,099,005,030

You may already know this but Leviton is making changes to the VRCOP firmware. Don't know what they are doing specifically except addressing the HAI issue:

Leviton:VRCOP HAI Incompatability

Thought you might want to know.

 

[etc6849]

Thanks!

Do you know if HAI supports find (FI) with the VRC0P? If they change how FI is handled, I'll have to modify the Premise module. I also heard that LED indicator support is being added. This is kind of exciting since the indicator class is not supported by leviton scene/zone controllers...

 

[pbeaulieu]

Thanks!

Do you know if HAI supports find (FI) with the VRC0P? If they change how FI is handled, I'll have to modify the Premise module. I also heard that LED indicator support is being added. This is kind of exciting since the indicator class is not supported by leviton scene/zone controllers...

I have attached the Leviton VRCOP_ASCII_Programming_Application_Note.pdf which is part of the zip file for the VRCOP vers. 0.3 firmware. According to this document the FI command is supported. Leviton is a little slow on updating their documentation. They are probably sufferring from the too much work too few workers virus. Leviton seem not to provide detailed release notes but when you contact them they do provide the information.

 

[etc6849]

No, I'm asking if HAI supports the FI command via the VRC0P... If HAI uses FI, there will be more changes than just scenes when the latest firmware is released. This is because of the changes to FI in the VRC0Pv3's current protocol.

I have attached the Leviton VRCOP_ASCII_Programming_Application_Note.pdf which is part of the zip file for the VRCOP vers. 0.3 firmware. According to this document the FI command is supported. Leviton is a little slow on updating their documentation. They are probably sufferring from the too much work too few workers virus. Leviton seem not to provide detailed release notes but when you contact them they do provide the information.