Leviton RZC0P RS-232 Z-Wave Driver

[noworries]

I have built a functioning driver for the Leviton RZC0P Z-Wave Serial Controller. The driver controls their Vizia-RF line of switches and dimmers, and will list any thermostats but not do anything with them at this point.

Leviton devices (dimmers and switches) report their status asynchronously so a simple ear to the ground poll works for them, and that's what's implemented. Devices from other vendors may not play well, therefore. A rolling device by device poll could be implemented if desired. Leviton also provides queryable user-specified names with their RZCPG master controller, so we get those names as well.

You can toggle the switches on and off. For dimmers you can also toggle on-off, report and set (or inc/dec) the level, and do a press and hold ramp up or down to the desired level.

The driver will certainly handle thermostats, but I don't have one and haven't spent time looking at the terse Leviton protocol example.

Driver fields are all created dynamically based on the device type and node assignments. It seems necessary to go slowly when attempting to pull status and names from all the devices, so it takes a couple of seconds for each device to be added. Thus, the driver could take a while to connect for a large installation.

My installation includes six dimmers (incandescent and magnetic) and one switch with another half-dozen dimmers in boxes yet to install. The driver will find and configure fields for them all, but I've only built a prototype interface form that controls one device. See the attached documentation for a picture.

Edited to add the documentation file. Note, the driver will need some further work to handle network reconfiguration events, but it seems to behave with an existing network. Give it a try.

Edited: 1/4/08 Version 0.13 -- provides a proper group for AllOn/Off commands and streamlines the connect process to retry individual nodes before throwing a timeout. Implements round robin polling and faster async event processing. Also will recycle itself to incorporate external network changes (adding or removing devices).

[Squintz]

That's awesome. Why the limitation on the thermostat? I need to buy an RZC0P first but I will be trying this driver out eventually. Is it truely limited to Vizia RF devices? I'm guessing because of the method of polling. This is a big limitation but it's still nice to have some other user editable z-wave driver.

[noworries]

That's awesome. Why the limitation on the thermostat? I need to buy an RZC0P first but I will be trying this driver out eventually. Is it truely limited to Vizia RF devices? I'm guessing because of the method of polling. This is a big limitation but it's still nice to have some other user editable z-wave driver.
I just haven't implemented a round-robin poll that will cycle through all the devices. That would be easy enough to do. The driver presently looks for async messages on three second intervals, and issues an ">UP"date command each 30 seconds. The async picks up the two-way responses that Leviton and its private labeled devices send when manipulated manually. The Update command is as much for a connection verifier than anything. Its designed to broadcast changes initiated through the RZC0P to other controllers, as I read the Leviton protocol. A round-robin poll wouldn't be hard, but it'd be nice to see how other brands behave first. What happens, for example, if names aren't supported by the device when a get name query is sent?

As for thermostats, I could take the brief examples in the Leviton protocol document and go with them, but, for example, the document discusses querying a "multi-level" sensor to get the current temp. That may or may not be a different NodeID than the thermostat. Probably is, but I don't know. Then, there are thermostat fan modes (manual, auto) but incomplete information about them. Take a look at the Leviton protocol examples at the end of the document and see what you think. Its on the VisiaRF website under documentation.

[Dean Roddey]

I would think that you want ot check for asyncs quicker than every 3 seconds. There's not much of a problem to check for a new message every half second or so, just don't wait for very long. So check with a 50ms timeout and if nothing shows up, you are done, else process what's there. Otherwise, you could overflow if a lot of events happened while you were away and you'll greatly lower the latency to see the results of changes.

[johnnynine]

Finally, a Vizia RF driver :-)

I've written a Vizia RF .Net class library that supports all of the documented RZC0P commands and an application to go along with it as you may have seen over at cocoontech here (http://www.cocoontech.com/index.php?showtopic=9051&st=0&p=78523&#entry78523).

I'd like to compare some notes...

1. What are you doing to get the list of nodes? I'm basically doing a find (>FI...) on each basic class and generic class combination. This works well, but I'd like to find a better way.

2. Why are you sending >UP every 30 seconds? You should only need to send >UP after sending certain commands like changing a lights level. The light levels will come in automatically as they are changed by other means (manually by person at switch or remote).

3. I have found that round robin polling takes about 30-60 seconds to fetch the levels of 30ish nodes and isn't always successful... ie, you aren't guaranteed that you will received a response when polling even when the request is successfully sent.

4. Can events be triggered from changes in light levels? If so it sounds like you would have this as an "on light level received" event as opposed to "on light level changed". I assume this because I believe you mentioned you are not doing an up front poll of levels. IMHO, from experience "on light level changed" is the way to go. Also you may not be seeing it in your small set of nodes, but the RZC0P can report light levels more than once when the light only changed state once. I see this quite often.

5. Have you implemented an "on controller button pressed" event? People will likely want this.

6. People will also want to set scenes.

7. People will also likely want to use RZC0P groups.

8. Also, I'm not familiar with how CQC drivers are implemented, but do you have to read from the serial port on a timer? If not, it would be best to read the serial port when data comes in on the serial port as opposed to every 3 seconds. (But I'm not sure if CQC offers a "on serial data received" event.)


It's great to see a driver for the RZC0P. FWIW, Elk will be releasing their firmware for the RZC0P soon, but this would be great for those without an Elk M1 or HAI Omni, or even a nice supplement for those who do.

Thanks,
Johnny

edit: added #8.

[Dean Roddey]

The driver is called back to check for messages, but it can be as low as 100ms. The general scheme, for devices that send async messages, is to use a low callback time and do a fast check, with a very short wait, for any asyncs and if nothing is there, just return.

[johnnynine]

I see, thanks for the clarification Dean.

Noworries,

It generally takes about 2 seconds for the RZC0P to report a state change. So for instance if you manually turn on a light, you won't likely receive the notification from the RZC0P for about 2 seconds. So checking at least once per second would be ideal.

One thing that I didn't indicate before is I believe that another issue with sending >UP every 30 seconds is that (as I recall) it may only retrieve the levels of the active association in the RZC0P? (I've been on vacation so my memory is a little fuzzy.) So if you turn on node #2 without sending >UP and then turn on node #3 and then send >UP, you may only receive node #3's level since it is the current association. Same goes for commands done on groups and multiple nodes....?

Also I believe >UP is intended to be used to update the network so all controllers in the network receive the the state changes made. It's my understanding that this should usually be done after any command that changes the state of a light so that other controllers are aware of the change.

[noworries]

Johnnynine,
I don't have time for a full reply right now, but I have since implemented a 500ms interval check for async messages and a two second interval round robin poll of active devices that polls one device each round. The async poll picks up the replies. I've ditched the "Up"date poll for the reasons you mention but do issue that command when I initiate a device change. I've not posted the version yet, but will.

The biggest issue I've seen is that when doing the initial connect I'm looping over the active nodes (found using the >FI command as you indicate), getting the level (>?Nx) then issuing a >?NN to get the name. I've found that the replies are sometimes out of order (data before the <X000 Ack), or there are transmission errors (<X002), and sometimes also multiple replies as you suggest, or even a silent failure for a given node to reply with its name. The "level" data is more consistent. So, it will sometimes take up to three tries for the drive to get a full set of node initialization data. I have played around with all sorts of sleeping intervals between sending above commands, waiting for replies, etc. I'd hate to implement a two second pause for each of the two commands sent to each device during connection, but maybe that's required. I haven't gone that far, yet. I'd appreciate any insights you have in this area. Are you for example building up an association list and initializing names with a single query? I haven't had much luck doing that myself with Hyperterminal and half wonder if its my network topology as one group of devices is currently a little remote from the others. The biggest offenders are two dimmers each at the end of separate three gang boxes containing three dimmers. One box is close in, the other is more remote. These two devices also don't like reacting to the broadcast allon/off command (>N,ON - >N,OF) that I've also now implemented. So maybe it is largely a network issue.

I've had very good luck with getting data updates once the connection is established and nodes initialized, however. That seems solid.

I've now got seven dimmers and one switch in the network and hope to add another several dimmers this week. This will improve the topology as well. So, I'm motivated to get this working.

[johnnynine]

I've got over 50 nodes and I get similar results when retrieving node names and levels. For the <X002 errors, I just implemented a retry mechanism (it defaults to 3 tries). As for things coming in out of order, for me it doesn't matter since I read the serial data on a separate thread and implemented a queue to hold incoming <X and <E, everything else gets processed as it comes in behind the scenes. You'll have to add some somewhat non-elegant logic if you must use a single thread.

As mentioned before I basically process all responses on a separate thread. As soon as data arrives I read it into a buffer and then loop over the buffer while there is anything that ends with a CR or CRLF. I then immediately process any of those complete responses. For found nodes, light levels, names, etc, I just update the associated node object's attributes and create the node object if it didn't already exist. I then fire any events, like "node level changed", "received node level", "found node", "node name received", "controller button pressed", etc. Any <E or <X responses are added to a queue for the sender thread to pick up and process while sending commands.

I also get <X002 errors for no apparent reason sometimes. And it does take a while to get all names and levels especially when you have a lot of nodes like I do. After 3 retries I move on to the next node and then make another 2 complete passes over the nodes for any missing names or levels.

<FI ... even returns nodes that don't even exist in my network.

There is no guarantee that the broadcast commands will reach all nodes and there is no response back to indicate if they did. You are better off creating an RZC0P group with all nodes if you need it to be more reliable.

PS: How did you like that RZC0P protocol documentation? I don't think the author's English is quite up to the Leviton quality - not to mention some errors.

[noworries]

I've posted a 0.13 version at the head of this thread that handles AllOn and AllOff commands via a group that is much more robust than a broadcast command. This version also works harder to get each node added, retrying multiple times when the device does not cooperate. It always connects now in my system without recylcing through the entire network.

Also, round-robin polling now occurs device by device at 2 second intervals, while async events are processed on half-second intervals. External network changes are incorporated automatically by forcing the driver to recycle and recreate all the nodes and related fields. Its up to the user to keep the interfaces sync'd up with the network node IDs. We'll build the fileds based on what's out there.

Subsequent versions will support user defined groups, although these will probably need to come from an external config file. I may also take a crack at thermostat control from what's provided in the Leviton Documentation.

[Hiller]

It generally takes about 2 seconds for the RZC0P to report a state change. So for instance if you manually turn on a light, you won't likely receive the notification from the RZC0P for about 2 seconds. So checking at least once per second would be ideal.

I was thinking about getting the RZC0P so that I could get much faster comms to the computer for triggering purposes. Is everyone's experience with this unit the same as far as the 2 second time delay before the message gets to the computer? I would have thought that with the async message that gets sent it would be less than say 100ms. If eveyone is seeing the same response time, what is the reason for it and why would someone want to change from the Intermatic USB stick to the Vizia Serial connection?

Thanks,
Hiller

[noworries]

With hyperterminal connected, turning a dimmer on or off from minimum brightness results in a quarter to half second delay, then two lines of data on maybe third second intervals, tick..., tick. The update is received before the light ramps up or down from full brightness. Refreshes on an inc/dec cqc control lag slightly, but not horribly. I'm not sure what you're looking for, but the field updates are not unreasonably behind the device in my opinion.

As to why one would switch, I don't think the intermatic stick picks up async traffic, and relies on round-robin polling to get updates, right?

Also, if I ever finish the scene and group control, you could build them in a file. The intermatic driver does not support scenes.

The RZC0P will conceivably handle all zwave device types if one had the full command and control class document available to zwave alliance affiliate and higher members. If I allowed a free-form write field the driver could support one-way control now of those devices if you you knew the commands to send.

In its present form the RZC0P driver gets async updates, but does not support groups, while the reverse is true of the current CQC intermatic stick driver. I'm working as I have time on the groups and scene control.

[George M]

Is there any more advancement on this driver?
Can it be made to support the 2.3.xxx versions of CQC.

Right now I am using the RZC0P through my ELK system, but am unhappy with the response time between motion detected and lights coming on. I was hoping to switch to CQC control and find out if that would improve things.
However it will not install. It says it is not compatable with this version.

