Command Retry is a new hub feature that can increase the reliability of device actuations.
It works by capturing the commands sent to specific devices and resending them up to 5 times if the device doesn't produce the expected event.
Initial retry intervals vary by the device type:
switches and thermostats: 1,500ms
dimmers: 5,500ms + fadeTime if included in the command
shades: 60,000ms
locks: 5,000ms
A backoff strategy is also implemented such that each subsequent retry is delayed by an additional (currentRetryNumber * initialRetry interval), except in the case of locks where a retry interval of 10,000ms is used
This feature isn't designed to fix bad mesh issues but can have a positive effect on device reliability in many cases.
It can be more effective than metering since it works with specific devices that haven't responded, where metering simply adds configurable delays between the commands sent to multiple devices.
Command retry supports the following device types and commands:
-switches: on and off
-dimmers: on, off and setLevel
-blinds and shades: setPosition, open and close
-thermostats: temperatureSetpoint, heatingSetpoint, coolingSetpoint and setThermostatMode
-locks: lock and unlock
Command retry is available for any Z-Wave, Zigbee or Matter device that falls into the above categories and is directly joined to the hub (not via a third party bridge).
Command Retry is disabled by default but can be enabled/disabled via each devices preference settings or the Command Retry page located within the hub settings page.
Meshed devices on the destination hub are excluded, one should enable command retry on the source hub if desired.
Zigbee group messaging commands aren't compatible with commandRetry, enabling command retry on devices that are part of a Zigbee group won't have any detrimental effect, but the group message will not be retried.
Command retry compatible devices that control garage doors or gates should be tested independently as some implementations may cause unexpected results.
When command retry is enabled for a device, and that device doesn't respond to the initial command sent, a message is sent to the live logs under the devices behalf indicating the retry count that succeeded or if it failed altogether after trying 5 times.
Observationally usually the device will respond on the first or second retry, if a specific device fails consistently this could indicate a mesh and or device specific issue.
