Consider upping the range and default for the `response` timeout

[AlCalzone]

Some 500 series controller seem to take a long time before sending this response (although the correct behavior would be responding immediately and waiting before the callback).

[apella12]

FWIW I believe the openhab Zwave binding has a 2 second timeout.

[AlCalzone]

What does it do if that elapses? I've seen quite a few logs from users where the Serial API response can take upwards of 10 seconds. This shouldn't happen, but it does.

[apella12]

Basically any timeout cancels the command and tries again up to 3 times, then it is aborted. There is also a 250 ms holdoff after cancellation for a Wait Response timeout. I don't have that deep of knowledge here, but I can't recall seeing this (a Wait Response timeout) very often. I also have never understood as to when the controller decides reject a message rather than wait to accept it.

Far more common are the 5 seconds time outs on a Send Data command during the Wait Request or Wait Data phase if the network is swamped with excess reporting or controller routing attempts. The last is most common when a sleeping device is already asleep before the go to sleep message is acked. With a sleeping node send data messages are not resent

[AlCalzone]

Thinking about this again, I don't see much benefit in keeping this timeout short. For the affected 500 series controllers that would cause communication aborts, and worst case (if we go out of sync and soft-reset is disabled) a driver restart. In all cases I've seen so far, the response does come after 15-20 seconds. And when this timeout isn't relevant, the wait time is very short usually (<100 ms).