Speed of home control protocols . . .

[Dean Roddey]

I am impressed by the amount you have been able to discern about how Z-Wave works by analyzing communications between some software program and a Z-Wave controller.

That's not the case actually. We talked them into an intermediate scenario. They blessed some company to deal with folks who don't want the whole dev kit, and we got some documentation from them. Our problem was that the folks they hired had no idea what was actually required, so though we were paying them, I was doing the work to figure out what headers and documents were actually required for someone like us, who just need to interface to the Z-Wave system, not to develop hardware.

So we have the headers and most of the docs that are relevant for our particular need, but not a full kit. I really abused those people that we got this stuff from, because I was so pissed at the time about Zen-Sys' attitude and then they send us to these folks who want us to pay them to do their job for them. They were kind of caught between a rock and hard place I guess, with Zen-Sys not really caring about third party automation system support and probably not giving them any real help to figure out what was required, and me really needing the information and pissed to have to be spending our limited revenues having to figure it out myself and paying for the privilege.

As for how we take care of the issue at hand, let's just say that we do not use one particular method, but a variety of methods which adapt to different types of installations at different times.

That's an easy answer of course. But the proof will be in the pudding, once someone actually builds a non-trivial system on your SDK we'll see how well it does in terms of polling latency for larger systems.

 

[ChrisWalker]

But the proof will be in the pudding, once someone actually builds a non-trivial system on your SDK we'll see how well it does in terms of polling latency for larger systems.

Dean,

There is no magic bullet, but there are lots of tools to take care of things. I'm not going to make any promises regarding optimization of polling times in large networks, as there are lots of other factors to consider. Certainly, there is no reasonable way to obtain sub-five second full device polling status updates with hundreds of Z-Wave devices. I personally don't think that's even necessary. But I do know that we will continue to tweak our algorithms and take advantage of the latest Z-Wave hardware and firmware to increase overall network performance in the interest of the consumer experience.

In the end, the reason it's so important for these kinds of software to have a Z-Wave certified implementation is largely because such software is truly becoming part of the network: the Z-Wave USB/Serial interface is not a high-level serial-based abstraction, but a set of power tools for sending, receiving, monitoring, and controlling an RF network at a level significantly lower than something like TCP would offer. Between it and the PC SDK, that power can be harnessed in a simple and interoperable manner.

Chris

 

[ChrisWalker]

That's not the case actually. We talked them into an intermediate scenario. They blessed some company to deal with folks who don't want the whole dev kit, and we got some documentation from them.

So are under NDA with Zensys then?

Chris

 

[Dean Roddey]

Yeh, we still had to sign an NDA for that. And we've honored that. There's no reason for me to want to help anyone else get info that would let them compete with us, so there wouldn't really need to be any legal constraints in my case.

 

[Dean Roddey]

So I finally got a little time to play around tonight. Mainly I'm just cranking up my little offline Z-Wave test harness program a lot, so that I can do some extensive experimentation before I take another whack at the driver.

I haven't put any actual timing in it yet, but just doing some eyeballing testing at first. This is a simple completely passive program that doesn't poll or anything, it just does stuff in response to a request. For units here in the same room with me, the response was obviously sub-second, probably less than half a second.

Then I tried one at the other end of the apartment, and it was obviously taking over a second. I did it a number of times and it was responding consistently much slower.

So I went in there and re-added that module to the remote, and then re-replicated to the PC controller, and then it went down to pretty close to the same speed as the local units.

That's actually a little strange since all of these units are fixed position, so you'd think that routing wouldn't really be changing. I'd hate to think that for optimal performance you'd have to go around and regularly re-add units to the system or something.

Of course this is all in a dead quiet network without any polling going on and all the modules are happy. I'll have to do some much more abusive tests.

 

[Squintz]

So I went in there and re-added that module to the remote, and then re-replicated to the PC controller, and then it went down to pretty close to the same speed as the local units.

That's actually a little strange since all of these units are fixed position, so you'd think that routing wouldn't really be changing. I'd hate to think that for optimal performance you'd have to go around and regularly re-add units to the system or something.

You don't have to go around and re-add devices. The rediscover option is available to the early version USB Controllers also. The catch is that you need to take your laptop or USB able PDA around and use it to learn all the devices the first time. This way you USB controller is set up as the master controller and you have full functionality.

I hear someone people(HS) complain that this is not practicle for it users. Well I say it should be practicle for CQC since it's targeted toward installers. And if you wanted to make both people happy you can do what the ControlThink SDK does and support both the USB as a master and secondary controller.

OR

You can get cracking on the xAP support for CQC so that if/when i get my service finished your users could use it.

 

[Dean Roddey]

It wasn't so much the 'having to walk around' part, it was the 'why would a fixed position set of nodes degrade over time and require a fix'. Since, either way, someone has to determine that this degradation has occured and invoke the repair. You don't want the user to have to wonder, if some issue arises with a module, if he needs to relearn them or not.

 

[Squintz]

One theory as to why it might degrade is because you used the hand held to program that device. When you add a device its routing table is configured there and then. So if you configured that device first it does not know of any other devices it can route through. So as you add more devices the latest one you added will probably be the most reliable. The first device probably still does not know that it can use the others to route through.

After all the devices are installed and you attempt to control that device which is far away it initially is trying to use the routing table it determined was best at the time of installation. If it determines that a node is missing it will try another device to route through.

So, I may have a few things above a little confused but the basic principal is correct as far as I know. Using the rediscover feature after all the devices are installed should maximize the performance.

 

[Dean Roddey]

Maybe so. But it doesn't seem like a likely theory in this case. These modules have all been where they've been for a long time. In my various experiments, I've re-added them all quite a number of times since they've been installed.