OK, I seem to have the client driver working. I spent an extra day because I ended up factoring out some more common code. And, I realized that I don't have to do anything special hardly at all to get the client and server sides talking to each other inside the test harness, so I undone some things I'd done.
And, in the process, I figured out that I was doing twice the back and forth necessary to get the regular client and server sides talking to each other in the normal scenario. So this change both makes the regular system faster and the test harness simpler. It also applies to all client code needing to connect to a server side driver and get data, which is extremely common. So that was well worth it.
I'm testing it now with the variables driver which already has a working client side driver, and it seems to be doing fine.
OK, I have the new test harness pretty well worked out now. This is going to be SO much better. I still need to add a few things, like ability to do a couple backdoor type calls, but nothing significant. I can start and stop the driver cleanly, and it's all working nicely, and the above mentioned changes make it clean and easy to redirect the client back to the test harness.
Another victory against the machines, I must say. So, I'll get back to the Z-Wave driver yet again and get the client driver worked out. Now I know I'll more than save the time I spent doing this test harness, and it'll end up considerably nicer than it would have otherwise.
I'm banging away on the client driver. There was a good bit of just plumbing stuff to get into place before I could really even start on the actual functionality, but I'm ready to get into that tomorrow. I've got a basic layout for it that's simple but should offer plenty of capabilities.
I'm starting to get some functionality in place and working finally. This one is different from any others in that the configuration can change other than by you editing and saving them. So it's more complicated. Battery powered units can wake up that we've not talked to and we get information about them, possibly auto-identify them. That changes the configuration on the server, and maybe you've made changes that you've not saved. So how that is dealt with is tricky.
OK I've got something like a functioning setup now. Still a good bit of detail to deal with, but it's starting to shape up. The work on the new test harness is definitely paying off. A lot of the stuff I worked out today would have taken so much longer otherwise.
I banged out a lot of stuff today. My brain is starting to make weird sounds. I got the replication/inclusion interface stuff done. And the stuff to approve newly recognized units that have woken up after first being added and we auto-recognized them.
I'm getting into the unit configuration stuff now. That involved some special issues. Only the actual specific unit handler classes know what the option are for the unit. But the client interface needs to know them. So I had to be able to create the on the client side but be sure they don't actually try to do something which won't work because it requires the server side driver be there. I needed to add a delayed load of the attribute editor as the selected unit changes, since there's a bit of overhead involved in getting that info. So if you just run the cursor down the list it won't beat the driver to death.
The big thing now will be selecting a type for those things not automatically recognized. I need to set up a couple generic two way off/on and switch/dimmer handlers which is what the bulk of unrecognized things will end up being set to. And I need to get the auto-config and manual setting of associations and config parameters stuff done. That shouldn't be much work.
The work I did earlier to set up a nice generic communications scheme between the client and server side drivers is paying off a lot. It would be nice to just create a custom ORB interface but that's not possible without a lot of complications. The standard driver ORB interface serializes all calls so the driver is always running in the same thread. That massively simplifies things. A separate one would then start calling in on a separate thread, and everything would have to do lots of locking. So not worth it. The scheme I set up is pretty easy and has been working quite nicely, which just uses one of the backdoor calls.
I spent the last hour, too fried to do anything else, making a change to the build tool to add a feature that I'd wanted for a long time, and it will really help a lot. Basically the ability to had 'group' targets, so a project that has no code but just dependent projects, so that I can cause a build of an set of projects that are not themselves directly dependent on each other (e.g. the client side, server side, and shared facility of a C++ driver, and any helper stuff like the device info compiler in the case of this new driver.)
Dean, in your usage of the Aeotec, is it a primary or secondary controller? If secondary, are you using the VRUSB as primary and replicating to the Aeotec?
I ask as I can't get the VRCOP to talk to CQC. Details irrelevant there as I already bought the Aeotec, just wondering if 5.3 will require both VRUSB & Aeotec.
The Z-Stick is a secondary, so you still need a primary. I'm using the VRUSB and Vizia software as the primary myself. On the VRC0P, be sure to check the baud rate. You have to either set the driver to the baud rate it is at, or send it a command (using the current baud rate its at) to set it to the baud rate you want the driver to use.
Yeah already did the baud rate a few times. Work is still psycho so I'm content waiting for 5.3 beta. CQC isn't like UDI where defects addressed in 8-12 week cycles and 3+ years to go G/A