Since I just installed CQC, I starte with the 2.3.7 version.

Thanks
GM

[Mikla]

Not sure what the latest status on this is, but since have decided to go with Leviton. If nobody objects, I may pick the advancement of this driver in the near future and run with it.

[Squintz]

Mikla, talk to Jonathan about his Z-Wave driver. I don't know what the progress is on that either since he is such a busy guy but I truely think his driver has much more potential in being flexible. It's based on the ControlThink SDK which is constantly updated.

[Mikla]

Anyone have this driver installed and can repackage or dump the code and manifest to a text file so I can use it in the latest version of CQC?

It would be nice if there was a better way to upgrade beta drivers... that is why I always include the manifest and source files.

[Mikla]

I loaded CQC v1.2 in one of my Virtual Machines and repackaged the driver for those that need it.

[Mikla]

Just to give an update:

I have been playing with this driver and THANKS to noworries it does an excellent job. My focus was on making it more efficient. What I have done is:


//8/9/2008 v0.13.1 (by "Mikla") These changes should make polling more efficent
// and updates faster, including user initiated (at the device) changes
//Changed polling to 250 ms
//Process all messages on com port (replaced if/then with while loop)
// before getting specific device status in the poll method
//Got rid of 2 second and 5 second polling intervals
//Removed quotes around kCmd_NodeCmdPrefix in boolfldchanged method for node
//Removed all "sleep"s
//Changed GetASCIITermedMsg2 to GetASCIITermedMsg (easier to debug)
//Made several changes in error handling, ignoring many to minimize recycling the driver
//8/11/2008 v0.13.4 Improved performance by reducting getmsg to 20ms and implementing new CheckMessages method

It appears to be more stable and a lot more responsive. I am using Leviton Vizia RF + may may use the latest/fastest chip and this may be what allows me to get away with some of these changes, but I think logic works regardless of device speed. I still have some additional things I want to try.

[noworries]

Wow, my wife and I yesterday discussed my getting back into all this to "finish" up our CQC home installation and here's what I find when I surface. I've been diverted on all sorts of other initiatives for months now and apologize for abandoning this driver in beta state and consequently relegating it to the archaic CQC version.

Mikla, thanks for promoting the driver to the current CQC version and tightening it up. I'm not familiar with the RF+ improvements, but I'd spent more time than I'd like to admit stabilizing it with the earlier hardware and frankly had to move to other projects in part due to that. These efforts largely involved slowing the driver down, working device by device, and having retries when the replies were bad. Do you have any of the earlier Leviton "RZ..." devices? I did call Leviton today to see if the new RS-232 interface model differed at all from the earlier one and was assured no, and that it even used the same firmware. Hmmm.

Mikla, I will contact you separately regarding progress I've made with managing groups and scenes that I didn't post pending figuring out if they would conflict with those configured via the master controller.

Thanks, again. I will be more active again shortly.

[Mikla]

Here is a drop of the driver with my latest changes. There are a few extra fields (they start with Opt) for the optimization routine that you can ignore.

The driver and device responds very fast to IV inputs. I am still not happy with the response to a user initiated action (at the device or from a controller).

Anyway... thought some might be interested...

[rocker]

Here is a drop of the driver with my latest changes. There are a few extra fields (they start with Opt) for the optimization routine that you can ignore.

The driver and device responds very fast to IV inputs. I am still not happy with the response to a user initiated action (at the device or from a controller).

Anyway... thought some might be interested...

Mikla,

I'm interested to test the ViziaRF+ CQC driver. I downloaded the driver Do you have any prototype interfaces for controlling Leviton's ViziaRF devices that will utilize the feature set?

I downloaded "LevitonRZCOP-ZWave_v0_13_5_CQCv2_4.CQCDrvPack"
Is there a newer version?

I'm using the latest CQC 2.4.26 and after I imported the package, loaded the driver (didn't connect yet), I tried to create a sample action from a button to see what commands are available but the Interface Editor didn't list the driver at all).

All my dimmers and switches are ViziaRF and my master controller firmware was updated to ViziaRF+. I was told by Leviton that they are computable.

Thank you,
Rocker
------------

[Mikla]

That's the latest version.

I am a bit confused by you statement of "loaded the driver (didn't connect yet)". It should automatically connect if it finds the device (RZCOP) on the selected comm port.

I assume you have the RZCOP interface?

You may have to recycle the server to get the driver to show up in the editor....
Admin I'face ==> Server Drivers Button ==>Select Server==>Shell Log==> Cycle

[rocker]

That's the latest version.

I am a bit confused by you statement of "loaded the driver (didn't connect yet)". It should automatically connect if it finds the device (RZCOP) on the selected comm port.

I assume you have the RZCOP interface?

You may have to recycle the server to get the driver to show up in the editor....
Admin I'face ==> Server Drivers Button ==>Select Server==>Shell Log==> Cycle

Mikla,

Thanks for your prompt response, I wasn't around this weekend so my response is delayed: I don't know why I couldn't see the driver in the editor but I can see it now.
I'm using ot RZCOP via another system without any issues but prior to understanding the full features of the the driver I tried a small example of controlling one dimmer (#002): created a few buttons and send all the possible commands.
I faced with major delay from the time I issue the commands until the dimmer reacts (don't encounter this behavior when I issue the command from an RS232 terminal or the the other controller so I know that my ViziaRF system system is functioning correctly).

I don't know if it is related or not but, I also faced period of times (minutes) where the port was unable to connect to the RZCOP but after connection established the sluggish response or no response all together is taking place.

I can monitor the port using access port but too much bi-directional communication is displayed and scrolled in the window.

Any ideas? or direction to try

[Mikla]

Hmmm... I'll take another look at the driver, but it will have to wait until my controller gets back from being repaired (I dropped it and the LCD stopped working).

Once in awhile, I'll get some sluggish response, but certainly not on the order of minutes. I'll also get quite a few Timeouts, but no lost connections... not sure what is causing that.

You should only see a delay in the update of the IV, not in the device responding to a command (e.g., if you turn a light on, the light should turn on right away, but the IV may take a second or two to update). This is because the driver confirms that the light is really on. Another way would be to assume the light is on and then double check it when polling devices for their state (allows updating the IV faster) ... I'll look at that also.

There also may still be some issues with lost comm that you are seeing... that may be due to the way the driver is doing some error handling. There is probably a better way to do this... I'll look at it.

I have the ThinkEssentials SDK, so I use it for comparison purposes and the driver is a bit more sluggish than a simple app developed with the SDK. But that is expected given the nature of CML drivers. This driver should really be done in C with multiple threads to improve performance.

[Mikla]

I have started playing around with this driver again, but I keep coming up against the same reliability issues, timeouts, etc. I am farily convinced this is due to the restrictions with CML in dealing with handling events, polling for changes and processing user inputs without being able to kick off async processes.

Soooo... I was thinking, what do folks think about the development of a bridge application (possiblly running as a service) between a new driver and the ZWave system that would use the ControlThink USB Stick? It would look something like:

CQC[CML]<==>[CML]CQC Driver[TCP]<==>[TCP]SDK App[Serial]<==>[Serial]ControlThink USB or RS232[ZWave]<==>[ZWave] lighting system

I believe this would simplify the driver and make the system much more responsive. I think it would also make it more flexible if more classes were to be added. The SDK app would send out status strings that made sense and the driver could even be developed to look like the current driver to the IF.

I duuno, just a thought after spending a couple hours looking at ways to improve the current driver.

[IVB]

I'm open to anything. I just posted here (http://www.cocoontech.com/forums/index.php?showtopic=13033&hl=) about my initial findings about the VRCOP with the Elk, the biggest concern is the Elk seems to be a fire-and-forget, which defeats the whole damn point of a 2way communication protocol.

I just tried this driver to see if it was a better path, and am stuck on "Wait for Connect", but I want to confirm no level 0 (physical wiring) issues before whining about it.

EDIT: BTW, i'll throw you some $$ to add polling for non-Vizia switches into this, whether it's via an interim app or natively. i've got 16 existing intermatic switches & dimmers, it will cost a shitload to replace them all with Vizia. I.E., much more than i'm allowed to spend.

[Mikla]

I currently have a multi-client/server app working in rough form. I still have a couple of bugs, but it basically replicates the current driver functionality, but allows multiple clients to connect and communicate with the network. I still am working on the protocol but it will be something like:

>ONOFF,NodeID,Flag Flag: 0=off, 1=on, 2=status e.g., >ONOFF|4|2

The app handles timeouts and retrys. Once complete it will respond with:

<ONOFF,NodeID,Flag|Valid

or if there is a problem with the command, something like:

<|ONOFF,NodeID,Flag|Invalid Parameter (device not dimmable)

It is definitely easier to write this app and get better reponse since I can use the classed built into the SDK.

[IVB]

FYI, twilo posted some interesting comments (http://www.cocoontech.com/forums/index.php?showtopic=13033&st=0&#entry111200) about the rzcop integration he's doing with his own app.

[rocker]

I have started playing around with this driver again, but I keep coming up against the same reliability issues, timeouts, etc. I am farily convinced this is due to the restrictions with CML in dealing with handling events, polling for changes and processing user inputs without being able to kick off async processes.

Soooo... I was thinking, what do folks think about the development of a bridge application (possiblly running as a service) between a new driver and the ZWave system that would use the ControlThink USB Stick? It would look something like:

CQC[CML]<==>[CML]CQC Driver[TCP]<==>[TCP]SDK App[Serial]<==>[Serial]ControlThink USB or RS232[ZWave]<==>[ZWave] lighting system

I believe this would simplify the driver and make the system much more responsive. I think it would also make it more flexible if more classes were to be added. The SDK app would send out status strings that made sense and the driver could even be developed to look like the current driver to the IF.

I duuno, just a thought after spending a couple hours looking at ways to improve the current driver.

Mikla and noworries,

Your effort is very impressive. I took your 1.3.5 version, removed all optimization, remove all queries from Poll(), fixed two basic bugs in the Connect() code and enabled the asynchronous messages from the Leviton RF master controller or just use the default in the RF+ firmware and all works fine. I'm sure we can even lower some of the timing but the system is very stable and responsive.

I didn't encounter any of the issues you reported in the above message (CML related) and I don't see the need for any bridge application- your driver works!!

Again, the details and the structure were all coded by both of you), I just gave it a small final touch.

Please, test it.

Rocker

[Mikla]

Wow... that's great! I figured more performance could be gotten out of the driver. My Serial Port Server is out for repair (who knows what happened to it... or more likely, what I did to it) and once I get it back, I'll try driver.

Thanks for jumping in!

IVB... you should see if Rocker's mods work with your installation.

[IVB]

will do. i've gotten the mind-numbingly stupid idea in my head that I have the skills to build a 2' deep x 10' wide x 2' high planter complete with cosmetic beautifications, just got back from home depot with a crapload of lumber, so i suspect i'll be too damn sore tonight to try. (only reason i'm online is that i'm waiting for the water for coffee to boil...)

[Mikla]

haha... I know the feeling... 'cept mine is a kitchen remodel. Should have seen me (and a couple of my kids) putting an 800 pound double wall oven in the cabinet... talk about sore!

Then, when I brought the 42" 600 pound frig in through the front door, I slipped and the thing landed on me. Think my kids were concerned?.... nooooo... they stood there pointing and laughing.

[Squintz]

Mikla,

I hope you didn't dent your fridge when it fell. :-D

[potts.mike]

I am looking to upgrade my lighting controls because almost all of my intermaric stuff has quit. I have a couple questions on the functionality of this driver and the rzcop.

1. Does this work with zwave switches that are not vizia rf?

2.do I need any other remotes or controllers than the rzcop to get this working? How do I add dimmers to the network?

Thanks for any help, I might be upgrading in the next week or so.

[rocker]

I am looking to upgrade my lighting controls because almost all of my intermaric stuff has quit. I have a couple questions on the functionality of this driver and the rzcop.

1. Does this work with zwave switches that are not vizia rf?

2.do I need any other remotes or controllers than the rzcop to get this working? How do I add dimmers to the network?

Thanks for any help, I might be upgrading in the next week or so.

1. I haven't tested it with non ViziaRF or ViziaRF+. I know that Leviton become more and more compatible with other brands that support Z-wave, but I will not surprise if others didn't fully implement the protocol.

2. There is a remote which is the master controller. This Master Controller is the brain of the system and you use it for maintenance and setup including adding new nodes and configure scenes - all are very easy and menu driven.

Over all I have good experience with ViziaRF, can recommend using their technology and you can find them in your electrical specialty places (or online).

[potts.mike]

so before I go out and buy stuff I want to double check what I need. The programmer controller is item rzcgp and is about $100. Then I need dimmers or plug in modules for everything I need to control and then the rzcop to allow cqc to control the system? A ground wire is required at all switch locations as well?

[rocker]

so before I go out and buy stuff I want to double check what I need. The programmer controller is item rzcgp and is about $100. Then I need dimmers or plug in modules for everything I need to control and then the rzcop to allow cqc to control the system? A ground wire is required at all switch locations as well?

You're correct. there are two versions of the controller- the better one cost an extra $25.

I believe, you don't need ground, but you can easily check since all the docs are on their web site.

That's all the components. Periodically I'm adding more dimmers and switches and I'm up to something like 25 - all work fine.

[potts.mike]

Thanks for the quick reply may I ask what makes the other programmer better?

[Mikla]

Don't forget to deal with the 3-way and 4-way switches (multiple switches controlling a load).

I used the VRI06-1L with one or more VP00R-1L matching remotes for this.

[Mikla]

The VRCPG-OSG has a timer (versus the VRCPG-BSG) that allows scheduled events to be set in the handheld controller.

[potts.mike]

Luckily I don't have any 3 way swig he's in the house. The timer function sounds like it would be handy to have in a controller. Thanks guys

[IVB]

Mikla and noworries,

Your effort is very impressive. I took your 1.3.5 version, removed all optimization, remove all queries from Poll(), fixed two basic bugs in the Connect() code and enabled the asynchronous messages from the Leviton RF master controller or just use the default in the RF+ firmware and all works fine. I'm sure we can even lower some of the timing but the system is very stable and responsive.

I didn't encounter any of the issues you reported in the above message (CML related) and I don't see the need for any bridge application- your driver works!!

Again, the details and the structure were all coded by both of you), I just gave it a small final touch.

