Premise Z-Wave Status using RZCOP/VRCOP help

Motorola Premise
I would also use the RF Installer to "Set Routes" for the VRC0P with the compatible devices (aka Leviton switches and dimmers).

You should be able to unbrick it. I had a similar issue last year, but I followed the instructions in the pdf after switching serial cables and it worked. I think the issue is some usb to serial adapters do not work with their program (under windows 7?).

If I remember I used Windows 7 Pro, but had to dig out an old Digi adapter (USB to 8 serial ports). I had a cheap cable with a prolific chip from Newegg and it didn't work with Leviton's program!?! You also might try XP and see if that helps.

If you google, you'll find some people have issues with their update program, but everyone gets it working eventually.

If the update process is inteerrupted for eiither Flash filee;
Cycle power to the Serial interfa ce
Close and reopen t he Serial Boootloader
Reopeen the Flash file
Click oon “Start” and the update pprocess will reepeat"
What...are you clarivoyant? Yes Win 7, Yes generic board (4 port) just added. Maybe you could tell me what to get for my wife for Christmas? ;-)

I'm not hopeful given it won't even light up now. I would think there'd be a factory reset procedure. I had followed the procedure above but it was a non-starter.

Until I get this resolved I'll focus on zoned audio with android tablets as controllers.
The only other reset I know is to unplug the VRC0P, hold in the button, plug it back in while keep holding button, and then hold the button for 30-60 seconds or until the light turns red.

The flashing tool should make it operable again though if you follow their steps. If not, maybe you had a unit with some portion of corrupt memory? For Leviton RMAs, you would typically go through your distributor/retailer. Worthington/Asihome is who I used once. They were great about it and just sent me a new dimmer and processed the RMA with Leviton for me. I didn't even pay shipping cost!
Yoy might try
Factory Default:
If your module is not responding, or you are unable to control it after you have tried to Include Exclude it multiple times, it may be necessary to
reset the module to its original factory settings. To accomplish this, proceed as follows:
• Press and hold the programming button until the LED turns Amber and then turns Red. Release the button and wait until the LED starts blinking Green. NOTE: This can take up
to a minute. The module is now reset. Once the module is reset, it will be necessary to Re- Include it to a network before it can be used.

VRCOP up and running. I'm trying to add the ViziaRF.xdo v33 into Premise but when I Import, via Modules, nothing happens. I did delete the Leviton module (assuming older version) prior to adding in the new one. Odd but it seems the Import functionality isn't working correctly now. Adding a NEW module works fine.

Ideas? Even tried putting the xdo into the Schema/Modules directory and going through Add-ins in Premise but no love.

...even tried to restart Services to see if that reset Premise... still no luck.

