a 5 second poll time means there's the potential that because of a lost command, someone could hit "showtime" and the lights won't dim for over 5 seconds. I guess that's my point. As I stated earlier, bad devices will be uncovered when the system tries to command them and cannot.
The latency issue really doesn't apply to outgoing commands. They'll do fine since they are proactive outgoing commands from the controller which will usually be acknowledged. The lights will dim immediately, or pretty close to that in most cases. It's the getting the status back part that's the issue. Generally, you won't bother to check a light to see if it's off before turning it on, you'll just turn it on.
Devices that take a long time to power up or down or which have consequences, you would want to check first, and there you have to deal with the latency issue, and be aware that you might not have absolutely up to the minute information. It would be very nice if you could, but that's up to the people who make the devices and the realities thereof. If someone makes a devices that has significant consequences if you turn it on or off when you shouldn't and that can only be polled once a minute, that's just a sucky device that you shouldn't buy.
But, in a fast wired network, it's generally not a problem to get quite snappy updates of status, even in a pure polling scenario in a large system. Even a high speed serial line can provide low status latency on a point to point basis if the protocol isn't really bad.
Z-Wave and UPB I'm sure can do well in smaller systems UPB probably considerably better as long as the notifications are working well. I'm using Z-Wave, which is a purely polled system, with just 6 devices, and the latecy is generally less than a second, becasue the driver does overlapped polling (i.e. it keeps more than one poll operation outstanding at once.) But in another customer's system, with like 16 to 20 modules, it's more like 10 seconds latency. That's also probably due to the fact that the Z-Wave network is straining a bit and not all modules are reliably responding the first time they are asked for status, and that slows things down.
It could probably be gotten down to closer to 5 with a more agressive polling strategy (which we'll be experimenting with) and some tweaking to make sure the mesh is all filled in nicely. And we'll also probably be adding the ability to prioritize modules so that some will be polled faster than others.
Outgoing commands are practically instantaneous in both our systems, so that's not an issue really. And since it's a polled system, you will always know within the polling latency time, if something has gone away.
That's not to say that Z-Wave's polling strategy is better than UPB's broadcast strategy. I wish Z-Wave did the same, because it really does help a lot. But it doesn't get the automation system out of the job of making the rounds and tapping on the doors to make sure everyone is safe and sound, and that does eat up bandwidth, which is pretty darned limited on the powerline. A littles less so on Z-Wave/Zigbee.
On an ethernet type system, you could run a very large home without problems using a pure polling strategy, or a a combination of status broadcast and a backup scheme of activie pinging, or both in a mixed environment. The driver just keeps a map of all known modules and every time a broadcast status or a reply to an active ping comes in, it marks that module's entry with a time stamp, and pushes it to the buttom of the list. So it can keep a list of who's being naughty and who's being nice. The guys on the top of the list are naughty and haven't been heard from lately and it can prioritize it's active pinging by working down the list all the time.
Protocols like xAP in fact depend completely on the fact that everyone is regularly sending out 'heartbeat' messages which don't say anything other than, "I'm here, don't worry" and "I'm here, if you are looking for me", so the automation system in that case, can be quite passive and only actively ping those things that have not sent their heartbeat message in the time frame they are supposed to. xAP is ethernet based, so it can afford that kind of overhead easily.
