(05-24-2018, 01:46 PM)Dean Roddey Wrote: [ -> ]Well, the best I can tell about the Schlage lock is that it is a buggy piece of junk. It just doesn't work right. I noticed it's not even a Schlage lock, it's made by some generic Chinese company and branded by Schlage. Half the time it just doesn't respond to anything. I set up the device info so that you can set the type manually, but it doesn't work. It doesn't seem to send any notifications or respond to any queries. Once in a while it responds to a battery level query. One time in many it will get through the device info queries successfully.
I've seen various other complaints out there about these older Schlages. Apparently they were not so great, and I can't see what else to do.
Of course there may be issues because it's not actually in the door and there's something about the actual bolt being int here that causes it to act differently. But, it's not responding to lots of other things besides the door lock state.
It hasn't destroyed my Z-Wave network, but yours is more complex than mine.
That's not good news. you can turn the mechanism and it will act like the bolt is extended.  Over the next few days will do some more testing. Seems to work great with the vizia Rf+ stick.
The Vizia guy isn't trying to get any information from it, or only very basic stuff that it gets at the Z-Wave level, it doesn't really interact with devices in the way we need to. Mostly it just sends BASIC SET commands to devices. So it's not really trying to do much.
(05-20-2018, 06:09 PM)batwater Wrote: [ -> ] (05-20-2018, 11:17 AM)Dean Roddey Wrote: [ -> ]Activity from the unit doesn't wake them up. When they send out state changes they wake up just long enough to send that msg and go back to sleep immediately. There's no chance to talk to them. That can only happen when they actually wake up, which causes them to send out a wakeup msg which means, talk to me know if you have anything to say. If they are sealed, and have no external button to make them do it, then presumably you have to just wait for them to do it themselves, which they will do eventually, though it can be many hours in some cases. Until that happens any setup won't have been sent to the device. Also, if you cycled the driver or CQC while waiting for that to happen, those msgs will be lost. Battery powered devices sort of suck.
Okay I get that I have to wait but for how long? Last go around before I rebooted this morning was for something like 4 days with no updates showing up on any battery device, something is not right.  I think I mentioned that my z-stick is continuously cycling between Blue, Orange and Red.  So while the wired units and the battery operated locks are operating correctly none of the other battery powered units are.  I'm wondering if I should start over and nuke everything, remove the z-stick from the master controller, and re-do everything?  If I get the same behavior at that point I can open my system up to you for diagnostics.
Have you tried the latest version? This should deal with the battery reporting, at least on those that I knew needed to be done, which are the Eco ones. If you have any others that aren't reporting battery after .914 let me know and I can adjust for those as well. I wasn't sure which ones it might be.
Anyhoo, give that we are early in the process, and a lot of bits have passed under the bridge, it might be worth you starting it over. You can exclude the driver, unload the driver, remove the Z-Stick, then re-add it, then load the driver back and include it again. If you don't want to mess with the wakeups, just let it go on its own. They'll all wake up over the next hours. Then just approve them all. 
[this bit is wrong, see below]
However, that will leave the auto-config msgs queued up to be sent. At that point, you should make sure you get those sent, by either waking up the battery powered ones, or just letting them sit again and those messages will be sent on the next wakeup. Until that happens, they are not configured and stopping the driver will lose even those pending setup msgs.
Oh, no, wait, some of the above was wrong. I changed it some time back so that it will send out the auto-config in the same wakeup that gets the man ids and takes it to WaitApprove state. So you DON'T need to do the manual wakeups if you just want to let it set until they all auto-id. The config msgs (assuming no transmission failures) will have been sent. Then you can approve and it should be all done other than naming units (if you don't get names from the units themselves) or setting any options. And I guess any manual setting of unit type on ones not auto-identified yet.
I've been on .914 since you put it out on 23rd but other than upgrading haven't had time to make anything work. None of the battery powered units other than the Yale Locks have auto-id'd.
As soon as I get some free time from other honey do projects this weekend I'll go through the steps above and drop and re-add the z-stick to SmartThings and start over.
The other option before I drop and re-add is that I can open my system up for you to poke around if that would be of any benefit. I would think that if it weren't working properly then none of the devices would show up for approval and work correctly.
Wait, I just checked, the yale locks while correctly identified and approved are not populating with battery or lock status. Do I need to associate each lock to the driver, did I miss a step?
Okay, I have some free time now to delete all and start over but I'm not clear on how to "Exclude" the driver.
You exclude just like you include, put the master into exclude mode and run the include/exclude operation on the driver. Be sure to clean up the config file after you have unloaded the driver.
I've made the changes necessary for the main tabbed window in the Admin Interface to show when there are changes in a given tab. It'll have an asterisk after the tab name if there are changes. This is something that has really been missing in an otherwise getting pretty dang good admin UI. I need to bang on it some more tomorrow to make sure I've not missed anything, but that'll be a nice addition for 5.3.
I followed above instructions to start over, went as far as doing a factory reset on the zwave stick and I am getting identical results. Re-install was done about 16 hours ago and other than the Yale locks none of the other battery units are filling in. I can confirm that according to SmartThings all of my battery powered units have checked in within the last hour.
There seems to be something about my setup that is preventing the driver process from flowing correctly.
The only thing I can think of is that SmartThings is overwriting the associations or something. We need to see what associations are set on these guys. Most of them, if you take the batteries out and put them back in, will stay awake for a little while. Do do one close by, then go back and use our manual associations dialog to query the associations for group 1. Have it up and ready to go and you should be able to get it before it goes back to sleep. The Ecos typically will stay awake for a minute or so.
If the Z-Stick is in the list of associations then we should be getting talked to.
Also of course just enable tracing and let it sit for an hour or so. Then close it and send me the trace file. We can see if any of them are talking to us.