Premise Z-Wave Status using RZCOP/VRCOP help

Motorola Premise
Glad you got it working! The next version will have AddDelayForNextJob unchecked as default. It was originally necessary for the first firmware version of the VRC0P+3, but Leviton fixed that issue for me a long time ago. I may just remove it altogether.

How many devices are you polling? You may find that the module will raise your polling from 60. I would let it manage things, but you can always find the script from the previous post and disable it.
I'm polling 17 devices. I had unplugged one module for a few days and found timeout errors in Premise as well as port resets. I gathered this would happen based on comments previous in this thread. some modules have zero failedjobs and others have 5, 6, 9+. 95 failedjobs for the moduel I unplugged (christmas tree). Is there a way to reset all failedjobs for each device?

BTW 48897 totoal jobs with 124 failedjobs. 292 totaltransmissionerrors. 11 Interfacefailures. Is this ok or is something wrong? Also, Polling Interval has moved up to 230 (from 60) Why? I would like a more frequent polls given the manual one-way swtiches we use.

Isn't there any option to ResetJobCounts or something under the JobQueue container? Also look under the Devices container. I'm not in front of it now...

The numbers sound normal if you tried 95 times to poll a node that was unplugged. You really shouldn't unplug a node and expect the rest of the network to operate correctly without reprogramming the network, It is a mesh network.

Watch the job queue folder in Premise Builder. If it never empties, you are polling faster than the VRC0P and network can respond. If you poll beyond that, the queue will just fill up even more and keep growing. The polling may have gone from 60 to 230 seconds because you slowed things down by unplugging a node.
yes. Found the ResetJobcounts and that cleared the totaljobs and totalfailedjobs in JobQueue. I meant to clear the 'FailedJobs' under each device (now that they are all plugged in). Not a big deal.

Can I enable Logging to see, in ascii, what commands are failing and to what devices? Still getting failed jobs on multiple devices(switches) and then that forces a port reset. I can control all devices directly through Premise without exception.

As a thought I re-enabled the ManualACK just to confirm commands.

Lastly, How would I see the last successful command to a device? I see date/time stamps for other things but not for these devices.

Thanks! I'm hoping to have Premise monitor my HAI keypads to trigger scenes of lighting changes. Maybe Button macros.
There isn't a way to see the last successful command on a per device level other than to watch it in Port Spy or using Debugview. Search Premise Buidler's help for "Port Spy." Also, search this forum for debugview. You should be looking in the Event viewer and this should tell you which device fails the most. Your issues all sound like they are z-wave related, and I have no way to help you from here as they are outside of Premise.

To clear all the variables you mention try this:
Search on here or Builder's help for "scriptmacro." I think this is covered in one of the Premise tutorial videos found here:

Paste the code below in the scriptmacro, commit the code, then trigger the scriptmacro:
devices.CustomDevices.ViziaRF.TotalTransmissionErrors = 0
devices.CustomDevices.ViziaRF.Jobs.TotalFailedJobs = 0
devices.CustomDevices.ViziaRF.Jobs.TotalJobs = 0
devices.CustomDevices.ViziaRF.InterfaceFailures = 0
for each oDevice in devices.CustomDevices.ViziaRF.Devices.GetObjectsByType(schema.Modules.Leviton.Classes.Device.Path, true)
oDevice.FailedJobs = 0
oDevice.MaxFailedJobs = 50

This should clear all the variables for you. I'll probably add this as a feature at some point.
Great! Thank you. When I finish this part I'm moving on to lighting ramp control. I'd like some of my scenes to ramp much slower (mock sunrise).

Thanks much for the support!
I may have found out the reason for my pain w/ the ZWave module...I'm not certain, (and I'm not going to test it again!), but if you physically remove a device, it appears that the discovery 'hangs' on the recently removed device node. 
I went in to the Installer Tool, removed the device/node, installed the new device/node, and the module picked it up asap.
Again, not sure it's the reason...but it lessened my pain once I figured out the sequence. ETC, is there a 'remove node' option in the module, or does it have to be done via the installer tool?
Bingo! That's exactly what I did..maybe we should make it more clear in the instructions? Although, I'm sure most of us don't ever read them... :blush:
Looks like my zwave lighting configurtion is settling in. 18 errors in 7600+ jobs. Very good!  I had to re-optimize the network after a VRCOP lock up, then update everything.
The module is still automactially increasing the one-way polling time when, after 3 misses, it resets the comm port.
With such a low error rate A) is resetting the port the actual solution or is it just possible transmission collisions a couple of times a day? B) should we have the capability of NOT automatically increasing the polling duration? Mine was set to 120 sec and after 18 errors it's now at 185 sec. 
The more I play with the module the more I'm learning!  Thanks!
By the way, if it's a z-wave product that supports association, two-way feedback should usually work if you set your network up correctly.  In other words, there is no need to poll at all as Premise will be kept up-to-date automatically.  I'm not sure what these 18 devices are, but I would certainly ensure polling is necessary.  I have 55-60 devices and none of them require polling.  The free Leviton training talks about this and
discusses which z-wave partners are "tier 1" or whatever Leviton calls it.
If the devices are battery powered, you should be all for smart polling.  Otherwise, when the batteries fail, the job queue will continue to fill with the polls.
18 errors out of 7600 sounds reasonable to me.  Especially considering jobs with the errors were automatically retried (default is 3 times) and probably succeeded.  I don't think other z-wave software automation options are anywhere close to this level of performance.  Typically, I have even less errors, probably 18 out of 20000 jobs.
So I added a couple of Zwave switches this weekend...these are my steps - corrections appreciated!
Step 1 - Install, following all of the electrical warnings - 'serious damage, death, etc'
Step 2 - Find and add using the Leviton SW (I can't speak to other SW) - following the instructions e.g. select OK , etc
Step 3 - Right click on Controller - select update controller
Step 4 - Go to Premise Builder ->devices->Custom Devices->ViziaRF->Devices
Step 5 - Select 'Discover Devices' in the properties box...
Step 6 - Go to newly added device - select 'Associate with' (assumes you have already added the VRCOP
Step 7 - Go to Home - add object type (e.g. Light) in the desired location
Step 8 - Bind object to device as usual
I would perform a network rediscovery and also be sure to set routes for the new device so two way feedback will work with the VRC0P.  Move around with a laptop when you are doing steps 2.5 and 2.6.
Step 2.5 Network rediscovery
Step 2.6 Set Routes
Step 3 Update controllers
Step 3.5 Update Routes (recommended if you read the RF Installer help file)
So I have a question and a tip...
Question - on the HomeSeer Motion Detector - HSM100. It appears as a binarysensor. Should I see something more? I added via Vizia RF+ tool. Shows in builder..I'm getting battery levels, Manufacturer, etc. No DeviceModelDetails. What should I see?
I went nuts over the last three days after I added the gate sensor. The 'Shed Light' that is between the Front Door and the Gate Sensor stopped working. Period. Premise was fine; indicated shed light was on; front door light was on... Front door light turned on; Shed Light should turn on; Nope. However, the Gate sensor which is farther than the Shed light worked, which I assumed was the next node between the front door and the sensor. No Shed Light.
What the heck?
Burned out bulb.... :wacko:
Tip? If it worked, then stopped. try manual mode before assuming Premise (and ETC) might be to blame  ^_^