What's the worst-case real-world "cost" of z-wave polling?

[NeverDie]

Not sure how cost should be measured, but potential consequences like latency (milliseconds or seconds of communication delay) and/or failure to deliver a message would qualify as costs.

Example scenario (probably not a worst case):
1. HomeSeer polls a z-wave device (maybe a thermostat).
2. At the same time (or nearly so), let's say a z-wave motion sensor triggers. Let's say HomeSeer is supposed to receive the z-wave message from the motion sensor, and then (as part of the ensuing event) send a z-wave message to a light to turn on.
3. Suppose the z-wave thermostat polling collides with the z-wave motion sensor trigger, and so both messages are lost.

Simple enough, right? At a minimum, there's going to be some amount of latency incurred to make things right that wouldn't have been incurred if the polling hadn't been happening. I would define that extra amount of latency (whether a little or a lot) as part of the possible cost incurred by polling.

"So what?" you say. i.e. how big a magnitude can those costs be in the real world?

It seems that many HomeSeer users intuit a cost to polling and so try to keep their use of polling to a minimum. I'm just wondering what those costs actually are.

For me, there are certain tasks that absolutely need to be extremely low latency or they create a WAF that "something isn't right" with the system. A simple example of that is pressing a switch that turns on a light. I'm not sure what the exact threshold is, but that all probably needs to happen within around, say 100ms for there not to be a noticeable delay. If HomeSeer is in the middle of it, then that gives only 50ms for HomeSeer to receive the message and lookup the events triggered, and then 50ms to send out the z-wave "turn on the light" trigger. So, how many milliseconds of airtime does z-wave message take? If it's, say 50ms, then really any amount of delay (incurred because of polling collisions or otherwise) would lead to the perception of unacceptable latency, and therefore low WAF.

I'm making up those numbers to illustrate the point. I'd like to know what the real numbers are. Even if z-wave is in many ways a black box, I shouldn't need to guess about this or do forensic experiments to find the answer. It's relevant.

[rmasonjr]

You are right on track with the WAF factor. I watch the wife and kids press a button and expect instant gratification. If it doesnt happen within a second or so, they start pushing again and again. Its really no different than using a smartphone or tablet or even typing on a keyboard - they all want it instantaneous.

On the polling side, the consensus seems to be to only poll what you care about HS knowing. It's been stated that polling is expensive since it could 'block' those other control commands that affect the users.

I'm curious how others will chime in on this too...

[NeverDie]

Looks like the numbers I pulled from thin air are actually close to the mark. According to http://www.homeseer.com/support/faqs/faqs_z-wave.htm:

"How fast is Z-Wave?
To send a single command to a device, and get an acknowledgement, takes about 50 milliseconds. This means you can control many devices with a single command and have them respond instantly."

It doesn't say, but I'm guessing 50ms is the "best case" that only happens with zero hops.

Also, according to the scientific references cited http://stackoverflow.com/questions/5...response-delay, the 100ms threshold for perceivable delay was established 30 years ago.

Implication? On those occasions where a polling interferes with a task that needs to be low latency (such as the z-wave light and z-wave switch example in post #1), then that polling will create a noticeable delay. The more polling you do, the more likely you are to experience noticeable delays.

Conclusion? Avoid polling whenever possible. If impossible to avoid, then do the least amount you can and/or schedule it for times (like the dead of night) when no one is awake or around to notice the delays incurred by it.

[NeverDie]

I'm curious how others will chime in on this too...

+1

Likewise, for similar reasons, you're better off using sensors that aren't z-wave and that (ideally) send their packets much faster than 50ms. That might rule out most OOK transmitters, which seem to be the most common type used by inexpensive non-z-wave wireless sensors (like x10). You probably want a sensor with heartbeats, but those heartbeats could have similar costs to perceptible latency as the polling has. So, maybe you put cheap, slower sensors at, say, 433Mhz, and more expensive wireless sensors that really need to be quick at a different frequency entirely? Of course, a wired sensor avoids collision and interference pitfalls entirely.