Please, test it.

Rocker

I just installed this driver, works fine (1way) with my Intermatic switches. Well, I tested a single one.

one question: Does the driver currently poll the existing devices to check their current state? I ask b/c all I have is Intermatic switches, so they don't do the Active Notification that the Leviton ones do. I tried manually changing two lights, but they don't seem to be updating on the driver side.

[rocker]

I just installed this driver, works fine (1way) with my Intermatic switches. Well, I tested a single one.

one question: Does the driver currently poll the existing devices to check their current state? I ask b/c all I have is Intermatic switches, so they don't do the Active Notification that the Leviton ones do. I tried manually changing two lights, but they don't seem to be updating on the driver side.

No polling is being done at the driver level. Leviton recognized the limitation in the "basic" z-wave protocol and implemented an event driven scheme which provides notifications when states change- the CQC driver take advantage of it. This was the first question I asked before I picked ViziaRF and my choice of hardware. You need to ask Internatic about their support for Active Notification.

[IVB]

got it, thanks.

Mikla - would your interim app be able to deal with polling?

[SamVimes2]

Is anyone using this plugin with the VRC0P-1LW? This seems to be the Vizia RF+ version of the serial module (and the only one I can find to buy).

[IVB]

I just bought the VRCOP a few weeks ago, that's what I used.

[Mikla]

got it, thanks.

Mikla - would your interim app be able to deal with polling?
Ahhh... Crap.... I just typed up a nice response and when I hit submit I got booted out of the forum and had to relog.

In any case yes... the app will do polling (only polls for levels for now).

The app and protocol are mostly done and can handle scenes, groups, polling and several classes of devices, including those with config parameters. Just need to get past the licensing thing, which appears to take an act of congress.

I started on the CQC driver, but some other things have come up, so it may take some time before I get it done.

For those interested, here is a pic of the sample client I created. All the information you see is pulled from the server via a simple ASCII protocol (you can see some of it in the messages window):
http://cqcdrivers.bizsy.com/Files/zclient.jpg

[rocker]

I would like to be clear about the polling.

The CQC driver (like the application above) is polling all devices at the initialization time to figure out the list of the dimmers, switches, thermostats, ....and initialized the data structures.
Once the info is known no more polling or request for info.

At the regular operation the dimmers, switches communicating back to the should the people in the house change the state of the switch/dimmer the serial interface will communicate it to the CQC driver.

[IVB]

Thx Mikla, very much appreciated.

I would like to be clear about the polling.

The CQC driver (like the application above) is polling all devices at the initialization time to figure out the list of the dimmers, switches, thermostats, ....and initialized the data structures.
Once the info is known no more polling or request for info.

At the regular operation the dimmers, switches communicating back to the should the people in the house change the state of the switch/dimmer the serial interface will communicate it to the CQC driver.

Unfortunately, many of us now have sizable investments in non-Leviton zWave stuff, which is the only brand that I know of with ActiveCommunication. I have 23 different devices, and another 8 waiting to be installed. That's a hell of a lot of repurchasing of stuff, ripping out perfectly functioning equipment.

[Mikla]

Did you take the polling code out of the driver? It used to be there in the Poll method:

TmpStr := kCmd_GetNodeData; //>?N this gets node level
While ( True )
Index := m_PollNodeCount - 1; //m_PollNodeCount will be modifed elsewhere if ther is a user initiated action at the device or in the IV
If ( m_NodeTypes[Index] != IgnoredTypeID )
TmpStr.AppendCard4(m_PollNodeCount,Radices.Dec);
SendMessage(TmpStr);
m_PollNodeCount++;
If ( m_PollNodeCount > 128 )
m_PollNodeCount := 1;
EndIf;
Break;
Else
m_PollNodeCount++;
If ( m_PollNodeCount > 128 )
m_PollNodeCount := 1;
EndIf;
EndIf;
EndWhile;


I would like to be clear about the polling.

The CQC driver (like the application above) is polling all devices at the initialization time to figure out the list of the dimmers, switches, thermostats, ....and initialized the data structures.
Once the info is known no more polling or request for info.

At the regular operation the dimmers, switches communicating back to the should the people in the house change the state of the switch/dimmer the serial interface will communicate it to the CQC driver.

[rocker]

Did you take the polling code out of the driver? It used to be there in the Poll method:

TmpStr := kCmd_GetNodeData; //>?N this gets node level
While ( True )
Index := m_PollNodeCount - 1; //m_PollNodeCount will be modifed elsewhere if ther is a user initiated action at the device or in the IV
If ( m_NodeTypes[Index] != IgnoredTypeID )
TmpStr.AppendCard4(m_PollNodeCount,Radices.Dec);
SendMessage(TmpStr);
m_PollNodeCount++;
If ( m_PollNodeCount > 128 )
m_PollNodeCount := 1;
EndIf;
Break;
Else
m_PollNodeCount++;
If ( m_PollNodeCount > 128 )
m_PollNodeCount := 1;
EndIf;
EndIf;
EndWhile;




Mikla and noworries,

Your effort is very impressive. I took your 1.3.5 version, removed all optimization, remove all queries from Poll(), fixed two basic bugs in the Connect() code and enabled the asynchronous messages from the Leviton RF master controller or just use the default in the RF+ firmware and all works fine. I'm sure we can even lower some of the timing but the system is very stable and responsive.


As I wrote, the polling was redundant, colliding with messages from the serial interface and slow down the system. I also removed all the polling interval optimization code since nothing need to be optimized

If you're using ViziaRF you need to specify to the serial interface to send the notification (default is NO) for VizaRF+ Leviton got smarter and the default is YES. You do it by programming the hand held Master Controller.

[Mikla]

Hmmm... the polling loop only polled one device per poll call... I wouldn't think it would add that much overhead.

It might be worthwile putting the ability to poll back into the driver and then add two fields:

EnablePolling
PollingTime

This way folks that don't have the Leviton RF devices can still use the driver and the RZCOP, which I think was the original intent.

[jkish]

Hmmm... the polling loop only polled one device per poll call... I wouldn't think it would add that much overhead.

It might be worthwile putting the ability to poll back into the driver and then add two fields:

EnablePolling
PollingTime

This way folks that don't have the RF+ devices can still use the driver and the RZCOP, which I think was the original intent.

Yes, that would nice.

I would be interested in trying out the RZCOP and the driver, but I currently have Intermatic devices, but would like to transition to RF+ over time.

[SamVimes2]

I am moving and have decided to leave my intermatic behind and go with vizia rf+ in the new place.

