Adding Leviton VRCZ4 and VRCZ4-MR zone controllers to Z-Wave binding

I have some of the Leviton VRCZ4 and VRCZ4-MR zone controllers. They are in the Z-Wave database but are listed as requiring review and are not in the 2.2 release or any of the branches in the GitHub openhab/org.openhab.binding.zwave repository.

I assume the way to test these out on my system is to build the z-wave binding locally and include the exported XML files for those devices. To that end I’ve:

  • gotten an account for the database and sent an email to Chris requesting edit access
  • followed the instructions to set up the OpenHAB Eclipse development environment
  • forked openhab/org.openhab.binding.zwave and cloned it to my system
  • imported my local clone into the Eclipse OpenHAB workspace.

I’ll create a branch for testing these devices. Should this branch be based on the development branch?

If I need to make changes to the the device XML files, I know that I need to update the database and request a review. After that what is process for getting these into the official Z-Wave binding? Does a review and OK of the database entries trigger that or do I need to submit a pull request from my repository.

Thanks - David

I think both these devices need further information adding to the database before they can be reviewed/approved…

Once this is done, then the process is I’ll approve them, the generated files are added to the next snapshot of the binding, and you can install this. Installing is easy if you are using the snapshot runtime, but a bit more painful if you are on the 2.2 release as it needs to be installed manually.

I’ve updated your access in the database, so feel free to update these devices :slight_smile: .

Okay, I’ll update the information on these devices in the database. I’ll also switch over to the snapshot runtime.

One other thing about the VRCZ4-MR is that it also has a switch that can also be included in the network. By default it is associated with button 1 on the zone controller. However, the switch has the same device ID and type as the controller even though they have different attributes. Here’s what shows up in HABmin after including both devices, node 7 is the controller, node 8 is the switch:

Z-Wave Node 7 (001D:1202:0243:0.2)

  • Unknown Device
  • Manufacturer 001d Leviton
  • Type / ID 1202:0243
  • Firmware Version 0.0
  • Basic Class: STATIC_CONTROLLER
  • Generic Class: NOT_USED

Z-Wave Node 8 (001D:1202:0243:0.2)
Unknown Device

  • Manufacturer 001d Leviton
  • Type / ID 1202:0243
  • Firmware Version 0.2
  • Basic Class: SLAVE
  • Generic Class: BINARY_SWITCH
  • Specific Class: NOT_USED

How should this be handled in the database?

Thanks - David

I don’t really understand this - so you say the device is reporting two nodes - and the two nodes are themselves reporting the same manufacturer information? I don’t think I’ve ever seen a device report itself as two nodes - that’s the exact function of the multichannel encapsulation to allow a device to support multiple virtual devices. Are you really sure that the device isn’t just included twice?

Please provide the XML files for both devices and we can see. Probably we’ll just have to add both functions to the single device, but we need to see what this thing is really supporting.

Yeah, after writing my previous reply I was wondering if this is something that should be handled by multiple endpoints.

On the other hand, there are instructions for including the switch in addition to the controller. If you are using Leviton’s Z-Wave Programmer/Remote it sounds like this happens pretty automatically. I seem to remember my Vera doing this too, but that was a few years ago. If you use an Aeotec Z-Stick you use a different combination of buttons on the VRCZ4-MR to include the switch.

I assumed that the builtin switch has a separate Z-Wave radio, but I could be wrong. Maybe the alternate buttons for the switch inclusion make it look like a different device.

With the 2.2 release I was only getting nodeN.xml files for devices that were found in the database. So no nodeN.xml files for either incarnation of the VRCZ4-MR or the VRCZ4 for that matter. Is there some setting that controls this?

I’m reinstalling openhabian and will switch the openhab2 installation to the snapshot builds and see what happens. I’ll let you know what I find out.

Ok, this would make sense if it was the case. I’ve not looked at this thing - is it physically two parts?

It’s a shame then that they chose to use exactly the same manufacturer information for both devices.

The xml files are not dependent on the database at all (in fact it’s more the other way around). If they are not being produced, then it means there’s another problem and you need to get a logfile so we can work out what’s happening.

The VRCZ4-MR is one piece/part. It looks just like the VRCZ4 which doesn’t have the switch.

Should I upload the log file here or raise an issue in the openhab/org.openhab.binding.zwave repository?

