"status request failed" followed by status

I'm seeing the following sort of thing more and more:

Code: Select all

Mar 22, 2017, 10:49:55 AM
   Z-Wave Error                    send "Master Bath Sink Light" status request failed
   Z-Wave                          received "Master Bath Sink Light" status update is off


That is, I'm seeing the error, and then very shortly thereafter the status update comes back.

Now, I do have over 50 devices on my network (not huge, but not small), and I do have a few of them set to poll "As often as possible", and my computer and Series 2 Z-Stick are up on the 3rd floor and I've got devices all the way down to the basement. But I've got a repeater on the first floor and I've used the optimizer a few times. I suspect what I'm really seeing is just that things are slow on my network and Indigo is a bit impatient. Is there a way to tell Indigo extend the time for "status request failed" for polls? Or maybe make polling a bit more asynchronous: Send the poll, don't wait for the ACK, but start a timer in the background such that if it doesn't get a status update in the next minute or two, then signal the error?

Or is there something I can do to make my network a bit more reliable? Is it time to upgrade to the new Z-Stick? Should I move my repeater? Should I line up garlic around the computer?

[matt (support)]

In the case above is it one of the auto poll status requests?

If you have 50 devices I would really recommend against using the "often as possible" poll option. That is going to create a lot of Z-Wave traffic and with 50 devices the likelihood of collisions and failures is pretty high. In the case above the ACK from the status request command to the module is never making it back from the remote module to the Z-Stick. Based on the next message it clearly really did receive the message, but the ACK was dropped for some reason. The Z-Wave network automatically retries on failure, so the fact that the ACK didn't make it means there were probably several attempts but it still failed.

Your suggestion to make the background polling process more tolerant of missed ACKs (in the case where an update comes within a few seconds) is a reasonable idea, albeit not one that is trivially to implement..

The newer Gen5 Z-Stick might help in this case, especially if the destination module and all modules in the route between the Z-Stick and the destination are Z-Wave Plus compatible. If the failures are happening from auto polling of modules, then the most robust solution would be to replace those with modules that don't require constant polling. That would improve the reliability of the entire Z-Wave network.

In the case above is it one of the auto poll status requests?

Yep.

If you have 50 devices I would really recommend against using the "often as possible" poll option.

I've probably got half a dozen devices set that way. Is that too many?

That is going to create a lot of Z-Wave traffic and with 50 devices the likelihood of collisions and failures is pretty high. In the case above the ACK from the status request command to the module is never making it back from the remote module to the Z-Stick. Based on the next message it clearly really did receive the message, but the ACK was dropped for some reason. The Z-Wave network automatically retries on failure, so the fact that the ACK didn't make it means there were probably several attempts but it still failed.

Interesting. I hadn't realized Z-wave automatically retries. In that case, I'd even settle for a simple way to suppress the error message.

Your suggestion to make the background polling process more tolerant of missed ACKs (in the case where an update comes within a few seconds) is a reasonable idea, albeit not one that is trivially to implement..

I hear you. Speaking as someone who used to write interrupt-driven stuff in C and 68000 assembler, I can agree that asynchronous coding ain't for wimps!

The newer Gen5 Z-Stick might help in this case, especially if the destination module and all modules in the route between the Z-Stick and the destination are Z-Wave Plus compatible. If the failures are happening from auto polling of modules, then the most robust solution would be to replace those with modules that don't require constant polling. That would improve the reliability of the entire Z-Wave network.

So most of the modules in question are Leviton switches and dimmers, mostly DZS15-1LZ, DZMX1-1LZ, and a few VRCS2-MRZ dual switches, but also some GE switches and dimmers (12722 and 12724). Are those Z-Wave Plus compatible?

Still considering the garlic.

[matt (support)]

If you have 50 devices I would really recommend against using the "often as possible" poll option.

I've probably got half a dozen devices set that way. Is that too many?

I really don't like the option to poll as often as possible. Even with just a few devices it is going to cause a lot of continuous Z-Wave traffic. If the network is small (10 devices?) and it is imperative that the states stay updated, then it is probably okay.

The newer Gen5 Z-Stick might help in this case, especially if the destination module and all modules in the route between the Z-Stick and the destination are Z-Wave Plus compatible. If the failures are happening from auto polling of modules, then the most robust solution would be to replace those with modules that don't require constant polling. That would improve the reliability of the entire Z-Wave network.

So most of the modules in question are Leviton switches and dimmers, mostly DZS15-1LZ, DZMX1-1LZ, and a few VRCS2-MRZ dual switches, but also some GE switches and dimmers (12722 and 12724). Are those Z-Wave Plus compatible?

Most of those are older and although they will work in a Z-Wave Plus environment, you won't see the reliability and speed improvements in routes that they are relaying commands between.