More aggressive retries in the event of an error.

It would be nice if when an error occurred, indigo would call for a status check and retry the command if necessary. An example would be calling for a light to turn on, but getting a no response error. Sometimes communication is interrupt or corrupted. Even with Insteon’s dual communication mode sometimes the command just doesn’t make it there or get the response back.

[jay (support)]

Note that both Insteon and Z-Wave have built-in retries at the protocol level. So if a failure ends in a no ack error, it's already performed retries. We find that in this situation, and most specifically in the Insteon case, attempting even more retries will usually make things worse rather than better since the primary issue with Insteon is signal collisions (which it doesn't handle very well). Z-Wave handles it better, but if it retries a different route that requires extra jumps it can also significantly slow down messages as well.

There isn't really a good one-size-fits-all approach to no acks - you have to try to characterize what's causing them and then mitigate specific things that might be causing them.

If I have a problematic Insteon switch, I usually have indigo send the command twice and it works. For my z-wave units, if it fails once, sending an extra command does no good; in that case the only fix seems to be to move the switch closer to the server or swap it out with an Insteon equivalent. Finding what causes interference is such a pain. I have four Insteon switches that work at my main gate some 600’ away, and then have a switch that will be flaky two rooms away. I have figured out that in all cases, dimmers are the most problematic with either z-wave or Insteon.