ikcn / retry

Home Assistant Integration with Retry Service

Retry

Smart homes include a network of devices. A case of a failed command can happen due to temporary connectivity issues or invalid device states. The cost of such a failure can be high, especially for background automation. For example, failing to shutdown an irrigation system which should run for 20 minutes can have severe consequences.

The integration increases the automation reliability by implementing 2 custom services - retry.actions and retry.call. retry.actions is the recommended and UI friendly service which should be used. retry.call is the engine behind the scene. It's being called by retry.actions but can also be called directly by advanced users.

retry.actions

Here is a short demo of using retry.actions in the automation rule editor:

retry-actions.mov

retry.actions wraps any service call inside the sequence of actions with retry.call. retry.call calls the original service with a background retry logic on failures. A complex sequence of actions with a nested structure and conditions is supported. The service traverses through the actions and wraps any service call. There is no impact or changes to the rest of the actions. The detailed behavior and the list of optional parameters of retry.call is explained in the section below. All features and parameters of retry.call are also supported by retry.actions, so there is no reason to use the YAML configuration of retry.call. A straightforward UI usage as demonstrated above should be the way to go.

Note: This retry.actions and retry.call are not suitable for the following scenarios:

1. When the order of the actions matters: the background retries are running independently to the rest of the actions.
2. For a relative state change: for example, homeassistant.toggle and fan.increase_speed are relatives operations while light.turn_on is an absolute one. The reason is that a relative service call might change the state and only then a failure occurs. Calling it again might have an unintentional result.
3. If any service call response data is needed: the service calls are running in the background and therefore it's not possible to propagate responses.

retry.call

This service warps an inner service call with background retries on failures. It can be useful to mitigate temporary issues of connectivity or invalid device states.

For example, instead of:

service: homeassistant.turn_on
target:
  entity_id: light.kitchen

The following should be used:

service: retry.call
data:
  service: homeassistant.turn_on
target:
  entity_id: light.kitchen

It's possible to add additional parameters to the data section. The extra parameters will be passed to the inner service call.

The inner service call will get called again if one of the following happens:

1. The inner service call raises an exception.
2. The target entity is unavailable. Note that this is important since HA silently skips unavailable entities (here).

service parameter (mandatory)

The service parameter is the only mandatory parameter. It contains the name of the inner service. It supports templates.

retries parameter (optional)

Controls the amount of retries. The default value is 7. For example:

service: retry.call
data:
  service: homeassistant.turn_on
  retries: 10
target:
  entity_id: light.kitchen

The service implements an exponential backoff mechanism. These are the delay times (in seconds) of the first 7 attempts: [0, 1, 2, 4, 8, 16, 32] (each delay is twice than the previous one). The following are the seconds offsets from the initial call [0, 1, 3, 7, 15, 31, 63]. The retries parameter is not passed to the inner service call.

expected_state parameter (optional)

Validation of the entity's state after the inner service call. For example:

service: retry.call
data:
  service: homeassistant.turn_on
  expected_state: "on"
target:
  entity_id: light.kitchen

If the new state is different than expected, the attempt is considered a failure and the loop of retries continues. The expected_state parameter can be a list, it supports templates, and it's not passed to the inner service call.

validation parameter (optional)

A boolean expression of a special template format with square brackets "[[ ... ]]" instead of curly brackets "{{ ... }}". This is needed to prevent from rendering the expression in advance. entity_id is provided as a variable. For example:

service: retry.call
data:
  service: light.turn_on
  brightness: 70
  validation: "[[ state_attr(entity_id, 'brightness') == 70 ]]"
target:
  entity_id: light.kitchen

The boolean expression is rendered after each call to the inner service. If the value is False, the attempt is considered a failure and the loop of retries continues. The validation parameter is not passed to the inner service call.

state_grace parameter (optional)

Controls the grace period of expected_state and validation (has no impact if both are absent). The default value is 0.2 seconds. There is an additional check at the end of the period if the initial check (right after the service call) fails. The service call attempt is considered a failure only if the 2nd check fails. The state_grace parameter is not passed to the inner service call.

Notes

1. The service does not propagate inner service failures (exceptions) since the retries are done in the background. However, the service logs a warning when the inner function fails (on every attempt). It also logs an error and issue a repair ticket when the maximum amount of retries is reached. Repair tickets can be disabled via the integration's configuration dialog.
2. Service calls support a list of entities either by providing an explicit list or by targeting areas and devices. It's also possible to specify a group entity. The call to the inner service is done individually per entity to isolate failures. Group entities are expanded (recursively.)

Install

HACS is the preferred and easier way to install the component, and can be done by using this My button:

Otherwise, download retry.zip from the latest release, extract and copy the content under custom_components directory.

Home Assistant restart is required once the integration files are copied (either by HACS or manually).

The Retry integration should also be added to the configuration in order to use the new custom service. This can be done via the user interface, by using this My button:

It's also possible to add the integration via configuration.yaml by adding the single line retry:.

Contributions are welcome!

If you want to contribute to this please read the Contribution guidelines

Link to post in Home Assistant's community forum