Mikla/Rocker: any progress on getting something like this zwave motion sensor (http://www.automatedoutlet.com/product.php?productid=990) work with your new driver? You mentioned not much luck here (http://www.charmedquark.com/vb_forum/showthread.php?t=7994) but that there were some other things to try.

Thanks!

[rocker]

Hmmm... the polling loop only polled one device per poll call... I wouldn't think it would add that much overhead.

It might be worthwile putting the ability to poll back into the driver and then add two fields:

EnablePolling
PollingTime

This way folks that don't have the Leviton RF devices can still use the driver and the RZCOP, which I think was the original intent.


Mikla,

For Leviton (ViziaRF only the ViziaRF+ has it correct by default), I will not introduce any unnecessary polling if you can just enable the notification by selection the following mode using the master controller menu:

Menu --> System Setup --> Advanced --> Yes --> HAI Setup --> <Serial> -->
select (press +) each dimmer and switch so they will send updates (don't need to select controllers)


In general event driven is the way to go and stay away from polling if you can.

For Intermatic devices ether we develop another version of the driver or incorporate in such away that will use fields as you suggested with default no polling.

[IVB]

For Intermatic devices ether we develop another version of the driver or incorporate in such away that will use fields as you suggested with default no polling.

Sorry, i'm not following what you guys are saying the driver can't do. I'm using it with Intermatic switches, and I can turn the lights on/off. It correctly retrieves the list of devices when first added.

(although as i type this, i realize i only tested it with 3 of 8 devices in my initial network, haven't added or tested the rest).

[jkish]

Sorry, i'm not following what you guys are saying the driver can't do. I'm using it with Intermatic switches, and I can turn the lights on/off. It correctly retrieves the list of devices when first added.

(although as i type this, i realize i only tested it with 3 of 8 devices in my initial network, haven't added or tested the rest).

I thought the issue was that for the RZCOP driver to get state from Intermatic devices, it would need to have polling ability which has currently been taken out of the driver.

Mikla suggested adding the polling back, but making it optional via a field, so that the driver could work more completely with devices that do not support ActiveCommuncation.

If that isn't what we are talking about, then nevermind...

[Mikla]

I think the question is: If you manually switch a light (or change it from a zwave controller), does the status change in CQC?
Sorry, i'm not following what you guys are saying the driver can't do. I'm using it with Intermatic switches, and I can turn the lights on/off. It correctly retrieves the list of devices when first added.

(although as i type this, i realize i only tested it with 3 of 8 devices in my initial network, haven't added or tested the rest).

[IVB]

I think the question is: If you manually switch a light (or change it from a zwave controller), does the status change in CQC?

Oh! Well, yeah, it doesn't do that. But it works as a 1way driver just fine.

Due to the huge hassle of switching networks between Intermatic USB stick and RZCOP, i'm leaning towards just sticking with 1way integration in case your new app gets through the licensing issues. I guess I should actually try that app via the RZCOP, though...

[Mikla]

I haven't got the code in to work with the RZCOP yet... should take me about 2 minutes, but I need to find that 2 minutes...

[IVB]

no rush whatsoever, not even a little.

[IVB]

Mikla and noworries,

Your effort is very impressive. I took your 1.3.5 version, removed all optimization, remove all queries from Poll(), fixed two basic bugs in the Connect() code and enabled the asynchronous messages from the Leviton RF master controller or just use the default in the RF+ firmware and all works fine. I'm sure we can even lower some of the timing but the system is very stable and responsive.

I didn't encounter any of the issues you reported in the above message (CML related) and I don't see the need for any bridge application- your driver works!!

Again, the details and the structure were all coded by both of you), I just gave it a small final touch.

Please, test it.

Rocker

Can Rocker or Dean update the driver from post 29 to whatever the fix the latest beta requires?

[rocker]

Can Rocker or Dean update the driver from post 29 to whatever the fix the latest beta requires?

The latest version I'm using is http://www.charmedquark.com/vb_forum/attachment.php?attachmentid=1607&d=1240040896 (posted in this thread)

[IVB]

hmmm. that's the one I have but it throws massive errors, are you on the latest beta?

If not, Dean, can you do a quick scan and fix whatever the change you made requires?

[rocker]

hmmm. that's the one I have but it throws massive errors, are you on the latest beta?

If not, Dean, can you do a quick scan and fix whatever the change you made requires?

I'm on the latest beta. This driver is no using or sensitive any spacial features added in the last few months.

I have over 30 devices and testing it daily. No issues are known to me.

Leviton will be developing additional commandS for handling scenes but didn't release them yet. As soon as they'll be released, I intend to add that scene support to the CQC driver.

Are you using all Leviton equipment?

[Dean Roddey]

hmmm. that's the one I have but it throws massive errors, are you on the latest beta?

If not, Dean, can you do a quick scan and fix whatever the change you made requires?

Are you sure you aren't using some User version of the driver that someone gave you? Do you see two variations of it in your driver list? The one he pointed you at may have a different make/model or something, in which case you would still be loading the old one.

[IVB]

well, i just blew away the user one and re-imported. Now I don't get errors, but it sits at WaitForConnect. Putting it into high-verbose mode kinda sorta worked - it said the verbose change was unsuccesful, but the logs have stuff in them.

Namely, I see this:

http://www.myhometheaterpc.com/images1/rzerrors.JPG

[rocker]

well, i just blew away the user one and re-imported. Now I don't get errors, but it sits at WaitForConnect. Putting it into high-verbose mode kinda sorta worked - it said the verbose change was unsuccesful, but the logs have stuff in them.

Namely, I see this:

http://www.myhometheaterpc.com/images1/rzerrors.JPG

A) I think your problem is not the CQC driver or anything related to CQC. I think the issue is your ViziaRF Zwave network. I'm not familiar with the details but an message such as (I know your is 039 and not 034 !) <N020:034,001,000,000 is message from node 20. Command 34 that means "application busy". It means in this case that node 20 couldn't reach one of the nodes it has on association list. There are following reasons for this message to show up:

- Node included to the association list doesn't exist in the system or not powered up.
> Check association list in Primary Controller-make sure node 20 is associated with RZCOP.


- Node on association list in node 2 can't be reached because routes haven't been assigned or incorrect.
> Check routes in Primary Controller-Leviton VRCPG:Main Menu>Sysem Setup>Advanced>RTS Devices>Set Routes-select node 20,then ensure RZCOP is checked.

Then under RTS Devices,run Update Routes.
Also Update the RZCOP (Leviton VRCPG:Main Menu>Sysem Setup>Advanced.Network>Update Controller)

B) I'm interested to know how you got the screen you attached (my "CQC Log Server Monitor" doesn't display this format not this information)

Hope this can help.

[IVB]

Hmmm, you might be right, I just hooked it up to the Elk, and it isn't working there either. It used to.

I tried doing the steps you specified, but it says "No RTS Dev". Not sure what that means.

Re:the screen: I used the Admin Interface, Click Logs.View Logs.

[potts.mike]

Can this driver detect when a scene has been activated from a wall controller?

[IVB]

only if it's a Leviton switch that sends the asynchronous active notification.

[rocker]

Can this driver detect when a scene has been activated from a wall controller?

Currently the scenes are not detectable (according to Leviton the next release will support the scenes) but all changes the scene (and the zone) controllers have an impact on any of the dimmers and/or switches will be notified and can displayed/reflected on your screen. From the protocol point of view it doesn't matter if the user or the controller changed the value or state.

So, currently you have present scenes programed on the devices and your own unrelated scenes on CQC (you can set them to the same values). The next VizaRF API (hopefuly) will allow you to program and sync them dynamically at both locations from both locations.

-Rocker

[potts.mike]

My hope was the I could have a bedtime scene, that was triggered from one of the four button controllers, detect this in cqc and do other things with it like shut off the tv or music.

Any idea when the new api is coming and if it will work existing hardware?

[rocker]

My hope was the I could have a bedtime scene, that was triggered from one of the four button controllers, detect this in cqc and do other things with it like shut off the tv or music.

Any idea when the new api is coming and if it will work existing hardware?

I don't know when the firmware updated to the existing hardware will be available.

Yes, your bedtime scene should be possible.

[SamVimes2]

Hi Rocker,

I cannot get the driver to connect. I am getting timed out errors - log attached.

Any thoughts on what I need to fix?

Thanks!

[SamVimes2]

A)


- Node on association list in node 2 can't be reached because routes haven't been assigned or incorrect.
> Check routes in Primary Controller-Leviton VRCPG:Main Menu>Sysem Setup>Advanced>RTS Devices>Set Routes-select node 20,then ensure RZCOP is checked.



I have one node that won't retreive during this test. I also can't exclude it from the network. Is this probably what's gumming up my network? How do I fix it?

[SamVimes2]

Ok I ended up rediscovering my network and getting it all working.

Now that the driver is up and running, how do I make groups?

Thanks!

[rocker]

Hi Rocker,

I cannot get the driver to connect. I am getting timed out errors - log attached.

Any thoughts on what I need to fix?

Thanks!

I didn't read your follow-up messages stating you found a problem so I upgraded to the latest pre Beta and confirm the ViziaRF+ is working without any quirks.

I don't recall making groups.

[SamVimes2]

Ok - how do you do "all off"?

When you say you don't make groups - what do you do? I'm trying to incorporate lighting scenes into my "watch a movie" macros (eg). Should I just address each light that I want to change individually?

[rocker]

Ok - how do you do "all off"?

When you say you don't make groups - what do you do? I'm trying to incorporate lighting scenes into my "watch a movie" macros (eg). Should I just address each light that I want to change individually?
Currently, there is no RS-232 support for scenes/zones controller - their next version should add it. For now you need to address it individually.

[SamVimes2]

I find it hard to believe there's no "all off" command supported in their protocol.

Have you seen the LumenLink program? It's a .Net program that interacts with the RZC0P. I played with it on the suggestion of another forum member with pretty good success. It supports AllOn/Off and groups.

[rocker]

I find it hard to believe there's no "all off" command supported in their protocol.

Have you seen the LumenLink program? It's a .Net program that interacts with the RZC0P. I played with it on the suggestion of another forum member with pretty good success. It supports AllOn/Off and groups.

I don't recall, but even if they don't have it we can add this command to the driver - the driver has a list of all zWave devices on the network and it is possible to send the OFF command to each of them (only Dimmers and and switches or whatever we define for a device to be off).

[SamVimes2]

That sounds great!

One thing to be careful of is sequential vs. parallel - ie, AllOff should turn everything off *at the same time* rather than one after the other (but I'll really, I'll take what I can get!)

[Dean Roddey]

You wouldn't want to do one at a time anyway, since it could take forever to complete that. You'd want to at least do a multicast type command where it's sent to multiple targets at once I'd think.

[SamVimes2]

I'll gladly leave the big boys to discuss, I just want to make my point that a z-wave driver isn't really complete without groups and AllOn/Off functionality.

[IVB]

I'll gladly leave the big boys to discuss, I just want to make my point that a z-wave driver isn't really complete without groups and AllOn/Off functionality.

Technicality, but we shouldn't be referring to this as a zWave driver, it should be called the ViziaRF driver. It doesn't fully support non-ViziaRF devices.

Elk also refers to it inappropriately, and their misleading has caused more than one person to buy this device without realizing that. IIRC, 2 of the others were non-CQCers, so they're really screwed as they have no other option.

[SamVimes2]

Happy to revise:

IMO Rocker's ViziaRF version of this driver, superb though it is in its current form, would be enhanced by adding support for groups/areas/scenes/whatever.

Since he didn't add it because he's not using it, for him to do so just because I ask for it is very generous of him. I realize and appreciate that.

I have a small network of all ViziaRF dimmers. I had the VRC0P hooked up to my elk for a while, but I'm now experimenting with direct-to-CQC connection to see if it offers any more flexibility. The VRF definitely gave me the upgrade I was looking for (real async states and nicer switches) over what I had before (intermatic dimmers + USB stick) but no AllOff or groups makes a direct comparison tough.

I think this device/driver would be a good one for Dean to take over, as suggested in the other thread. CQC needs another z-wave controller anyway!

[IVB]

oh yeah, totally agree, the ViziaRF solution and this driver is far superior to the Intermatic stuff.

But, I have nearly 25 intermatic devices, and can't afford to spend $70 * 25 to replace stuff that works. I'm hoping to phase in over time, so if this driver was made to be 2way with non-Vizia stuff, no one would be happier than I.

[George M]

Happy to revise:


I have a small network of all ViziaRF dimmers. I had the VRC0P hooked up to my elk for a while, but I'm now experimenting with direct-to-CQC connection to see if it offers any more flexibility. The VRF definitely gave me the upgrade I was looking for (real async states and nicer switches) over what I had before (intermatic dimmers + USB stick) but no AllOff or groups makes a direct comparison tough.

!

I would be interested in how you compare the controll through ELK as apposed to CQC. I now have mine controlled through ELK also, but always wondered if it would perform quicker through CQC, especially when controlling lites from motion detectors.

[SamVimes2]

That's exactly what I'm doing. Will report back my findings.

[IVB]

oh yeah, totally agree, the ViziaRF solution and this driver is far superior to the Intermatic stuff.

But, I have nearly 25 intermatic devices, and can't afford to spend $70 * 25 to replace stuff that works. I'm hoping to phase in over time, so if this driver was made to be 2way with non-Vizia stuff, no one would be happier than I.

FYI to Dean/et al, the latest version of johnnynine's J9AE software (http://www.cocoontech.com/forums/index.php?showtopic=13902) now supports polling for non-Vizia devices. I happened to be on IRC when he was on, asked him about it, he said it was all of a 15 minute enhancement.

Cloning this driver to add that, or perhaps an option on driver install about whether one owns non-ViziaRF devices that need to be polled and then doing a client-side driver to specify which devices should be polled, would be HUGE.

[Dean Roddey]

I can't imagine that robust polling that deals with devices not responding and so forth, without getting the whole system piggy, would be a 15 minute enhancement? It don't seem likely anyway.

[IVB]

I can't imagine that robust polling that deals with devices not responding and so forth, without getting the whole system piggy, would be a 15 minute enhancement? It don't seem likely anyway.

dunno, i'm no techie, but that's what he said. Granted that was before he did it, but it was done within a few hours of me asking whether his driver did it, so it wasn't that hard.

[IVB]

God damn MF'ing stupid HA problems with cheap equipment interrupting the damn sabbatical yet again.

My Intermatic zWave USB stick has started turning random lights on when I open the closet door, the actual closet light only turns on maybe 70% of the time.

I got $150 to anyone who can add polling to the ViziaRF RZCOP driver, so I can keep my intermatic switches and only swap controllers. Otherwise, i'm close to ripping out all this crap and going back to $2 light switches.

PM me if interested, i'm still not on the forums on anything remotely close to a weekly basis.

[123]

I'm co-developing a ViziaRF driver (for another HA program) and I was hoping that CQC's Z-Wave gurus could spare a few moments of their time and shed light on a few issues.

Here's my understanding of Groups and Scenes. Please correct me if I'm wrong.


Groups
This is an association list that is stored within the RZC0P/VRC0P. If group #25 contains five devices, issuing a ">GR25ON" will cause the RZC0P to issue a single multi-cast message instructing the five devices to turn on.