I reinstalled Premise but then found that the XDO module was corrupt. All is ok now. HAI and Zwave are functioning with lock (and that's cool! thanks). Still getting errors transmission errors. I'll track down the thread on tweaking this XDO modules communications settings... I saw it somewhere.

Fun stuff! thanks again.

I wonder if there's an illegal xml character in one of the xdo's? This wouldn't cause the failed transmissions though, but sounds like something else to look at. If you backup Premise, then change the xdo extension to xml and open it in internet explorer, ie will tell you which line the issue is on. There are some characters you cannot put inside an xdo file explicitly, so you would use the chr() vbscript function instead. I think the help file has a list or google for a list of xml valid characters.

If you still see X001 or X002 errors, you probably will need to place a routing slave in between the VRC0P and the lock(s). I had to install two of these:

Just make sure the VRP03 you buy has a +3 on the back as the older version did not support secure packets. Before spending money, I would relocate the VRC0P closer to the locks and see what happens. The issue is only a few routing slave nodes work with secure transmissions, so even if you have 40 z-wave devices, the secure packets may have transmission issues unless you have a routing slave that for sure supports secure packets.
Interesting note about changing the .xdo to xml and reading it in IE!

I had a long on-going problem with the ZWave module...It generally worked from the mb, but bi-directional didn't work, it was a pain in the neck to get new devices added. I took ETC's advice and decided to go Fukushima on it (I nuked everything)
I deleted the vrf file from the installer (after removing each device, an important step!). I deleted the ViziaRF install I had in Premise Builder, then reset the VRCOP to Factory Defaults. Then I upgraded the firmware to the VRCOP. Well, actually, I bricked it...I received a new VRCOP on the 24th, plugged it in, added it in the Leviton Installer, added the new ViziaRF in the Builder, loaded the Installer info into the VRCOP, did the auto-discovery, rebounded everything, then went to church. We came back after the service, the Christmas and Landscape lights were on (picked right up from the previously programmed schedule); bi-directional worked, and all was good.

No problem, two days and counting...
etc - thanks for the info. I'm a lot further along now. Basically did what chuck did above (including the bricking). Started from new firmware and built up from there.

Current challenges:
*** For some reason the VRCOP XDO stopped communicating with the VRCOP3 (confirmed it is a 3+) after working for a few days. I tried controlling lighitng from the Device level properties (ON, OFF) without success. Then I ran the BurnInTest (for the heck of it) and it successfully communicated with my 17 devices (then popped an error forcing debug mode). After ignoring the error, and going back to polling mode, everthing is back again... strange. Polling was set to 60 seconds but had changed by it's self to...over 1000. I changed it back and can see the polling strings cycle through in the Status property. Also I did change the property on most of my switches to One-Way (that was a great idea) so Polling is bringing back correct status.

SUGGESTION: HAI's XDO has a PollEvents property that will pull True every couple of seconds to show successfull communication with the Omni. Can the VRCOP XDO do something like this? Or is there already...

TotalTransmissionErrors is at 17 and going up slowly.
zero InterfaceFailures

Is there a watch-dog timer on this XDO so I can be notified when/if it stops again?

Again, Thanks so much!
When MaxConsecutiveJobs is exceeded (default is 3), an interface failure will be given and the port is automatically reset. This is the watch dog.

Your device being polled sounds like it may have inconsistent communications. The polling being used is smart polling. See my next post for what "smart polling" means. I would check that CustomDevices.ViziaRF.JobQueue.AddDelayForNextJob is false also.

It would help to know what device you are polling and if there are any events being set (go to Monitor->Events). If you see a bunch of events, you have to dig through them and figure out which node is the issue (it's a mesh network) and fix it or your network will not be reliable. Look at the frequency of the events, node(s) affected, etc...

If you look in the Premise Help file, there is an example on how to be emailed if an event occurs. An interface failure (severity = 50), like a job failure (severity=70) will set events. If you have transmission related errors, it is very unlikely that Premise is the cause, but rather the way the z-wave network is setup or behaving. The code for the VRC0P has been looked at by several experienced professional programmers (123 and Markh).

The best thing to do is to study the documentation and take the free training on Leviton's site if you have a bunch of node failures. Yes, deleting your network is one way that may fix a problem, but I never do that as it's too much work! If you take the online courses, they show you how to use the debugging tools in the RFInstaller software. There's also explanation of how the network works, how to properly place devices, etc... http://www.leviton.c...&minisite=10251
Also read this guide:

And other documents found here:
Smart Polling
If you try to poll every device in a large network, you can easily overload a z-wave network. So, what the module does is it auto increments the Devices.PollingInterval property if polls are still in the queue. This is actually a very smart way to do things. If this number is getting very large, it means you are processing a lot of jobs. This may be ok if it's intentional, but imagine if a node failed, why would you want to keep polling it every 60 seconds?!? Another feature is job priority. Polling jobs are always sent after all high priority jobs (e.g. actual state changes).

From sys://Schema/Modules/Leviton/Classes/Polling/CheckPolling:
' Start a Polling cycle only if the Job Queue contains no low-priority jobs.
' Polling creates low-priority jobs.  If there are low-priority jobs in the Job Queue
' it means the previous Polling cycle is still underway.
' Do not start a new polling cycle until the previous one has completed.
'debugout "<CheckPolling>"
dim oJobs
set oJobs = this.Parent.Jobs.GetObjectsByTypeAndPropertyValue(Schema.Modules.Leviton.Classes.Job.Path, "Priority", false)
if this.DiscoverDevices = false then
'debugout "Discovery is disabled."
if oJobs.Count = 0 then ' Last polling cycle has finished
  'debugout "Previous polling cycle has completed. Starting new polling cycle."
  'debugout "Previous polling cycle is still underway. Skipping this polling cycle."
  this.PollingInterval = this.PollingInterval + 5 ' Extend the Polling Interval by 5 seconds
  ' Restart the Polling timer if Polling is enabled
  if this.PollingInterval >= this.MinPollingInterval then this.CreatePollingTimer
end if
'debugout "Discovery is enabled."
' Do not poll during a Discovery operation.
' Restart the Polling timer if Polling is enabled
if this.PollingInterval >= this.MinPollingInterval then this.CreatePollingTimer  
end if
set oJobs = nothing
Amazing! I love this stuff. Your suggestion to set to False the AddDelayForNextJob worked perfect and now my polling is under a few seconds... not 10+ seconds. Thanks!

I will follow your recommendations and take the online class. I didn't know it existed and being off for the holidays is perfect timing.

Also, I now remember the email functionality as I had implemented it years ago (first house with Premise). I'll read up on that as well.