One advantage of taking the batteries out is that that doesn't require that associations have been set. That will cause a node info frame to be broadcast. So, for units that aren't yet set up, that's sort of necessary because wakeups are only sent to associated nodes. Until we get the unit set up, it's not associated yet, because we don't know if it supports association and what group we should add ourself to.
So try one with a battery removal.
I did, that's what I was trying to convey in my last post. Pulled the battery again unit 0x1B, emailed you the trace.
There's nothing in there. I think maybe you are not stopping or flushing the trace before sending the file? If so, you aren't going to get the last bit of output.
The Linear WADWAZ-1 documentation very clearly indicates that you only have to remove the cover to wake the unit up.  However I have removed and re-inserted the battery just to make certain that the documentation is not wrong.    
Just so we are on the same page, here is how I captured the log:
1) Make sure Tracing is off
2) Reset Trace
3) Turn Tracing on high
opened WADWAZ-1 counted to 10, pulled battery counted to 10, put battery back in counted to 10, closed cover after counting to 10
4) Stop Trace
5) Flush Trace
6) Look at trace file, trace file has timestamp of when I flushed, that's it, nothing else.
Z-Wave USB3 Trace
,  Time: 7:40:20 PM
----------------------------------------------------
I am certain that I am looking at the correct unit, confirmed that open close action is reflected in VRC0P driver.
Did it again, this time flushed before turning off trace, same result...
Z-Wave USB3 Trace
,  Time: 7:59:17 PM
----------------------------------------------------
There you have it unless I'm doing something above out of order.
I'm not believing that the SmartThings master hub is the issue as clearly it is working for the the locks (except battery status accuracy) and for the hard wired devices.  You've done special handling for the locks with the security protocol and all, perhaps there's a bit o something missing somewhere for none secure battery devices...
The Linear unit that I approved from earlier does not reflect any data in the driver tab, only shows ???.  Do I manually need to do an auto approve action?  Clearly something is not working there.
BTW, the battery value for both of the Yale YRD220 locks is being reported inconsistently; SmartThings indicates 91% for the garage door lock and 69% for the front door lock, where as CQC indicates 87% for garage and 57% for the front door respectively.
Now that I have typed all the above I went and checked the status of the YRD220 door lock in the driver and it is not consistently reflecting a lock status change if I unlock it from the SmartThings app, however, I can lock and unlock the lock from the CQC driver.  
Trace activity:
From SmartThings
Lock
Unlock
From CQC
Lock (no message went through to Smart things, lock remained unlocked first time, unlocked from CQC, locked again, worked 2nd time)
Unlock - worked
Trace for this activity was just emailed to you.
I'm not sure if the Yale locks send out a notification if they are changed by software command or not. The trace you sent me is too much for this type of detailed testing. It really needs to be specific, individual operations captured at a time. I don't know when you did what exactly in time, so I can't say for sure what is going on.
So let's do one thing at a time. First let's see if we get a notification when you do it via Smartthings. So reset the logs, change the state via Smart things. Wait a few seconds, then close and send the file. If it doesn't then, there's no much we can do. STs knows since it sent the message. We could only know if we polled quickly, which is not a smart thing (no pun intended) to do since it is battery powered. If STs is polling, then that might account for battery suckages.
When I asked before, I was mostly interested in what it does when you lock/unlock it from the door itself. That's where we know it absolutely should send a notification, and we can see what it sends. These Yale locks still use the old Alarm V1 stuff, which uses completely arbitrary vendor defined codes, so we have to just try them and see what they send. So it would be good to do the same as above, i.e. reset, lock the door via keypad, wait a few seconds, unlock via keypadd, then go back and stop and send the file.
Actually, on the trace file... You might be doing it at least less conveniently for you. Reset truncates the file when it's open. So it lets you keep it open but keep resetting it. Each time you can flush, grab the contents, then reset and do another one. But, stopping and starting it again also resets it, so as long as you did that, it should also reset the file. But, generally, if you want to grab a set of things, enable it, reset, do something, flush, grab the contents, reset do something, flush, grab the contents. That's the least steps possible.
As to why we see nothing from that unit, that makes no sense. The only thing I can think of is that it doesn't transmit a node info frame when you change the batteries. I thought that was basically universal but maybe its not, when has Z-Wave ever been consistent? Maybe it only sends one upon being included into the network, so only the master server sees them. If that's the case, then no secondary controller could ever auto-id it since that would require a wakeup which it will never see because it doesn't know how to do the association until it knows what the unit is.
If you added it to the network after our driver was in the network, maybe we'd see it then, but it wouldn't matter since we wouldn't know it exists as a valid node until you replicate us from the master again. So catch-22 sort of.
If that's the case, the only way to do it would be to make it wake up, then force it to rescan while the unit is still awake. When you force a rescan the driver will make one attempt to talk to the unit, even though it is battery powered, on the hope that it's awake right now. If it's actually awake now, it can talk to it and will go through the whole process (hopefully.) Normally it would do this once it saw a node info frame, but apparent it's not going to.
So give that a try and see if that makes it happy.
Version 5.2.916 is posted. It includes a number of small but quite useful additions to the interface system.
Driver traffic trying to reconcile battery operated devices was hammering my zwave network / SmartThings hub to the point that I was getting errors on devices not reporting in as such I've paused the driver. I will update to .916 in the next day or so and then attempt to capture individual traces of discrete events between the YRD220 lock, SmartThings and CQC.
At least one hard wired device is not behaving well in the above state either.
On v.916 
For the sake of testing I just deleted everything and started over.
To Exclude:
1) told SmartThings to remove Z-Stick
2) told CQC driver to include / exclude
3) delete driver
3) delete ZWaveUSB3S directory on master server (where driver was loaded)
Driver reported back that it was excluded, SmartThings reported that device was removed
To Include:
1) Loaded new zwave driver
2) told CQC to include / exclude
3) told SmartThings to add new device
4) SmartThings confirmed new device added
5) CQC confirmed joined (now has status of joined to network)
6) CQC Client driver empty, no devices
Now what?
Okay, so something went wrong.  Started over, did the same as above, now all devices show up.
Only 1 lock has lock status correct, other 2 have ???.  YRD 226 recognized properly
I had to manually associate driver to the lock.
For wired devices:
Wayne Dalton and ACT switches have nothing showing up for Value field, shows up as a v1 device.  (this worked on older release prior to changes you made)  No control
GE light switch showing up properly as a v2 device and can turn on and off properly
Fibaro RGBW showing up properly as a v2 device, and is fully controllable
What do you want me to send you a trace on?
Given all the issues you are having, I'm assuming that there is just not good comms between the Z-Stick and some of the other nodes. For all these failures to happen, and for them to be fairly random, that's about the only thing that would do that. If it has question marks that just means it can't communicate with those nodes to get any value.
Can you try getting the Z-Stick into some more advantageous position (up above any computer gear and metal rack and all that?
You can turn on trace, force an include again, which will basically make the driver go back through the motions, let it come back up and run for a minute or so, then stop the trace and send me that. That'll show me everything going on as it's trying to get up and running.
(05-31-2018, 01:41 PM)Dean Roddey Wrote: [ -> ]Version 5.2.916 is posted. It includes a number of small but quite useful additions to the interface system.
The unsaved "*" tab indicator is really useful. Now no more changes lost because I didn't save a template before closing out window.