Scenes
Each Z-Wave device is programmed to be a member of one or more Scenes. If a Scene-related command is issued, only members of the scene will process the command. A Scene specifies a brightness level and fade-rate. A Scene-related command is a single multi-cast message.


QUESTION #1: Groups or Scenes?
Assuming I have a correct understanding of groups and scenes, which one should a ViziaRF driver support? The driver would have to offer a means of programming Groups (into the RZC0P) and/or Scenes (into each Device). If the driver supported both Groups and Scenes, (get your crystal ball ready) which one would end-users be more likely to use?

QUESTION #2: Scene commands?
In addition, could someone provide a few examples of scene-related commands. I've seen this example but it doesn't make sense to me:
>N1, 10, 23S2, 255
It calls Scene #2 with a default Fade Rate (255). So why does it include an association list (1, 10, 23) when, in theory, the members of Scene 2 know who they are. Does this command suggest that one can filter the members of a scene? In other words, you can specify a subset of a Scene's members?

QUESTION #3: Polling strategy?
What would be the most practical polling strategy?


Query one device, pause five seconds, query the next device, and so on.
This technique keeps RF traffic to a minimum but, given a large Z-Wave system, it may take awhile (> 1 minute) before it iterates through all devices.

Query all devices every 15 seconds.
This technique could either send a single large association list (apparently this is not the most reliable way of soliciting responses) or send one query per device in rapid succession (driver would need flow-control to ensure reliability). Either way, the goal is to query all devices every 15 seconds to ensure low latency. However, this places far more traffic on the network than in strategy #1.

[Dean Roddey]

Wouldn't it kind of not be in our best interests to help a competitor's product get better?

[123]

Dean,

You have a valid point and rest assured it isn't my intent to lure customers away from your company. If it provides any comfort, the other HA product is defunct and not your active competition.

The technical questions I've raised are also relevant to the enhancement of CQC's ViziaRF driver, especially the issue of polling. Previous posts, notably by IVB, makes it very clear that polling is a desirable feature.

If you'd prefer I not solicit technical information, for non-CQC purposes, please let me know and I'll promptly delete my post. No harm, no foul.

[Dean Roddey]

Oh, I assume you mean Premise?

[123]

Yes. There's a long thread on Cocoontech (http://www.cocoontech.com/forums/index.php?s=&showtopic=14829&view=findpost&p=125692)that chronicles the driver's development. A user was unhappy with the existing (developed in C++) driver's lack of polling so we are building a new one (in VBScript) from scratch. It's functional but some features require design decisions that would benefit from more input ... like from the folks who developed CQC's ViziaRF driver as well as its end-users.

[IVB]

Should the driver in the OP work on V3.0.5?

My Intermatic USB controller got way too unreliable, so I spent a few hours blowing away the network, re-adding it into the Leviton controller (after I found it), replicating to the RZCOP. It's now just hanging out at 'wait to connect', although putting it into verbose mode shows that its getting replies back from the device and yanking the connector out of the serial port shows tons of timeout errors.

BTW, 123 or anyone else - i'll bump the cash payment up to $200, more if you want something from the overflowing parts closet...

[123]

...i'll bump the cash payment up to $200...
IVB:

HA enthusiast.
All 'round stand-up guy.
And now: Patron of the Software Arts.

:-)

[IVB]

IVB:

HA enthusiast.
All 'round stand-up guy.
And now: Patron of the Software Arts.

:-)

And one more:


Ready to rip out & urinate all over the Intermatic USB stick for not working like it's supposed to.


It's amazing how much faster the Leviton controller is. With my Intermatic stick, I had to open the closet and wait 2-3 seconds for the light (presuming it worked). With the Leviton, sometimes the light is open before I even finish opening the door. AKA, how you would actually want it to work.

[jkish]

And one more:


Ready to rip out & urinate all over the Intermatic USB stick for not working like it's supposed to.


It's amazing how much faster the Leviton controller is. With my Intermatic stick, I had to open the closet and wait 2-3 seconds for the light (presuming it worked). With the Leviton, sometimes the light is open before I even finish opening the door. AKA, how you would actually want it to work.

Did you get the polling working with the Leviton?

I'm using the HA22 POS and would like to get rid of it as well. It has the habit of working for a long time, just long enough to make me think all is well, and then crapping out for no reason.

[rocker]

Polling is a bad concept: delay, CPU intensive and only lazy manufacturing or old fashion equipment doesn't have support for event driven.

Leviton doesn't need poling and as a matter of fact an older version of CQC was doing poling which confused the entire ZWave, it cause a chain reaction of messages that couldn't be handles so some (that happened to be the important one) got dropped.

Also expect delay which is unacceptable with lighting systems.

[jkish]

Polling is a bad concept: delay, CPU intensive and only lazy manufacturing or old fashion equipment doesn't have support for event driven.

Leviton doesn't need poling and as a matter of fact an older version of CQC was doing poling which confused the entire ZWave, it cause a chain reaction of messages that couldn't be handles so some (that happened to be the important one) got dropped.

Also expect delay which is unacceptable with lighting systems.

For those that don't have Leviton equipment and would like an alternative controller, polling seems like a necessary evil.

[IVB]

yeah; i've got 25 perfectly functioning Intermatic zWave devices, and no way can I rip them out just to get the latest cool thing.

But at least CQC isn't pulling the same dumb move Elk is, by claiming Leviton is supported in the production version. Elk does that, and indeed on Cocoontech even claimed support for 2way knowledge of device status. When pressed (after I bought the RZCOP), Elk admitted that it's only true for Leviton devices. I knew this driver didn't have polling, but I wish I knew Elk had a similar limitation as that was the reason I bought it.

BTW, I still can't get this driver to work on 3.0.5, i'm using it via the Elk. Anybody have this working in a 3.x version?

[123]

Polling is a bad concept ...
... chain reaction of messages
... important one got dropped.
... expect delay which is unacceptable with lighting systems.
Agreed; polling is evil.

However, polling is a necessary evil (for non-Leviton and other one-way devices like thermostats) so what can be done to mitigate its negative aspects?

Here's its evilness in full bloom:

Your Z-Wave network ("the python") contains two dozen Z-Wave dimmers.
The CQC driver generates 24 unique polling requests.
The 24 requests ("the pig") sit in the queue and wait their turn to be transmitted.
Now you reach for your touchscreen and turn on a light.
You've created request #25 and it won't get processed until the python finishes digesting the pig.

The solution is to introduce the concept of Job Priority. Each item (a.k.a. "Job") in the queue has a priority of either "High" or "Low". Polling requests are low-priority jobs whereas all others, like user-initiated lighting requests, are high-priority.

When the queue is processed, high-priority jobs are handled first. After the queue is emptied of all high-priority jobs, low-priority jobs are processed.

Job prioritization helps to reduce the latency introduced by polling. I'm sure we can think of other ways to make polling more palatable.

[jharder]

I am new to HA/CQC and I am in the planning stages of adding lighting control. I have spent hours searching and reading all the threads on z-wave. This solution is currently at the top of my list for a new lighting control system. This seems to be a good solution if Vizia RF + switches, dimmers, etc. are used (I want to know the dimmer states without having to deal with polling).

It seems that development of this driver has slowed considerably...

Is there a driver that will work with version 3.3.x?

Rocker references a "cleaned-up" version of "LevitonRZCOP-ZWave_v0_13_5_CQCv2_4.CQCDrvPack" in post #29. Is that version available as a beta?

Thanks for any updates/additional information that anyone can provide.

----------------
Josh

[Dean Roddey]

The latest version of the Z-Wave driver (in what is about to become 3.4) supports group based notifications, so you don't need polling. Or, more to the point, you'd just set the polling very slow so that each module is probably polled a few times a day just to be sure, so that you will now if a module goes sour on you, which you wouldn't if you purely use notifications.

[jharder]

Dean, thanks for the information. I have been trying to get up to speed with what I have just jumped into (v3.3), so I have not spent any time digging in the CQC beta thread...

Will the v3.4 z-wave driver support the RZCOP?

I realize the following questions head in an off topic direction, so could you point me toward such information (or suggest I post in a more appropriate thread)?

Do you know if there is a solution for v3.3 that supports devices that provide notification, such as the Vizia RF+ product line? What z-wave controllers are currently supported/recommended? Only the Intermatic HA22?

[Dean Roddey]

Will the v3.4 z-wave driver support the RZCOP?

I have to confess my ignorance and admit I don't know what that is?

Do you know if there is a solution for v3.3 that supports devices that provide notification, such as the Vizia RF+ product line? What z-wave controllers are currently supported/recommended? Only the Intermatic HA22?

You can go ahead and get the latest 3.3 beta, which is effectively what is going to become 3.4 minus just some licensing changes and a couple small fixes. It's very solid and lots of folks are using it and have been for a good while.

In terms of controllers, I think that most of the recent USB stick types ones should be ok. Someone sent me an Aeon Z-Stick and it worked just fine as well. As long as it's Z-Wave compliant I think you are pretty safe, but I can't really say for sure, not having used any others.

[jharder]

Thanks again Dean.

I really don't know anything about the RZC0P, except its driver is the subject of this thread :-)

I will go ahead with the latest v3.3 beta and look into the USB sticks a little more. The Aeon Labs controller looks promising at first glance.

I really do appreciate your help.

[Dean Roddey]

So, guys, is the VRC0P-1LW just the new version of this device? It was pointed out to me that this one supports the new security and lock features. This is something that we've not been able to add to our native driver, so perhaps at this point we may want to consider just moving over to this type of device for our official Z-Wave support, I dunno.

If it is just the new version, I assume that this driver would work with it and would just need the addition of new code to support the locks and such?

[dogman]

Yes the latest version (3) of the VRCOP is the one that is firmware upgradable and can support the encrypted Z-Wave Class. The latest protocol including the encrypted Lock commands are located here: http://communities.leviton.com/docs/DOC-2392

[SamVimes2]

anyone have one of the new versions and an accompanying lock to report experience with?

[potts.mike]

Does this driver still only support leviton dimmers due to the pollig issues brought up a few years ago?

I would love to see locks supported in the native driver.

[Dean Roddey]

One would hope it could handle the standard group based notifications now, so that notification enabled standard Z-Wave modules could report to it.

[dogman]

I just got mine today as well as a new Yale Z-wave Lock. Once I get a chance to get it set up with my existing system I will report back. Note I don't use it directly with CQC currently I use it via the interface with my ELK M1 but when I last asked ELK when they were going to support the new locks and VRCOP they said they were not sure yet so I may switch over to just using CQC. I kind of like the idea of my ELK controlling my locks directly though Regarding the other question of whether the VRCOP supports non Leviton equipment I can't say all I have is Vizia RF+.

[batwater]

I just got mine today as well as a new Yale Z-wave Lock. Once I get a chance to get it set up with my existing system I will report back. Note I don't use it directly with CQC currently I use it via the interface with my ELK M1 but when I last asked ELK when they were going to support the new locks and VRCOP they said they were not sure yet so I may switch over to just using CQC. I kind of like the idea of my ELK controlling my locks directly though Regarding the other question of whether the VRCOP supports non Leviton equipment I can't say all I have is Vizia RF+.

Any feedback on this?

I'm starting to think Z-Wave is the way I need to go for most of my switches. I have some neutral available in some boxes so will use UPB for those but for for the rest Z-Wave looks to be the ticket. ZwaveProducts also has a screw in light socket module that I can use in my walk in closets and shop area to finally get rid of the X-10 socket rockets and get to 100% reliability (Big WAF here, something has been plugged in somewhere recently that is eating the X10 signal randomly)

Still researching on whether the VRC0P-1LW will support non Leviton stuff. (like the zwaveproducts screw in module) Also trying to figure out what is the best controller choice with the most universal compatibility.

So, guys, is the VRC0P-1LW just the new version of this device? It was pointed out to me that this one supports the new security and lock features. This is something that we've not been able to add to our native driver, so perhaps at this point we may want to consider just moving over to this type of device for our official Z-Wave support, I dunno.

If it is just the new version, I assume that this driver would work with it and would just need the addition of new code to support the locks and such?
Dean, where is your thinking at on standardizing on the Leviton, seems to make sense?

Thanks,
-Ben

[jkish]

Any feedback on this?

I'm starting to think Z-Wave is the way I need to go for most of my switches. I have some neutral available in some boxes so will use UPB for those but for for the rest Z-Wave looks to be the ticket. ZwaveProducts also has a screw in light socket module that I can use in my walk in closets and shop area to finally get rid of the X-10 socket rockets and get to 100% reliability (Big WAF here, something has been plugged in somewhere recently that is eating the X10 signal randomly)

Still researching on whether the VRC0P-1LW will support on Leviton stuff. (like the zwaveproducts screw in module) Also trying to figure out what is the best controller choice with the most universal compatibility.


Dean, where is your thinking at on standardizing on the Leviton, seems to make sense?

Thanks,
-Ben

I would like to see this happen too

[Dean Roddey]

Yeh, I guess it makes sense. I just haven't had any time to look into this guy. There were serious concerns about its predecessor wrt to non-Leviton based modules and such, and I haven't seen any good info about whether this one deals with that or not either. So it's just something I need to take some time to dig into.

[SamVimes2]

As I recall, the issue was that the Vizia RF+ devices support async notifications. In a system with all ViziaRF+ and this unit, it all works very well.

In order to support non=ViziaRF+ devices, the driver was modified at some port to support polling. This had a negative impact on the performance of the driver.

There also some communications issues I believe between some user/devs and others that negatively impacted perceptions.

Upshot is any official for this device should have the ability to turn off polling completely, for the best possible performance with networks that don't need it; as well as some fine-tuning for polling for mixed networks.

[Dean Roddey]

So, what's the big picture with this thing?

1. Is it really completely separate and inoperable with existing Z-Wave remote primary controller remotes?
2. Is it something in addition to something like the Aeon stick, or does it completely replace that?
3. How do you talk to it? Does that require a separate piece or does it use the USB interface
4. Is there any sort of other software involved?

[Dean Roddey]

Poking around a bit, it seems like:

1. This guy becomes a secondary controller, as with the Aeon stick, so it would replace that.
2. It is interoperable with standard Z-Wave primary controller remote controls, though obviously if the purpose of this is to support locks and such, then it has to be a new enough one that the primary can enroll those types of devices.
3. But, if you actually want to use those new encrypted features, you can't actually use a remote control primary, you have to use some software based primary controller of theirs, which it would seem to me would have to also be able to talk to the device.

So I'm not sure how that works. How can our driver talk to this guy and own the serial port if you have to use some software of theirs to be the primary controller? Would you have to pause our driver every time you wanted to use their primary controller software? And how can you enroll devices using such a thing when their device is something that plugs into a power socket in the wall? You couldn't carry it around plugged into a computer.

[batwater]

Poking around a bit, it seems like:

1. This guy becomes a secondary controller, as with the Aeon stick, so it would replace that.
2. It is interoperable with standard Z-Wave primary controller remote controls, though obviously if the purpose of this is to support locks and such, then it has to be a new enough one that the primary can enroll those types of devices.
3. But, if you actually want to use those new encrypted features, you can't actually use a remote control primary, you have to use some software based primary controller of theirs, which it would seem to me would have to also be able to talk to the device.

So I'm not sure how that works. How can our driver talk to this guy and own the serial port if you have to use some software of theirs to be the primary controller? Would you have to pause our driver every time you wanted to use their primary controller software? And how can you enroll devices using such a thing when their device is something that plugs into a power socket in the wall? You couldn't carry it around plugged into a computer.

Dean,

As I research what parts to buy for this to work it looks like the VRC0P-1LW will handle security protocols if used with the Leviton VRUSB-1US Vizia RF per the documentation linked earlier in this thread (p2 in red) Now whether this implies that the Installer software must be running or simply the VRUSB stick (once programmed) is not clear. It appears as you say that the VRC0P is a secondary controller on the network. I have none of these things yet so I am speculating...

-Ben

[dogman]

