ZWave Debugging - Where to Start?

What version of firmware are you on?

VRCOP+3 is on firmware .30 (The one that fixes the status updates). I am not a big fan of how Leviton releases new firmwares and doesn't increment the number.

The Omni is on 3.10A

I don't know the lock firmware version.
 
This just keeps getting weirder. I connected the VRCOP to my laptop and used hyperterminal. I seem to have perfect control of the lock, sending the commands directly.

I connect the VRCOP back to the HAI and I can't control the lock at all. However, the HAI is clearly talking to the zwave controller because it can turn on and off the evolve modules without issue.
 
I don't know if this will help, but usually when i have problems with my network, i usually would do a full reset of my network. That solves most of my problems most of the time.
 
Resetting the network may make troubleshooting this problem more difficult. This is likely not a routing problem that can be resolved by re-including devices and updating secondary controllers.

If the VRC0P+3/Hypterminal is located in exact same location as the OmniPro/Z-Wave Bridge (OPZB), then changing routing tables may not improve situation.

Did you manually manipulate your locks, so they are generating notifications back to VRC0P+3/Hypterminal. You should also manipulate a selection of lights to see if VRC0P+3/Hypterminal is correctly monitoring non-encrypted devices.

It’s possible that OPZB is being too aggressive with command transmit and event responses. Communication with locks can be unreliable. Thus, if OPZB is blasting commands to a wide variety of devices, it may not take into account that encrypted commands take longer for setup/response.

From your description indicating that moving the lock closer to OPZB improves reliability, this step provides a hint that timing may be a component of problem. Since you are manually sending commands, the timing is slower and may actually be the right throughput and rate for communicating with lock.

The only alternative is to get OPZB manufacturer involved. When I was having problem with Elk Z-Wave, I contemplated buying an EZ-tap RS-232 Analyzer. This is really the only way to prove what is going on. This way you can provide the logs files to manufacturer.
 
Yeah i guess my way would be a bad way to find the problem as it might come back again :l... I guess its good for a last minute showdown for the frustrated =P.

What does the EZ-tap RS-232 Analyzer exactly do? seems like something that would be good to have just in case. Is it Z-wave Specific?
 
Ok.. So I took every device off the zwave network, then I created a new network. Added the lock first, then the two security compatible evolve modules, then the VRCOP3. I am back at the state where I get 100% reliable status updates from the lock to the HAI, but no control of the lock from the HAI. I also attempted to switch serial ports, so I moved the VRCOP to serial port 1 - as expected that did not resolve anything.
If I connect the VRCOP3 to hperterminal I am able to control the lock 100% of the time. It almost acts like there is a bug in the HAI - but I would think more people would have reported this if true.
 
I don’t have a HAI Z-Wave controller, so I cannot really comment on this device. In general, you could have a hardware configuration problem where the baud, parity, etc… may not be 100% correct. For Elk, you need to configure the M1XSP correctly. I initially had some jumpers on the M1XSP set incorrectly; This is a multistep process and if you make a mistake at any of the early steps, then a domino-like problem develops.

If the HAI controller supports sending commands directly to VRCOP+3, then just create a fixed text string containing the VRC0P+3 lock door command and see if you can get the lock to responds appropriately.

If you can control all devices and all associations (light on/off, door locked/unlocked) work in Hyperterminal, then it’s probably not a Z-Wave problem. If you manually manipulate the lock, then Hyperterminal should show a update status line.
 
Back
Top