I got a parameterizable light switch handler done last night. Not a generic one, but one that can be driven by the device info file. Just to see how hard it would be to do by eye, and how likely we could get accurate info I did a device info file for the Aeotec DSC24 switch, without having one to test. Hopefully someone has one of those to test so we can see how well that sort of thing will work.
I can do a generic one as well, similar to the generic dimmer one I've already done.
I added a 'save config' option to the main options menu, which will just let you store away the configuration file somewhere locally if you want.
I'm thinking probably I should get what I have out there. I think everyone should just assume that anything they set up with this first drop may have to be thrown away potentially. But mostly we just need folks to start gathering device info captures to help use get these devices supported. Worst case sometimes it may require using the remote port server to let me get to their Z-Stick to see for myself what a unit is doing.
And it won't be just the info file, but also the trace file mechanism allows for capturing lots of useful info. In most cases the thing will be, don't try to assign a type to it. Just manually set up the appropriate association (maybe we might need to try to configuration parameters), flush the trace file, do some stuff on the unit, close the trace file, and send me that and the device info file. That will typically be enough to know what is required.
I think I have all of the changes required for the installer and installer image builder. So I'll get a build and do some testing in the real environment and production build to make sure it's all still happy that way. I've only run it so far in the test harness in debug mode.
I started testing out the new driver in the real environment, and immediately realized I'd introduced some problems when I made the changes required to allow the server/client side drivers to be loaded into my new C++ driver test harness. Digging into that brought up some other crufty bits that I needed to fix which I've (I hope) just finished up. That was quite a day of head scratching.
I seem to have the above issues straightened out. I need to make sure I've not broken anything else obvious. I also updated the driver so that, when new units are approved, it automatically queues up auto-config commands on those units to get them configured without any human intervention.
The auto-config option is still there so that it can be re-applied if need be. And of course if it's a battery powered unit, the msgs are just queued up until the device wakes up. That should help avoid some confusion hopefully.
I'm also updating it to have the auto-config stuff to be sent out at a random time for each unit, once a day. That will just insure that, should something mess with the configuration that it'll get back correct again before too long.
Okey dokey, I think she's ready. I'm not going to do a release tonight since I'm so brain fried from a long day of chasing down weirdness, but probably tomorrow should be not a problem.
I also figured out something nice. The AI can't download client side driver files to the Program Files area, since that would involve an admin prompt. So it downloaded them to the C:\ProgramData area. That's not optimal for a few reasons. But, the client service is there on all machines, so I changed it to just ask the client service to download the files, then it can put them in the normal place. Once there the AI just reads them, which is fine. So one more moving part in the process, but ultimately a much better solution. And I made various other improvements to how C++ driver files are downloaded and loaded up.
Anyhoo, it seems to be working well, and I don't see so far anything that I've broken (and not re-fixed) with the various underlying system changes mentioned above, and other ones required to get my new C++ test harness working.
I got the release with the zwave driver updated on everything and added the usb stick to my Smartthings network. Smartthings recognized the usb stick and added it but none of the devices got copied over the usb stick. Unfortunately I wont have time to troubleshoot for a few days.
We'll probably need to get a trace of the activity during the inclusion process. The only master I know it works with of course is the Vizia RF one. But the process is well defined, so it should work with others. Though, it does depend on how the master added it. Did it add it as a secondary controller?
It just says z-wave controller. I might have time to exclude it and re add it later and can get a trace of that. When we were messing around with smartthings and the VRCOP I feel like there was a special order for things.
Edit: maybe this thread -
http://www.charmedquark.com/vb_forum/sho...martthings
That all looks pretty obvious. In that there's two steps because you have to replicate ST to the VRC0P and then the VRCOP to the driver. In this case it's just VRC0P to the driver.
We can look at the trace and that will tell us a lot. Also, what does the driver show? Does it show that it's in the Z-Wave network? That's one of the particularly stupid things about Z-Wave is that there's no final step of "I think it worked, do you think it worked?" One side can fail while the other side thinks it worked.
Even worse, if the master thinks it worked, if you just try to re-include again, it won't go through the security stuff because he thinks it's already got that. So the inclusion 'works' but the driver isn't any better off because now it's included non-securely and can't do any secure stuff. You have to exclude it and try again.