The USB installer stick is just that . It is only used to add new nodes to the network or optimize/trouble shoot the network. It can be used to control nodes but that is really just for testing. So the VRCOP is just a serial controller enrolled as a secondary controller either via the USB stick or some other type of primary controller. The VRCOP is basically just a serial bridge to a network so it operates independentlyly of the USB stick. I have an older non-beaming VRCOP that works great |(interfaced with Elk M1 directly not CQC but CQC controls it just fine. I just purchased the new beaming VRCOP so It can operate Z-wave locks but upon updating the firmware it bricked so I have a call into Leviton to see if It can be recovered or needs to send it back. Will update if I find anything else out. As far as I know the New VRCOP needs no special software to operate just ASCII RS 232 commands.

[Dean Roddey]

This statement is in the serial protocol document anywhere secure commands are involved:

Note: Must have a Vizia RF + VRC0P with a +3 on the back label and use the RF Installer tool as primary

I'm not sure what exactly that's implying wrt to the RF Installer tool being the primary.

[zra]

Dogman,

Would you be so kind and clarify some stuff for me. I ordered the following

http://www.smarthome.com/45016/Leviton-VRC0P-1LW-Vizia-RF-Plug-In-Serial-Interface-Module/p.aspx

along with 5 of these

http://www.smarthome.com/45072Z/Leviton-VRI10-1LZ-Vizia-1000W-Incandescent-Scene-Capable-Dimmer-White-Ivory-Light-Almond/p.aspx

and 5 of these

http://www.smarthome.com/45001Z/Leviton-VRS15-1LZ-Vizia-RF-15A-Scene-with-LED/p.aspx

If i connect the VRCOP to my CQC server will i be able to configure the above switches and control them using the driver that is attached to the first page of this thread?

Is there anything else im going to need?

[dogman]

You will need a primary controller to set up the Z-Wave network . You can use the VRUSB-1US leviton usb stick and their free leviton rf+ installer network software on their website or you can get their VRCPG series of portable remotes to do this. Last I checked the USB stick is cheaper but you will need a laptop to walk around to set up the network with the USB stick. I have not used the RZCOP driver myself I use my ELK M1 to interface with the RZCOP then use CQC Elk Driver to send it commands.

Dean: I think that statement is just clarifying that the VRCOP/RZCOP cannot be used to set up a Z-wave network. It can only be used as a secondary controller. You still need the USB stick and the rf installer software to set up the network first.

[zra]

Thanks Dogman,

By chance would a AEON stick work in place of the Leviton stick?

[Dean Roddey]

Dean: I think that statement is just clarifying that the VRCOP/RZCOP cannot be used to set up a Z-wave network. It can only be used as a secondary controller. You still need the USB stick and the rf installer software to set up the network first.

But it would seem that that is true in general and they could have just put it at the top of the document. But the protocol document only ever indicates this (in red) in the commands that are related to beaming and security, which seems kind of unusual.

[dogman]

Thanks Dogman,

By chance would a AEON stick work in place of the Leviton stick

I am not sure about AEON stick but I doubt it as I think only the leviton stick will work with their RF installer software. But you should be able to include the VRCOP with AEON stick and whatever software they use then use the free Leviton RF installer software to configure the VRCOP for the network but I am just guessing here since aalmost all of my stuff is Leviton.

By the way I have had no luck getting my new VRCOP to work with my new Yale Zwave locks. The VRCOP works fine with all my other devices but just haven't been able to get it to lock or unlock my new Yale lock.

[batwater]

I was notified on Monday by Smarthome.com that the Leviton Vizia RF+ Plug-In Serial Module has been discontinued. :angry2: I had planned on using this with CQC as my foray into Z-Wave. I received the Leviton VRUSB-1US - Vizia RF+ Installer Tool last week and now have to comtemplate sending it back as I was going to pair the two in order to have the security capability to handle ZWave door locks.

I am now back to the drawing board as to what my ZWave options are. Anyone else have any thoughts / seen anything on what Leviton's plans are re the home automation interface and a replacement?

(This is also posted on Cocoontech)

Thanks,
-Ben

[Dean Roddey]

So this is the newer one we've been talking about and it's already discontinued?

[DaveB]

Cooper, Intermatic and Wayne-Dalton all have USB RF sticks that become part of the Z-Wave network. CQC could simply send commands to the stick which in turn sends the command to the Z-Wave meshed RF network. I think that is the direction that most manufacturers are taking.

[batwater]

So this is the newer one we've been talking about and it's already discontinued?

That's what I'm trying to sort out, Smarthome is not forthcoming with any other information. It could be as simple as they discontinued the older model (was advertized as if it were the newer one.) I posted on Cocoontech with the hopes that someone from AO or other industry folk could provide insite. Making me crazy! :shock:

-Ben

[batwater]

So this is the newer one we've been talking about and it's already discontinued?

Okay some clarity; I received great info from a chap named Wilson at Automated Outlet via their web chat feature. The current version of the VRC0P has been discontinued by Leviton; they are in the final stages of releasing a new VRC0P that has capability to handle the security protocols required for the Zwave locks. AO indicates that they are expecting the new module in the next 30 days but no guarantees as that is out of their control. AO does have some of the older units still in stock.

Whew! Folks sorry for the partial false alarm but at least there is more clarity in what is going on with this.

Also, Wilson indicated that Evolve is the only other Zwave vendor that has the security protocol capabilty in it's controllers at this point.

(above is cross posted from Cocoontech.com)

Bottom line, the old VRC0P has been discontinued. The new unit we started talking about here will handle the lock protocol and is not yet out on the market (at least to Automated Outlet)

-Ben

[batwater]

From Cocoontech user...

Leviton has already released the VRCOP RF+3. I have had one for several weeks and currently have it working with a YALE zwave deadbolt. Note: Leviton did not change the part number. So you have to ask the vendor specifically if they have the VRCOP RF+3.

As indicated in a post about the Leviton protocol documentation. What is important is that if you order you have to be explicit & verify what think you are getting.

-Ben

[zra]

Hi Guys,

I just got my VRCOP V3 today. Im using the driver from way back in the begining of this thread, but so far im getting a "wait for connect" errror and a bunch of timeouts.

I have an AEON stick fully functioning. its acting as a secondary controller and the leviton remote as the primary. i added the new VRCOP and its listed as a controller, but i still cant get it to connect in CQC.

Anyone have a suggestion for me?

[Dean Roddey]

They could well have changed the interface enough so that the existing driver can't understand it. It may also be that if you include any modules that use any of the new features that that might confuse the existing driver because it seems stuff that didn't exist when the driver was originally created.

I know that the protocol was posted a bit back, but I never really looked at the protocol for the original one. Was that new document supposed to be applicable to the old one as well?

[batwater]

Hi Guys,

I just got my VRCOP V3 today. Im using the driver from way back in the begining of this thread, but so far im getting a "wait for connect" errror and a bunch of timeouts.

I have an AEON stick fully functioning. its acting as a secondary controller and the leviton remote as the primary. i added the new VRCOP and its listed as a controller, but i still cant get it to connect in CQC.

Anyone have a suggestion for me?

+1 Too weird, I also receive my VRC0P V3 yesterday, won't be able to get to it until this weekend so I am most anxious to hear how this turns out...

-Ben

[zra]

Thats pretty funny, Ben. Let me know if you get it to connect to CQC. Im still unable and completely at a loss as to where to go from here.

For now it's making an execellent $110 paperweight. :(

[zra]

They could well have changed the interface enough so that the existing driver can't understand it. It may also be that if you include any modules that use any of the new features that that might confuse the existing driver because it seems stuff that didn't exist when the driver was originally created.

I know that the protocol was posted a bit back, but I never really looked at the protocol for the original one. Was that new document supposed to be applicable to the old one as well?

I guess that is possible. Im not an expert on the drivers, just a appreciative user, so i really cant talk to that.

Its unclear to me if those who have gotten it to work were using the VRCOP V3. In fact, this thread is 3 years old now, and the original repliers seemed to be using one of the earliest versions of the product, the RZCOP. One person mentioned that they had successs with the VRCOP, but im guessing that it was V1 or V2.

Dean, what is your thought on getting a current driver written for the VRCOP V3? Do you know of anyone who would be willing to give it a go?

[Dean Roddey]

I'm willing to get into it, but I can't afford to buy one right now, and if that involves having to get a new primary controller and USB stick, then most definitely I can't afford it right now. I have an Intertic HA7 primary and the original Aeon stick right now.

[zra]

ok,

ive been playing around with hyperterminal - im no expert here - but i have been able to send commands that are working with the VRCOP. i know its working at least.

i wonder if there are others who would be willing to toss money into a pot inorder to get you the hardware you need.

ill offer up 50 bucks. anyone else?

[batwater]

I guess that is possible. Im not an expert on the drivers, just a appreciative user, so i really cant talk to that.

Its unclear to me if those who have gotten it to work were using the VRCOP V3. In fact, this thread is 3 years old now, and the original repliers seemed to be using one of the earliest versions of the product, the RZCOP. One person mentioned that they had successs with the VRCOP, but im guessing that it was V1 or V2.

Dean, what is your thought on getting a current driver written for the VRCOP V3? Do you know of anyone who would be willing to give it a go?

I'll be able to provide feedback in the next 24 hours or so. I have a small test zwave network activated that I can turn the 2 connected lights on and off via the Leviton Installer Tool and now just need to add the VRC0P +3 to CQC.

Quick question, do you have your VRC0P controller, which is a secondary, associated with an existing network? I'm wondering if the driver is barfing because there are no devices registered to the VRC0P?

-Ben

[zra]

just so we're clear - you mean the VRCOP right?

i think i have the associations correct.

Ive been using an AEON stick(secondary) and the leviton remote(primary) and ive got that working pretty well now. i just tryed to introduce the VRCOP into the network that was established. i guess i could try to remove all the nodes and redo them with the VRCOP.

thats probably a good place to start. what do you think? ive now confirmed that the VRCOP is working - via hyperterm.

[Dean Roddey]

It would seem like the VRCOP would have to be added to the network no matter how you controlled it, right? It couldn't be talking to nodes unless it was part of the network.

[zra]

It would seem like the VRCOP would have to be added to the network no matter how you controlled it, right? It couldn't be talking to nodes unless it was part of the network.


yes, believe that is correct. so mine is included. bat suggested that the driver is hickuping because its not associated, but im pretty sure mine is. again, i was able to send commands to one of my switches, successfully. if it was associated i dont think it would have worked, right? i wonder though if a clean start would prove fruitful.

[zra]

and BTW, dean. the protocol doc

http://communities.leviton.com/docs/DOC-2392

does seem to be written for the newest version.

[batwater]

just so we're clear - you mean the VRCOP right?

Doh, brainfart. :shock: Yes that is what I meant. Will update original post.

Sorry!
-Ben

[Dean Roddey]

and BTW, dean. the protocol doc

http://communities.leviton.com/docs/DOC-2392

does seem to be written for the newest version.

What did the old protocol look like? Though they may well have created a new, non-compatible interface, it doesn't seem like this one is radically different, it just supports new features. You'd think that they would have tried to keep it backwards compatible, but then I'm an automation guy so I have crazy ideas like that.

[batwater]

Okay,

1st roadblock... I cannot load the driver in this thread into CQC 4.03 says its not compatible. What now?

Thanks,
-Ben

[zra]

bat,

grab one of the later updates. it fixed that problem. check page 3 of the thread - somewhere around there.

post number 20 seems to be the most recent.

[batwater]

bat,

grab one of the later updates. it fixed that problem. check page 3 of the thread - somewhere around there.

post number 20 seems to be the most recent.

That did it. Loaded up, can confirm the same behavior. VRC0P is associated with the network and knows about the other devices but CQC will not connect to it.

I can see I/O in hyper terminal.

Dean, I can make this remotely available to you if you want. Let me know.

-Ben

[zra]

Thx Ben,

Saves me a bunch of time trying and erring

I have a copy of the driver code, dean, if that helps you.

[Dean Roddey]

It would probably be next week before I can look at it. I have another driver i have to do for someone this weekend. Have you tried putting it into verbose mode and see if gives any useful info as to why it's not happy?

[zra]

It appears to me that the device isnt responding, but both Ben and I have recieved replys with hyperterm, so it has to be something with the driver.

10/07 16:36:43-Automation.esugar.local, CQCServer, CQCDrv_VRCOP_Thread21
{
CQCKit, CQCKit_DriverBase.cpp.2927, Status/App Status
Driver 'VRCOP' is trying to connect to its device
}
10/07 16:36:43-Automation.esugar.local, CQCServer, CQCDrv_VRCOP_Thread21
{
CQCGenDrvS, MEng.User.CQC.Drivers.Leviton.RZC0P-ZWave.334, Status/App Status
Message sent to Device->>?FI0,016,0,1
}
10/07 16:36:44-Automation.esugar.local, CQCServer, CQCDrv_VRCOP_Thread21
{
CQCGenDrvS, MEng.User.CQC.Drivers.Leviton.RZC0P-ZWave.287, Status/App Status
GetMessage(), Timed out waiting reply from device
}
10/07 16:36:44-Automation.esugar.local, CQCServer, CQCDrv_VRCOP_Thread21
{
CQCGenDrvS, MEng.User.CQC.Drivers.Leviton.RZC0P-ZWave.317, Status/App Status
GetMessage(): Call to Device failed. Err=Timed out waiting for a message
}
10/07 16:36:44-Automation.esugar.local, CQCServer, CQCDrv_VRCOP_Thread21
{
CQCGenDrvS, MEng.User.CQC.Drivers.Leviton.RZC0P-ZWave.590, Status/App Status
Timed out waiting for: <F or <E010
}
10/07 16:36:44-Automation.esugar.local, CQCServer, CQCDrv_VRCOP_Thread21
{
CQCGenDrvS, MEng.User.CQC.Drivers.Leviton.RZC0P-ZWave.955, Status/App Status
Connect failed. Err=Timed out waiting for a message
}

[jkish]

It appears to me that the device isnt responding, but both Ben and I have recieved replys with hyperterm, so it has to be something with the driver.

10/07 16:36:43-Automation.esugar.local, CQCServer, CQCDrv_VRCOP_Thread21
{
CQCKit, CQCKit_DriverBase.cpp.2927, Status/App Status
Driver 'VRCOP' is trying to connect to its device
}
10/07 16:36:43-Automation.esugar.local, CQCServer, CQCDrv_VRCOP_Thread21
{
CQCGenDrvS, MEng.User.CQC.Drivers.Leviton.RZC0P-ZWave.334, Status/App Status
Message sent to Device->>?FI0,016,0,1
}
10/07 16:36:44-Automation.esugar.local, CQCServer, CQCDrv_VRCOP_Thread21
{
CQCGenDrvS, MEng.User.CQC.Drivers.Leviton.RZC0P-ZWave.287, Status/App Status
GetMessage(), Timed out waiting reply from device
}
10/07 16:36:44-Automation.esugar.local, CQCServer, CQCDrv_VRCOP_Thread21
{
CQCGenDrvS, MEng.User.CQC.Drivers.Leviton.RZC0P-ZWave.317, Status/App Status
GetMessage(): Call to Device failed. Err=Timed out waiting for a message
}
10/07 16:36:44-Automation.esugar.local, CQCServer, CQCDrv_VRCOP_Thread21
{
CQCGenDrvS, MEng.User.CQC.Drivers.Leviton.RZC0P-ZWave.590, Status/App Status
Timed out waiting for: <F or <E010
}
10/07 16:36:44-Automation.esugar.local, CQCServer, CQCDrv_VRCOP_Thread21
{
CQCGenDrvS, MEng.User.CQC.Drivers.Leviton.RZC0P-ZWave.955, Status/App Status
Connect failed. Err=Timed out waiting for a message
}

Did you try sending the message in the logs above via HyperTerm and see if you get anything back? If so, how does it compare the the <F or <E010 that the driver says it is looking for?

[zra]

Jkish,

im getting back

E004

Correction

im getting back

E000
F004
E000

[jkish]

Jkish,

im getting back

E004

Correction

im getting back

E000
F004
E000

Looks like it could be working according to the doc:

Driver is sending a FI command (Find) for 0,016,0,1

E000 means command processed and I think F004 is the response returning node 4.

Not sure what the driver is expecting exactly. Maybe the initial E000 is tripping it up now, but don't know what the old spec looked like.

[jkish]

You might want to use something like this: http://technet.microsoft.com/en-us/sysinternals/bb896644 and see what is being sent back and forth.

[zra]

Jkish or Dean,

I spent the morning tracing through the code for the driver. Keep at mind i took a few C courses in college but I dont consider myself proficient at all.

The device is returning in response to >?FI0,016,0,1

<E000
<F040 / this is varing but always starts with <F
<E000

As you suggested jkish it seems to be hanging up on the first <E000 and never getting to what the code is looking for "<F040"

I added a second line of getmessage() just to see if it would get to the <F line and it did and it processes, but the driver still wont connect - im sure due to unintended consequences of that and/or perhaps others issues.

[batwater]

Well, I've turned the zwave screw in module into $20 paper weight. Thought I had removed it from the network and then did a reset to start over - not! :-x Lesson learned. There does not appear to be any way to recover from this, need to know the house code it was set to, that was lost.

Need more detailed documentation on the communication protocol. I'm seeing responses from the RC0P when the USB stick master controller does stuff (including the setting of the association for the security protocol) but have no idea what they mean.

I do have one light switch configured at the moment that can be controlled manually from hyper terminal...

-Ben

[zra]

Well i never thought id be able to pull this off, but i did.

Ive spend the entire morning mucking with the driver code and i have it connecting now.

Its definately not 100% and since ive never written a driver for anything it probably needs to be evaluated by someone smarter then me.

The way the orginal code was responding to the getmessage() method was not working and it was timing out here and there. so i fixed the getmessage() method and increased the timeout number. its taking about 2 mins to connect, but its connecting.

dean, orginally the programmer was using 1000 for the timeout and i increased it to 3000, ill test it here in a few at 2000 to see if that works.

This is all in the initialize part of the driver(forgive me if the terminology is incorrect as i dont know the layout of the code intimately yet.

[batwater]

Well i never thought id be able to pull this off, but i did.

Ive spend the entire morning mucking with the driver code and i have it connecting now.

Its definately not 100% and since ive never written a driver for anything it probably needs to be evaluated by someone smarter then me.

The way the orginal code was responding to the getmessage() method was not working and it was timing out here and there. so i fixed the getmessage() method and increased the timeout number. its taking about 2 mins to connect, but its connecting.

dean, orginally the programmer was using 1000 for the timeout and i increased it to 3000, ill test it here in a few at 2000 to see if that works.

This is all in the initialize part of the driver(forgive me if the terminology is incorrect as i dont know the layout of the code intimately yet.

That's great. I was just sending the device query commands manually and noticing that the expected <E010 (no device found) is never returned. It does return an <F000 as a result code when there are no devices. when there are devices for that type the VCR0P returns <F003 for which corresponds to the working dimmer that I have.

Not sure how what I am observing ties into upping the timeout setting that is allowing you to connect. Do you have any valid devices in CQC after your 2 minute initialization?

-Ben

[zra]

That's great. I was just sending the device query commands manually and noticing that the expected <E010 (no device found) is never returned. It does return an <F000 as a result code when there are no devices. when there are devices for that type the VCR0P returns <F003 for which corresponds to the working dimmer that I have.

Not sure how what I am observing ties into upping the timeout setting that is allowing you to connect. Do you have any valid devices in CQC after your 2 minute initialization?

-Ben

yes, i never got <E010 either so instead i started looking for <F000 which appears to be the correct Null return. I added some code to look for <F000 and that seemed to do it. ONce the driver gets past the intialization part it seems to run ok. i havent done alot of testing yet so im not sure.

ive attached the revised file. cant believe i figured out how to do this. LOL

let me know if it works for you

[batwater]

yes, i never got <E010 either so instead i started looking for <F000 which appears to be the correct Null return. I added some code to look for <F000 and that seemed to do it. ONce the driver gets past the intialization part it seems to run ok. i havent done alot of testing yet so im not sure.

ive attached the revised file. cant believe i figured out how to do this. LOL

let me know if it works for you

Working for me to tho still getting some time outs during initialization. It's a start, congratulations! :-D

Now to figure out if I can recover my paper weight, damn, that makes me mad, the screw in modules are hard to come by as they are discontinued.

-Ben

[batwater]

I've renamed the driver to reflect the VRC0P+3 and upped the version level to .14

-Ben

[zra]

Thanks Bat -

The driver implementation isnt working great for me. Its connected but im not able to turn things on and off with any consistancy.

just a heads up.

[batwater]

Some initial observations...

The device I have installed in the network is of type Dimmer. The driver does not handle this device properly in relation to the various control fields available. For example, I can toggle the light on but the dim field for the device stays at 0. Conversely I can set the dim field to any value and the OnOff field stays off; in other words, they are not connected together.

Toggling all lights On hangs the driver and takes it off line. This may be a function of having only one device and not having any groups like all lights set up in the ZWave network.

-Ben

[batwater]

Thanks Bat -

The driver implementation isnt working great for me. Its connected but im not able to turn things on and off with any consistancy.

just a heads up.

Driver in general (the one you posted) or the one I uploaded? I used your code, hmmm...

[zra]

Another day hacking at this driver and i have it working pretty well, i think, knock on wood.

I dont know how rename some of the backgound files inorder to make it a seperate driver, so if anyone can walk me through that id appreicate it.

for now its stil using the old files(manifest, etc).

[zra]

Found and fixed(hopefully) a few more errors and added the ability to change the device name field - not the way that it should be done - via a client side driver, but at least it can be changed now.

Upnumbered version to 14.1

[batwater]

Found and fixed(hopefully) a few more errors and added the ability to change the device name field - not the way that it should be done - via a client side driver, but at least it can be changed now.

Upnumbered version to 14.1

Very interested in testing; traveling this week / weekend, be next week before I can install in my system and provide feedback.

How many zwave devices & what types are you managing?

Thanks for your work!
-Ben

[zra]

Ben,

I have 13 dimmers/switches/fan controls all leviton.

im eyeballing one of the three major z-wave door locks right now. not sure which, but as soon as i figure that out and get it im going to start working on the driver to accomidate that functionality.

Appreciate the feedback when you get some time.

[batwater]

Zra,

I'm having a hard time figuring out which driver is which on my system, did you update the manifest or the version # in the code itself?

I can talk you through updating the driver manifest to reflect the current release level if you have not.

Thanks,
-Ben

[batwater]

Ben,

I have 13 dimmers/switches/fan controls all leviton.

Appreciate the feedback when you get some time.

First observation, my unknown message counter consistently increments. I'll have to turn logging on high and note what it is complaining about. Are you seeing the same thing?

Thanks,
-Ben

[zra]

i did figure out how to sync the manifest and the new driver

the most recent should be an independant driver. if its not then let me know and ill double check it.

ive been working on some changes to that will allow for a more specific device name instead of the generic switchXXX/dimmerXXx etc. Im finding that the device is freezing up pretty frequently. im not sure if the driver is hitting it too hard with requests or what. i want to work on it some more before i post the new version.

[Dean Roddey]

Hey, could you start a new thread for this new guy, and try to sum up somewhat reasonably what the state of the state is and what's require for to use this thing, links to information that would be useful, etc...? And of course a link to the latest version of the driver.

[zra]

I will Dean. Unfortunately the VRCOP that I was using has completely failed. Im in the process of returning it to leviton and they are telling me it could take 3 weeks.

I was having some serious stability issues with it even before it completely stopped working. My hope is that it's a problem with the device itself and not a systemic issue with the model.

[batwater]

I will Dean. Unfortunately the VRCOP that I was using has completely failed. Im in the process of returning it to leviton and they are telling me it could take 3 weeks.

I was having some serious stability issues with it even before it completely stopped working. My hope is that it's a problem with the device itself and not a systemic issue with the model.

Any action here? I have a little bit of time over the holidays to play with this.

Thanks,
-Ben

[zra]

Ben,

I recieved a replacement device from leviton, but truthfully, i havent even opened it up.

Im alittle nervous to start playing with it because my aeon stick and deans zwave driver have been working stable for me.

i just opened it up and ill am going to give it a look

[batwater]

Ben,

I recieved a replacement device from leviton, but truthfully, i havent even opened it up.

Im alittle nervous to start playing with it because my aeon stick and deans zwave driver have been working stable for me.

i just opened it up and ill am going to give it a look

I can appreciate not wanting to mess with "working stable" :-) thanks for looking...

-Ben

[zra]

Bat

I thought id give you a little update. last week I connected the VRCOP to my cqc server and was getting a very slow response. not sure what was going on there. it was working "normal" on my laptop. Anyway, i sort of gave up again, and since i have a few higher priority things i want to accomplish im going to sideline it for now.

probably mid january ill be able to give it another go. sorry man.

hope you had a good christmas.

[Dean Roddey]

If there is any sort of enrollment, or if you moved the USB stick along with it, you'd want to re-add the stick to the network in its new location, so that it can see what all is around it and update its tables and such. Otherwise it might be piggy.

[batwater]

Bat

I thought id give you a little update. last week I connected the VRCOP to my cqc server and was getting a very slow response. not sure what was going on there. it was working "normal" on my laptop. Anyway, i sort of gave up again, and since i have a few higher priority things i want to accomplish im going to sideline it for now.

probably mid january ill be able to give it another go. sorry man.

hope you had a good christmas.

Christmas was excellent, had all my kids in town at once! (and a bonus, a 3 month old Golden Retriever puppy that my oldest son brought into the family) :-D

I have plenty to work on, I have 3 UPB switches to install and am otherwise focused on getting jkish's music templates up and running to manage our household music.

The zwave switches (2 of the 3 anyway) are going in places where I don't have a neutral wire, the x10 solution is still working in those locations for now.

-Ben

[zra]

If there is any sort of enrollment, or if you moved the USB stick along with it, you'd want to re-add the stick to the network in its new location, so that it can see what all is around it and update its tables and such. Otherwise it might be piggy.


Actually, Dean I was just testing it with hyperterminal and for some reason or another i was getting an extremely slow response. it actually wasnt even working. no response from the device. I am using rs-232 to usb connectors so perhaps that was the issue. i only have 2 serials on my CQC machine and they are both being used and i really didnt want to disconnect them to test out a pure serial connect. It was working fine on my laptop and it was working fine before(using the old VRCOP - the one that broke) so there is something going on there whether or not it was the usb im not sure yet.

[batwater]

Dean,

Are there any plans afoot to bring this into the "official" driver fold and make work well? I am reluctant to put in the few switches that I have as they are going to control high use / profile lights in my home...

Thanks,
-Ben

[Dean Roddey]

Oh, I thought other people were currently working on it, so I was pretty much putting my time elsewhere. What is the current status of it in terms of what's working and what's not?

[batwater]

Oh, I thought other people were currently working on it, so I was pretty much putting my time elsewhere. What is the current status of it in terms of what's working and what's not?

Dean,

The running status is in this thread. zra worked on it some but stopped. I don't have anything installed at this point as when I tried a variant it was generating a lot of errors so pulled it out.

Thanks,
-Ben

[zra]

Hey guys,

I was having stability issues with the hardware. Its my opinion that the hardware is not very robust. This of course could just be something in my setup.

Dean, if you want to give it a go. Id be willing to send you my hardware. You can evaluate it and perhaps write a driver for it.

I would just ask that you return it when you are done.

let me know.

zra

[Dean Roddey]

How much are the Leviton thingies? I have a small Z-Wave setup here and a USB stick, so that's all I need I guess.

[Dean Roddey]

In terms of a remote control, does anyone have a known working configuration? It would need to support all the new stuff. I can't use a USB thingie with software since I don't have a laptop to carry around to the different modules. I need an actual remote control.

And presumably my Aeon USB stick will also be able to handle the beaming and encryption, right? Did anyone ever confirm this?

[zra]

How much are the Leviton thingies? I have a small Z-Wave setup here and a USB stick, so that's all I need I guess.


about 100 bucks.

[zra]

In terms of a remote control, does anyone have a known working configuration? It would need to support all the new stuff. I can't use a USB thingie with software since I don't have a laptop to carry around to the different modules. I need an actual remote control.

And presumably my Aeon USB stick will also be able to handle the beaming and encryption, right? Did anyone ever confirm this?


dean, what do you mean by this? " does anyone have a known working configuration?"

I am currently using the aeon stick with all my leviton switchs and dimmers. it works almost flawlessly. occasional brief hickups, but thats it.

[Dean Roddey]

I meant in terms of a remote control that is compatible with all the latest stuff and happy with the Aeon stick in terms of replication and so forth.

[zra]

oh, gotcha.

i use the leviton remote just for the intial setup. not sure if it works with the door locks or not. never thought about trying

[Dean Roddey]

Can you try it? It would need to work with them or I couldn't set one up and test it. It doesn't matter if it will actually control a lock, just that it will learn it and replicate it to the Aeon stick.

[zra]

yeah, i dont have a lock, but i will start shopping for one

[potts.mike]

Dean,

Are you planning on moving away from the USB stick and making zrcop the supported controller or are you looking at implementing the encryption/beaming for use with the USB stick?

[Dean Roddey]

The old driver will remain there. But, in order to support all the new stuff, I'm looking at also supporting the Leviton device as well. The USB stick is still required in that scenario as well. The Leviton box is basically acting like a gateway to the Z-Wave network, exposing a non-ZenSys API.

[zra]

dean,

i see yale has some locks for between 200 and 300. i really dont want to spend the upper end of the range for products like the baldwin.


whats our goal here? since im not that confident in the rzcop and the aeon stick has worked well for me, can i expect that you will be able to control the locks with the aeon?

[Dean Roddey]

I can't promise anything of course. When it's done, if it works for me, then I can promise you it works for me. That's about it. Isn't there any anecdotal evidence out there that it works? I thought that some of the automation panel products are now using it as their Z-Wave interface now, right? Do they claim to support the Aeon stick?

Is it even in fact true that the USB stick is required if you have an actual remote control primary controller? Some of what I read seems to imply that the Leviton box is a secondary controller. If that's true, then the only reason you'd need the USB stick is if you used a software primary controller. It would mean that you wouldn't any longer replicate to CQC, instead the driver would probably use some sort of configuration file or something like that, or perhaps ask the Leviton box for a list of what's out there after the configuration has been replicate to it.

There just seems to be a lot of confusion out there as to how all this actually works.

[zra]

i wish i knew, but i dont. the stick acts as a secondary controller, i believe, and the remote is the primary.

levition claims that their remotes are not compatable with zwave locks

http://communities.leviton.com/thread/1959

[potts.mike]

My impression has always been that the vrcop replaces the USB stick as the secondary controller. I'll see if I can confirm this when I have time.

[batwater]

My impression has always been that the vrcop replaces the USB stick as the secondary controller. I'll see if I can confirm this when I have time.

That was my understanding as well. Although you don't need to have the USB stick up and running after your done programming the zwave network.

-Ben

[Dean Roddey]

Over on the Cocoontech forum someone said that it does require a laptop and USB stick (and their software) to serve as a primary controller.

[potts.mike]

Right, but if you use the leviton USB stick and software then you don't need a primary remote.

[zra]

i have the leviton stick and was not able to get cqc to control thru it. i had to get the aeon.

[Dean Roddey]

In this scenario being discussed here though, CQC would never actually use the stick itself. Only Leviton's own primary controller software would ever use it.

[wuench]

Yes, on CT they said the USB stick is one of the few that can program the locks. Just to get things setup.

[batwater]

In this scenario being discussed here though, CQC would never actually use the stick itself. Only Leviton's own primary controller software would ever use it.

Right, when I was testing the existing driver with switches that is how I did it. the VRCOP+3 was hooked up to CQC via serial and the USB stick was used separately to program the ZWave device network. The USB stick is not required once the programming is completed.

-Ben