ZWave Debugging - Where to Start?

[broconne]

I had a leviton VRCOP with beaming support and a single ZWave fan module. The VRCOP3 is in the basement and the fan module was on the second floor. I never had any communication problems.

I added a kwikset door lock on the first floor and was having intermittent communication problems. This doorlock was up one floor and over 35 feet or so from where the VRCOP is. Understanding that I don't have enough nodes and the battery operated devices might be a bit weaker, I purchased two Evolve appliance modules that support beaming. At first I placed them halfway between the kwikset and the controller. I removed the kwikset from the network and readded it after adding the two new modules and I updated the controller. That didn't help. I then placed one module within 5 feet of the kwikset lock, and repeated the procedure. I still only have about a 20% success rate in controlling the lock from the HAI.

I see in the leviton software that lock is 2 hops away from the controller, which I assume means it is using the evolve module. Is there any way to further debug the zwave network? Is there a way I can listen in and see what is happening when the VRCOP sends the kwikset a message?

 

[project_x]

I think I would remove the fan controller, if for some reason it is the hop before the Kwikset, then that would cause a problem.

 

[electron]

You can interface the VRC0P directly using Hyper Terminal or Putty. You can find the protocol on Leviton's website. If you think it's a range issue, can you try a serial extension cable which would move the VRC0P closer to other Z-Wave devices?

 

[jaydubb1]

This is very relevant to my interests, I am currently installing an HAI - Z Wave - Kwikset system.

Please keep this updated!

 

[broconne]

I think I would remove the fan controller, if for some reason it is the hop before the Kwikset, then that would cause a problem.

I removed the fan control from the network.. The problem persists.

 

[MrBOFH]

What happens if you move the lock within a few feet of the Leviton? Then remove and re-add it and check the hops? If it is now only 1 hop and you still have problems, it may be the lock is not 100% functional or the Leviton may not fully support beaming. If it's still 2 or more hops, try and remove all other devices so the only things on your network are the Leviton and the Kwikset. If there are still problems then, you've isolated it to the Leviton <-> Kwikset interaction and eliminated all other variables. Making it easier to pinpoint the exact problem.

My locks are Schlage and relatively easy to remove and bolt together without a door and be functional enough for testing.. I'm not familiar with the Kwikset ones but hope the same goes.

 

[ddennerline]

More than likely your routing table is not correct from the perspective of using beaming/security nodes. Since you have a mixture of security (supports encryption class) and non-security enabled (Leviton light switches) nodes, they may not be playing nicely together.

I had the same type of reliability problems without any encryption devices. I went back to all my switches and included then again. I walked from switch farthest from the VRC0P and moved closer. I noticed that some switches hop counts changed. I believe going through the inclusion process multiple times causes the mesh routing table to “acclimate” peer routes to partners with highest signal strengths.

The latest version of Leviton RFIT when using Levition VR-USB has ability to “Test Signal” and determine how Z-Wave system will respond if interference is present.

You could try and replace the Evolve devices with comparable VRP03 that supports beaming/encryption (http://communities.leviton.com/thread/1989). This way you can move the relay device around to get the best signal strength/hop count.

 

[InspiredTim]

Does the fan controller support beaming? You might have to purchase beaming device and add it to your network to wake up the lock.

 

[etc6849]

I'm pretty sure you've checked this, but what type of batteries are you using? I wouldn't use rechargeable batteries due to their lower voltage. I think this is stated some where in the manual for the locks. If you follow the links in my signature there is free HA software called Premise that can help you debug things using it's port spy feature along with the VRC0P Premise module.

 

[jwilleke]

Maybe I am missing something, but the whole Z-Wave thing of the Z-Wave Primary Controller needing to be within three feet of a Z-Wave Node, to perform such functions as adding/or updating a Secondary Controller, feels very poorly thought out.

Am I missing something?

 

[broconne]

Sorry to let this topic die down. I finally got some time this weekend to mess around with this.. I really didn't make much progress.

(1) If I move the lock closer to one of the other modules I can get 100% control of the lock.
(2) I then moved it back and have zero control.
(3) I then moved both evolve modules downstairs, directly under the door lock. I have 100% reliable control of the evolve modules.
(4) I then re-added the door lock. The lock routing shows that it is 1 hop to each evolve beaming module and two hops to the controller.
(5) I get zero control of the door lock.
(6) I did a network rediscovery and still have zero control of the door lock.

I would consider expanding my network, but its been about a year and Leviton isn't really putting out more beaming compatible devices. I have several fan controls I need to purchase, but Leviton hasn't added beaming yet. I also have a 15 month old, so I can't really put evolve modules all over the place because they are going to get pulled out.

Is Zigbee a stronger or more reliable protocol? I could consider going that route for my locks.

 

[swaggy]

I had a similar problem with my Yale zwave deadbolt, worked fine for about a week or so and then I could no longer control it with my OmniPro. My OmniPro is in the basement and the lock is on the opposite side of the house so I suspected signal issues. I ended up buying another VRC0P and placing it roughly in between the primary VRC0P (attached to the OmniPro) and the lock. Here's what I learned:

1) There are only a handful of zwave devices that support beaming, these Leviton products should: VRCZ4, VRP03, VRC0P, VRCS4
2) The Yale lock (and perhaps others) should be included into the network before any other controllers (like the VRC0P). If you include the lock after the controllers, them simply re-include the controllers.
3) Set your reverse RS232 associations while standing as close to the lock as possible
4) Excluding and re-including the lock is the only way to effectively "reset it"

Seems to be working ok for me now although it's been only a week or so since had to troubleshoot it. Also, HAI's zwave lock integration sucks IMO as all you get is basic lock/unlock and status reporting but you can't tell if the lock was unlocked via knob or keypad nor do you get battery alerts. The second VRC0P came in handy as I connected it to another serial input on the OmniPro and set it for ProLink, using Paul's great document for the more advanced logging features:

http://cocoontech.com/forums/topic/20322-hai-2-x-yale-zwave-locks-and-vrcop-rf3-integration/

 

[broconne]

This is somewhat interesting. I am getting status updates from the lock with 100% accuracy and the updates are rapid.

I have no successes when I try and control the lock from the omni. Its almost as if the lock knows the route back to the controller, but the controller doesn't know the route to the lock. I have updated the controller, but may try to remove and re-add it..

 

[ASIHome]

What version of firmware are you on?

 

[ddennerline]

Your best bet is to use Hyperterminal (as Dan meantioned above) to connect to VRC0P+3. You would then issue the appropriate lighting command directly from Hyperterminal. The Premise forum (and I believe latest Leviton ASCII Programming manual) has a detailed list of secure lock commands. In addition, you would manually manipulate the lock and verify that notification commands are received by Hyperterminal.

As Barry mentioned, you need to make sure that Leviton VRUSB, RF+ Installer Tool, and VRC0P+3 firmware revisions are up-to-latest. I remember seeing some patches/fixes related to locks in at least one of the devices. Flashing the VRC0P+3 can be tricky.

Note: You should keep the VRC0P+3 near the Omni RS-232 gateway as this may change the packet routing.