Premise Zwave sensors

Motorola Premise
Try this doc out (scroll to bottom of pdf for config class variables): http://oldsite.rcstechnology.com/docs/thermostats/zwave/TZ43%20INSTALLATION%20MANUAL%20141-01652-04.pdf

I know it says RCS, but I have a "theory" that the Trane tstat is very similar to the much more expensive RCS version. It contains parameter 25 and many others, but no 132... Still researching 132 :(
Good theory, except...

The doc says parameter 25 is the setback mode, which can be 0 or 1.
Code:
25 SB Mode 0 1 Setback mode, 0 = No Setback, 1 = Setback
From a post further up in this thread, the actual config command is returning a value of 2, which doesn't align with what the documentation says.
Code:
00000006 22.24174690 [1844] OnChangeOnNewData(): <3/27/2011 1:43:16 PM> rxtextline=<N003:112,006,025,001,002
 
you're right! I was only looking at this line: <N003:112,006,025,001,000. The thermostats do look identical, but there must be a firmware difference for the schlage/trane version, doh!

unfortunately, my post wasn't much help other than we now know asihome was able to get the secret codes (somehow). I emailed my asihome/worthington contact... I'm hoping he's willing to share or give hints ;)

PS: what is the full meaning of an ascii output from the VRC0P code like this: <N003:112,006,025,001,000?

I know 112 is zwave command class (112=configuration) and I know 25 appears to represent some function that is a subset of the configuration class. However, I have no idea what the 006, 001 or the 000 really mean other than one of them must represent a value for the function represented by 25. Thanks in advance :)
 
Mark, you really added a lot to this module... Your work is very nice and much appreciated! I can't wait to see what else you add to the final version :)

I'm curious if you have a Vera and if you've tried the VRC0P emulation plug-in? It's in beta, but I think you can download it from their site (I don't have a Vera or I'd try it). The plug-in is one potential way to use z-wave locks with Premise (assuming Vera's emulated protocol allows for lock control). The plug-in is in beta and I haven't read anyone using it...

Chuck: another option would be to contact homeseer and see if they'd supply you with the protocol for the z-troller:
http://store.homeseer.com/store/Z-Troller---Z-Wave-Primary-Controller-PC-Interface-HomeSeer-P214C44.aspx

If homeseer would give you their z-troller RS232 protocol docs (which they may not as they may want people to use their software instead of a free option like Premise), you could build a module for using z-wave locks via the z-troller. This could be done in builder pretty easily and you could even use 80-90% of the VRC0P's module as a template ;)

Etc, the ztroller is made by Cooper as part of the 'Aspire RF' line and their protocol is readily available. I've made a copy of it easy accessible HERE. It's an ASCII protocol similar to the Leviton but A) supports beaming and B) is a primary controller!

Cheers!
 
Right, but who makes the z-wave RCS thermostat? I'm assuming RCS makes all three?

I own one RCS TZ43 and two of the Trane thermostats. The Trane thermostats have a slightly different PCB (the thermostat wire connection points are all on one side, whereas the "real" TZ43 has it split into two banks, and has extra points for external sensors)

However, ALL THREE of my thermostats have an "RCS TZ43" written on the PCB itself.
 
Not sure if this is the right thread, but.

ZWAVE - ready to dive in. I know to get the new VRCOP, BUT is ZWAVE universal? Or does it differ from manufacturer to manufacture? If I buy the kwikset door lock, can I use it for GE or other products.

I just realized that things might be moving too fast even for a tech savvy geezer like me
tongue.gif
 
Z-Wave is mostly universal. However, some features are manufacturer specific (Leviton's scenes, groups, and status feedback). Further, there are several versions of the zensys protocol; only the newer versions work with locks and security devices. In short, you really want to make sure whatever primary controller you select is updatable. I would go with the ControlThink ThinkStick (with the ControlThink software) or the Leviton RF Installer software (free) and the Leviton USB stick. ControlThink is now owned by Leviton, so it really doesn't matter which you pick. The ControlThink ThinkStick will work with Leviton's RF Installer software too, so it's a good idea to get the ControlThink Professional kit (stick plus software) I think. Be sure to update the firmware to the newest version.

The USB sticks are a lot better than the handheld primary controllers. Of course, you still need the secondary controller (VRC0P) that interfaces with Premise. I also recommend the Trane/Schlage thermostat.
Kwikset locks are the one's I ordered, but they haven't arrived yet so I can't say anything about them.

Why don't you register here and take the vizia rf training courses: http://ezlearn.leviton.com/el_front/ It's free and provides a lot of great information. After creating an account, log-in and go to residential products.
 
You're welcome! Thanks to Mark and 123 too who built all of the elaborate code to make all of this possible :)
 
Lock support is slowly progressing. Working so far: UserCode (allows you to manage user codes through SYS), Alarm, Battery and Lock.

I finally have the Alarm class working with the Kwikset deadbolt from Asihome/Worthington. Leviton helped me to realize that even though their RF Installer Tool showed the lock was associated with the VRC0Pv3, it really wasn't!?! It seems the RF Installer tool does not properly associate secure devices... for now. The engineer at leviton emphasized that this is how things are "for now."

In the mean time, you must use the an association command to properly associate the lock with the VRC0Pv3:

associate controller (48) with lock (49)
>N49SS133,1,1,48

The module will do this automatically for you once I finish things off.

Here's what the VRC0Pv3 and Kwikset do on manual actions:
lock inside using deadbolt lever or from outside using key:
<N049:152,064
<n049:000,113,005,021,001

unlock inside using deadbolt lever or from outside using key:
<N049:152,064
<n049:000,113,005,022,001

unlock outside via keypad:
<N049:152,064
<n049:000,113,005,019,001

lock outside via keypad:
<N049:152,064
<n049:000,113,005,018,000

unlocked z-wave:
>N49SS98,1,0
<E000
<N049:152,128,162,227,030,186,237,175,104,032
<X000
<N049:152,064
<n049:000,113,005,025,001

locked z-wave:
>N49SS98,1,255
<E000
<N049:152,128,050,045,150,255,042,186,048,173
<X000
<N049:152,064
<N049:152,064
<n049:000,113,005,024,001

Lock fails to lock
Most likely due to a door alignment issue. I had to force it to fail to get this code. The lock will try to lock 3 consecutive times before giving up.
<N049:152,064
<n049:000,113,005,017,001

too many bad code entries from outside (seems to lock out the electronic portion of the lock for ~45 seconds too):
<N049:152,064
<n049:000,113,005,161,001

You can imagine the neat things you'll be able to do with this level of status feedback! If deadbolt is locked from the inside, arm stay mode; if some is trying to guess your keypad code, sound an alarm; if you unlock from the outside (via keypad), turn on entry lights before you open the door...

There is one issue so far with the module and Leviton is seeing if they can replicate it: when I send a crap load of on/off commands to the VRC0P one at a time (waiting for X000 then immediately sending the next), the VRC0Pv3 locks up! The old model can toggle lights continuously all day... Leviton has been kind enough to look into this issue, so more to come.

This isn't a deal killer for someone with multiple VRC0P's! I can use one exclusively for locks and thermostats, and use the other for my lights. Good thing Premise is flexible like that!
 
Lock support is slowly progressing. Working so far: UserCode (allows you to manage user codes through SYS), Alarm, Battery and Lock.

I finally have the Alarm class working with the Kwikset deadbolt from Asihome/Worthington. Leviton helped me to realize that even though their RF Installer Tool showed the lock was associated with the VRC0Pv3, it really wasn't!?! It seems the RF Installer tool does not properly associate secure devices... for now. The engineer at leviton emphasized that this is how things are "for now."

In the mean time, you must use the an association command to properly associate the lock with the VRC0Pv3:

associate controller (48) with lock (49)
>N49SS133,1,1,48

The module will do this automatically for you once I finish things off.

Here's what the VRC0Pv3 and Kwikset do on manual actions:
lock inside using deadbolt lever:
<N049:152,064
<n049:000,113,005,021,001

unlock inside using deadbolt lever:
<N049:152,064
<n049:000,113,005,022,001

unlock outside:
<N049:152,064
<n049:000,113,005,019,001

lock outside:
<N049:152,064
<n049:000,113,005,018,000

too many bad code entries from outside (seems to lock out the electronic portion of the lock for ~45 seconds too):
<N049:152,064
<n049:000,113,005,161,001

You can imagine the neat things you'll be able to do with this level of status feedback! If deadbolt is locked from the inside, arm stay mode; if some is trying to guess your keypad code, sound an alarm; if you unlock from the outside (via keypad), turn on entry lights before you open the door...

There is one issue so far with the module and Leviton is seeing if they can replicate it: when I send a crap load of on/off commands to the VRC0P one at a time (waiting for X000 then immediately sending the next), the VRC0Pv3 locks up! The old model can toggle lights continuously all day... Leviton has been kind enough to look into this issue, so more to come.

This isn't a deal killer for someone with multiple VRC0P's! I can use one exclusively for locks and thermostats, and use the other for my lights. Good thing Premise is flexible like that!


If you are using the new VRCOP for Levition Vizia RF+ lights you should be aware that Leviton has changed the status reply for lights. I have an HAI Omnipro II that replaced the older VRCOP with a brand new VRCOP RF+ 3 on the back (just got it from Worthington). What I noticed was that when the Leviton Vizia RF+ lights are activated at the switch the Omnipro II does not get the status. So I hooked up my laptop with a serial port to the VRCOPs one at at time and look at the status coming out of the serial port of the two VRCOPs. This is what I got:

The older VRCOP sends this out the serial port when a light changes state:
<N002:130,001
<N002S000,255,000
<N002:130,001
<N002S000,000,000


The new VRCOP sends this out the serial port when a light changes state:
<N004:130,001
<N004:044,003,000,255,000
<N004:130,001
<N004:044,003,000,000,000

Notices that the format has changed for status of lights both switches and dimmers. They have also changed there documentation. It's kind of a pain to have such a change when the part number is still the same. This explains why my OmniPro II is no longer seeing the status of my Leviton lights. I opened a case with HAI but have not gotten any feedback.
 
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.micasaverde.com/index.php/ZWave_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
 
Here's another feature to the lock protocol:
get status
>N49SS117,2
<E000
<N049:152,128,009,025,045,033,136,051,194,240
<X000
<N049:152,064
<n049:000,117,003,000

disable keypad
>N49SS117,1,2
<E000
<N049:152,128,225,227,237,100,075,161,125,236
<X000

get new status
>N49SS117,2
<E000
<N049:152,128,161,193,046,107,196,068,014,010
<X000
<N049:152,064
<n049:000,117,003,002

re-enable keypad
>N49SS117,1,0
<E000
<N049:152,128,255,103,047,252,122,096,216,172
<X000
 
I think I just solved my door logging class issue: abandon it!

Leviton says to contact Kwikset and Kwikset/B&D support seems useless on such questions.

Work around:
If user 5 unlocks the door we see (my previous post on manual operations was with user 1):
<N049:152,064
<n049:000,113,005,019,005

Then user 3 locks it (requires user 3 entering code then hitting lock otherwise, user will show as 000 which I guess means system):
<N049:152,064
<n049:000,113,005,018,003

Unlocked by user one (note a one is also appended on actuation via the lever and key, this will be ignored):
<N049:152,064
<n049:000,113,005,019,001

If we let Premise manage the user data, things are just easier!

EDIT: Why door logging doesn't work:
I can request a door logging record, but nothing is returned (this should return user 3):
>N49SS76,3,3
<E000
<N049:152,128,022,145,195,164,010,177,024,186
<X000

However, if I iterate through zzz=0 to zzz=255 for >N49SS76,3,zzz, I obtain the following resutls for record 3. Note that zzz in the working commands below appears to be random (e.g. encrypted). If I rerun my script to iterate through zzz=0 to zzz=255 again, I obtain completely different zzz values. I'm wondering if this is intentional on Kwikset's part or if the VRC0P is not encoding the entire command for some reason?

>N49SS76,3,2
<N049:152,064
<N049:152,128,214,219,134,062,178,093,161,054
<n049:000,076,004,003,007,208,001,004,016,031,012,015,005,005,054,054\
<n049:053,048,050

>N49SS76,3,10
<N049:152,064
<n049:000,076,004,003,007,208,001,004,016,031,012,015,005,005,054,054\
<n049:053,048,050
<N049:152,128,053,112,064,040,050,036,180,157
<X000

>N49SS76,3,50
<N049:152,064
<N049:152,128,193,231,191,090,035,216,240,168
<n049:000,076,004,003,007,208,001,004,016,031,012,015,005,005,054,054\
<n049:053,048,050
<X000

>N49SS76,3,140
<N049:152,064
<n049:000,076,004,003,007,208,001,004,016,031,012,015,005,005,054,054\
<n049:053,048,050
<N049:152,128,245,099,144,142,246,015,187,162
<X000

>N49SS76,3,175
<N049:152,064
<N049:152,128,092,177,019,095,115,043,076,116
<n049:000,076,004,003,007,208,001,004,016,031,012,015,005,005,054,054\
<n049:053,048,050
<X000
 
Back
Top