One more thing. The SDK did give me feedback for every command that the device turned on and then off each time with no failures. I have been testing the SDK and have pretty much tested all of the commands that are out there. It looks pretty good. The only thing I occassionally see is a polling failure when I do a command that takes awhile (like a timeout).
Speed of home control protocols . . .
- Thread starter ChrisWalker
- Start date
ChrisWalker
Active Member
Tom,Tombo said:
What brand and make of appliance module is that? It sounds like the software inside isn't hooked up to the hardware well enough. It may just be the ones you have, or it may be that those devices can't handle being tortured a bit (from the hardware side).
The Intermatic HA02 and HA04 modules we use here perform flawlessly.
Powering on/off the relay switches, what's your response time? I'm asking about "binary switches" in particular, not "multilevel switches" like the dimmers. These are fully-acknowledged commands, so we're dealing with the Z-Wave speed and not device-specific issues.
I ask because someone here would probably like a "second opinion" on this.
Chris
ChrisWalker
Active Member
Excellent. It's good to know that things are working well for you. Thank you for the feedback.Tombo said:
Regarding polling failures: polling is, of course, a background priority. So if you have a long-lasting foreground task, a polling call may fail (appropriately). We actually have it on our list to add some intelligence which would understand that a foreground task is going on, and will pause the polling call. I'm hoping that that makes it into an upcoming v1.1 beta. Please feel free to post this on the Technical Support [Beta] forum (over at forums.controlthink.com) if you haven't already.
Meanwhile, I'm really curious on your PowerOn/PowerOff response times on the relay switches (which include a full acknowledgement).
Chris
Squintz
Senior Member
Chris,
Send me that special test tool you have and I will try it out on my 23 device setup. If you are interested in only non-multilevel devices then please do some type of check in the code for those devices only. I have about a 50/50 mixture of both types and also a thermostat that would need to be weeded out.
Send me that special test tool you have and I will try it out on my 23 device setup. If you are interested in only non-multilevel devices then please do some type of check in the code for those devices only. I have about a 50/50 mixture of both types and also a thermostat that would need to be weeded out.
ChrisWalker
Active Member
Squintz: you've got mailSquintz said:
Chris
Squintz
Senior Member
Here are the UN_EDITED results of my response test. Basically what the code does in loop through each node (except the ones the don't support levels) and it request the level of the node 10 times as fast as possible before moving to the next node. You will notice one failure in the first run and no failures in the last runs. Also you will notice one node that has a significantly slower response time then the rest.
On average the results are about 125ms from the time the computer starts asking for the level data. There are several steps the computer has to take because of the loop so I am sure it could be reduced a little.
I am using ALL ACT hardware including the USB controller with a firmware upgrade. I can't wait to get my hands on some Intermatic for comparison. I would like to do a 50/50 setup and see them on the same network at the same time.
On average the results are about 125ms from the time the computer starts asking for the level data. There are several steps the computer has to take because of the loop so I am sure it could be reduced a little.
I am using ALL ACT hardware including the USB controller with a firmware upgrade. I can't wait to get my hands on some Intermatic for comparison. I would like to do a 50/50 setup and see them on the same network at the same time.
Dean Roddey
Senior Member
A more interesting test (and more representative) would probably be to each one once per round and do 10 rounds, so that you are doing something like a round robin polling loop. It would be interesting to see if things change because of routes being set up and reused in a loop vs. going a different route each time.
ChrisWalker
Active Member
Very interesting. What kind of product is node #9? That seems to the "slow guy" in your network. Also, node #19 seems to be having some bizarre routing troubles (or there was some sort of really crazy interference all of a sudden, which I doubt). It seems to have fixed itself in run02, but is it a bit out of range or something?
Just to clarify, this is the same program (source code included) that I ran for our local Intermatic speed test--albeit I had clear line of site, and some even quicker hardware. It looks like these devices are still getting amazing response times. 150ms to send a request to a device, get an acknowledgement, get a (separate) response back, and then send back an ackowledgement--including a whole bunch of serial latency--is very impressive for first-generation devices.
I also think it's cool that people are using the PC SDK to see how Z-Wave works more clearly. That's one more really nice use.
Chris
Just to clarify, this is the same program (source code included) that I ran for our local Intermatic speed test--albeit I had clear line of site, and some even quicker hardware. It looks like these devices are still getting amazing response times. 150ms to send a request to a device, get an acknowledgement, get a (separate) response back, and then send back an ackowledgement--including a whole bunch of serial latency--is very impressive for first-generation devices.
I also think it's cool that people are using the PC SDK to see how Z-Wave works more clearly. That's one more really nice use.
Chris
ChrisWalker
Active Member
Dean,Dean Roddey said:
You should pick up a copy of the SDK and create a test like that. With your coding skills, you should be able to do it in five minutes max.
Or maybe someone else here who has pre-ordered the PC SDK will write up a quick set of tests to test your scenarios.
FWIW, we have done those sorts of tests, and they are also very, very fast.
Chris
P.S. What kind of response times have you seen in your own representative tests, both in your development scenario and in testing in real-world installations? I know that you mentioned response times of 1s, but there's got to be something wrong there.
Dean Roddey
Senior Member
I've never tried a test just to see how fast a single module can respond, since that's not really very useful in the real world. I've just been going by the response I was seeing in our driver, but that driver does overlapped I/O and it lives in a highly multi-threaded object server where lots of other things are going on, so the numbers gotten from that wouldn't necessarily be very useful.
I'm going to get back into our Z-Wave driver this weekend probably, and I'll do a quick test of just single threaded response time in a single threaded test app, at the low level going straight to the controller, and see what happens.
If they would respond that quickly all the time, I'd throw away the overlapped I/O probably. But in the real world, some don't respond or get unplugged or are having sporadic interference, and you can't just stop polling and wait around for a couple seconds to see if a module is going to talk or not, since that stops up everyone else and the latency would go way up. So it seems to me that overlapping I/O is required as a practical matter so that you can always keep moving forward even if one or two modules per round-robin are being nasty.
ChrisWalker
Active Member
Dean,
Just as engineer-to-engineer advise, you should know that the way you are polling may cause unintended consequences which lower the value of both your software and the Z-Wave network its using.
You should really look into purchasing the Zensys Z-Wave embedded hardware developer kit and doing a lot of real-world testing--rather than trying to perfect a reverse-engineered implementation. You're also welcome to use the Z-Wave PC SDK where we've taken care of all that, but that goes without saying.
Chris
Just as engineer-to-engineer advise, you should know that the way you are polling may cause unintended consequences which lower the value of both your software and the Z-Wave network its using.
You should really look into purchasing the Zensys Z-Wave embedded hardware developer kit and doing a lot of real-world testing--rather than trying to perfect a reverse-engineered implementation. You're also welcome to use the Z-Wave PC SDK where we've taken care of all that, but that goes without saying.
Chris
Dean Roddey
Senior Member
I can't see any other way of creating a system that doesn't choke in the presence of a few bad or unavailable modules. If you just come to a stop and wait for some worst case reply time every time you come to a module that's not being happy, then latency goes way up. Even if you aren't purposefully doing overlapped I/O, if you give up quickly on a module that doesn't respond in a short time and move on to the next one, you are effectively doing overlapped I/O if the first module then responds after the fact, except that you probably just ignore the reply because it doesn't come while you are waiting for it.
From a practical standpiont, I'm not sure I see how it's much different than having multiple controllers on the the network. If controller A asks module B for a value and at about the same time controller C asks module D for a value, then there is effectivley overlapped requests on the network. This happens if you use a hand held remote while the USB controller is constantly active on the network, or your have two people press a transmitter switch at about the same time, while the controller is constantly active on the network.
Keep in mind that I'm not talking about multiple threads all banging away at the same controller at the same time. I'm talking about a single thread that's keeping a few outstanding polls at any time one time. It just sends the request, but doesn't wait synchronously for a reply. It'll get that reply later when/if it comes in. Once it gets a reply for one, it can then queue another one.
The other option, of just doing single threaded, one unit at a time polling, unless you are going to give up pretty quickly if no response is forthcoming, doesn't seem like a viable strategy. And if you do give up, then you are still kind of doing the same thing I'm doing now purposefully.
From a practical standpiont, I'm not sure I see how it's much different than having multiple controllers on the the network. If controller A asks module B for a value and at about the same time controller C asks module D for a value, then there is effectivley overlapped requests on the network. This happens if you use a hand held remote while the USB controller is constantly active on the network, or your have two people press a transmitter switch at about the same time, while the controller is constantly active on the network.
Keep in mind that I'm not talking about multiple threads all banging away at the same controller at the same time. I'm talking about a single thread that's keeping a few outstanding polls at any time one time. It just sends the request, but doesn't wait synchronously for a reply. It'll get that reply later when/if it comes in. Once it gets a reply for one, it can then queue another one.
The other option, of just doing single threaded, one unit at a time polling, unless you are going to give up pretty quickly if no response is forthcoming, doesn't seem like a viable strategy. And if you do give up, then you are still kind of doing the same thing I'm doing now purposefully.
