dean, how do we get the z-stick added as a secondary controller? i read the manual and it says that you must have it plugged in and use software to allow it to be included into an existing zwave network. does the driver do all of that for you once you get it plugged in and configured?
Yeh, the driver does that. Basically you just add the Z-Stick to the network just like any other unit. So it's just the standard unit inclusion process. You put the master into inclusion mode, and the client side driver interface will provide you with an option to put our driver into inclusion (or replication) mode, and that will cause the master to see we are wanting to be included and the process will begin.
The first you do it that adds the driver to the network. The master tells the driver about what units are currently available. In the case of security capable devices, that's also how the device (or our driver) gets access to the security key required to talk to secure devices.
That's also how the driver learns about newly added units. If you made changes to the units defined in the master, you just run the inclusion/replication process again and the driver is told again by the master what's out there now, and updates itself accordingly.
So I have the basic scheme for the client driver to talk to the server driver worked out. At this point, I'm going to take a short detour and do something that's needed doing for some time. Currently for C++ drivers, all I have is a simple command line 'IDE' to work with. It's not possible at all to test client side drivers other than in the actual scenario, with the server side driver really loaded and the client in the AI.
That's just too limiting, and the turn around time to make changes is way too long. It's made me really stay away from doing client side drivers, and making them no more than what they absolutely need to be when I have to do them.
So I'm going to take my little command line guy and make it into at least a primitive but functionality GUI based one, which can load the client side driver and have them talk to each other there locally within the program (though neither will realize it.) This may take four or five days, maybe even a week, but it'll be well worth it long term. Ultimately, I'll probably make those days up in less time spent working on just this Z-Wave client driver, given what all it needs to do. And it'll save far more moving forward.
BTW, this isn't a debugger of course, I do that with Visual C++. This is a way to see and modify fields, send backdoor commands, see the driver status, that sort of thing. And now of course to run and test the client side driver.
I got a good initial chunk of the new C++ driver harness worked out today. To be fair some of it I could steal from the CML one since the bits about starting a session, selecting a manifest and so forth is basically the same. After that they will deviate a lot. I'll work first to just get my old functionality, the server side driver, going again under this new regime. Then I'll look at how to get the client driver hosted there. Getting them talk may take some work since they won't be able to talk the normal way. Luckily it's all through our object request broker so it should be not too hard to lie to them. I just don't want it to require any substantial changes or intrusive code on the part of either driver side.
are you talking about the aeotec zstick in this thread, or another one?
Yeh, the Aeon Z-Stick Gen 5 is what I'm using. In theory any raw Z-Wave interface type Z-Stick would work, but there's no point really worrying about. Just get that one.
I've just about got the new test harness running the server side driver. I was slowed down somewhat by the fact that I need some stuff that was designed to be used on real running drivers, but I need it for this guy, and I didn't want to replicate that stuff, so I had to do factoring out of some things. And I had to add a thing to the server side driver to provide local field polling, again because the driver isn't running in the real environment. These are just direct calls into the server side driver in this case.
But anyhoo, it's pretty close. Hopefully I can get it workably along tomorrow. Then I'll figure out the client side bit. It's going to be a big improvement over my little command line thingy to say the least.
OK, I pretty much have the server side bit of the harness working. A few bits and bobs to add at some point, but basically it's there. Way better than before for sure. So on to the client bit.
If you give me a weeks notice, i'll order the AEon zstick and beta it. No point in having still yet another device laying around and then losing it when there's a drop ready. Like the 3 things I'm currently hunting down that I'm finally ready for but can't find
It looks like the wiring in of the client driver is going to be not so bad. A bit of grunt work code to create a faux version of the driver admin remote interface. This one just takes a pointer to the server side driver and directly passes the calls on to it. A simple 'test mode' flag on the client side driver to make it look for an alternative server side interface object to talk to is all it needs.
I've just about got all of the changes made. I just need to have the new test harness create the client side driver object (where there is one) when the driver is started, and set the test mode flag on it, and in theory this is all going to work. Probably I'll end up figuring out some oddities, but it turned out a lot more straightforward than I figured. There is some redundant code with the real one in CQCServer, but nothing to be done about that.