Okay, I reset my test setup to just contain the Z-stick and the VRCZ4-MR. Everything set to factory defaults.

  1. I checked that button 1 on the VRCZ4-MR operated the load. It did.
  2. I included the controller portion (4-buttons) into the network. Button 1 no longer operated the load.
    3 I included the switch into the network and button 1 again operated the load.

I put the Z-stick back into the system, installed the z-wave binding. an let system discover the devices and add them to the system. The binding is creating node1.xml for the Z-stick but nothing for node 2 or 3. Although there is partial data that shows up in habmin. in the log below node 2 is the controller portion of the device and node 3 is the switch:

The log is at: https://gist.github.com/davidlballenger/48ed912b4a5e498c3fd1dfa58fc5014a

This shows that the device isn’t responding to the version command class…

I’m not sure at the moment how best to handle this in the binding - it’s a very fundamental command class…

Here’s the log for the VRCZ4.

By the way the VRCZ4-MR was working in OH 1.8.3, not sure about the VRCZ4. Although I was using Z-Wave binding 1.8.0.201508211938. As I recall at the time there were some issues with the binding in 1.8.3.

I would offer to send logs from that system if it would help, but the earlier generation Z-stick that I was using decided to go wonky on me.

Thanks - David

What is the difference with the logs? They both seem to have node 2 and 3, and both have the same issue (as seen in the image above). Is there another node I should be looking for in the second log?

I don’t think it would help - presumably it will show the same issue. In OH1, the initialisation was less strict - it generally didn’t retry if something failed and this caused problems because data was incomplete. Unfortunately (or, fortunately, depending on your view :wink: ) in this case it would have been good as the failure would have been ignored.

I don’t see NODE 2 in the log but theres is a NODE 3, where I expected a NODE 4.

In order to give a smaller cleaner log I had excluded NODE 2 VRCZ4-MR Controller and NODE 3 VRCZ4-MR Switch. I tried the exclusion via OpenHAB but it didn’t seem to be working so I stopped openhab and did it through the Z-Stick itself. I put the Z-Stick back in the RPI and then restarted OH. I ended up having to trash those devices in OH since it didn’t know about the exclusion. I sopped OH removed the old log file. Started OH an monitored the log for a while to make sure I was getting no references to Node 2 or 3. There were none.

I then stopped OH and removed the log file again. I included the VRCZ4 using the Z-stick put it back in the RPI and restarted OH. Imagine my surprise when Node 3 showed back up. I was expecting a Node 4 for the VRCZ4, but there wasn’t one. I checked Node 3 in HABmin and it the Type/ID 0702:0261 which is the VRCZ4. So it seems that when it was included it got the Node ID of the previously deleted device. I didn’t think that was possible.

I’ll reset everything and start fresh and give you a new log.

This presumably means it wasn’t excluded. If you started the binding, and it still shows the device, then this means the controller still thinks the device is included into the network.

No - this is not possible. Te controller will allocate the node IDs so unless it was completely reset it will allocate node IDs in ascending order.

Yeah I’m just going to reset everything. and start over and give you a clean log.

I’ll do this tomorrow. My spring cold/cough has about put me out it for today.

I reset everything and set all devices to their factory defaults. After adding the the Z-sitck back into the wave binding and verifying that it currently had no devices I shutdown openhab2 and removed the Z-stick. I then included the following using the appropriate buttons on the devices and the button on the Z-stick:

node 2: VRCZ4-MR (controller)
node 3: VRCZ4-MR (switch)
node 4: VRCZ4 controller

I deleted the old openhab.log, put the Z-stick back in the RPi, and started openhab. Again no nodeN.xml files were created for these files. The resulting log is at:

Let me know what else I can do.

One more log. After facotory resetting everything and starting with a fresh installation, I did the inclusion of the VRCZ4-MR via OpenHAB. Previously I would remove the Z-Stick and use the inclusion button on it to include the device.

Unfortunately, even with inclusion via OpenHAB, the device initialization is still not completing and still no nodeN.xml file created even though a thing is added in OpenHAB.

Also, I had set the inclusion timer to 80 seconds, but it still times out after 30 seconds. I actually had to do the inclusion twice to get the Thing created and have the lights indicating inclusion mode on the device to turn off.

The log is at: