The GetClasses ones will be the battery powered ones. They can't go any further than getting basic node info until they wake up. Actually they will all wake up on their own at some point, which they do periodically. So by the time you get home they should have all done that and be in WaitDevInfo state.
I've gotten distracted by trying to finally figure out all this custom drawing stuff so that I can get the multi-column list control's column headers to color themselves. I swear this custom drawing stuff is one of the biggest jokes of all time. It is practically impossible to figure out. The header of the list view in particular is a mess to deal with.
I've made some progress, but basically it's every time I squeeze over here, something pops out over there. The problem with the header (and other older controls) is that it's an all or nothing thing. Once you say you are going to custom draw, you have to do everything.
I'm sort of tempted to go back to my own that I was working on a while back. It would probably be easier and a lot easier to maintain over time as well. I already have the header control part of it done.
Hmmm... I'm already wrapping the list view control (the mc list box) within another window. I could create it without a header, use my header, and just adjust the list view's column widgets accordingly as the user drags my header slots. That might be a reasonable compromise to get around the complexity. The main backing window would just keep them positioned correctly.
Dean,
My kwikset lock is recognized but it is not properly reporting the battery status.
The driver won't get that until the lock reports it, which it will do periodically. So give it some time.
Well I gave up again on the list window column headers background. It's just impossible to get right. It'll just have to stay as it is until I get a chance to work out my own replacement.
It has been a couple days and appears to be current in Smartthings...
Is the lock state itself showing correctly if you lock or unlock it from the pad? If not, then probably something is awry with the associations so the driver isn't seeing any async notifications.
If it goes recognized before the last drop, then the auto-config was not really auto, you had to do it manually, so you may want to force an auto-config on it.
BTW, you can use the manual associations dialog to query the associations for group 1 on the lock and see if the driver is associated with it.
I have dev info files for all of the modules I've got dumps on so far. I'll get a new drop up here in a bit. I had to under my ill fated list header background stuff above, and took care of one thing that I noticed while do that, and needed to make sure I'd not broken anything.
I posted revision D of 5.2.904. I forgot to put D in the comment, but it'll have today's date in the installer time stamp April 4. This one has device info files for all of the devices I've gotten dumps for so far. So far they've all fallen within the realm of handlers I've already done. So, in theory, they just need these device files to work correctly. Though we need to verify which CCs are being used to report async changes where that is supported. If the ones that support notifications are correctly updating when a change is made on the unit itself, then it's good. Of course also verify that field writes work. It's possible I got something wrong there as well.