Issue:
I have many Shelly switches to control lightning, appliances etc. Some of them are in areas where WIFI is not that good and they are unavailable sometimes. This is a issue, because when automation tries to for example turn off the lights and it’s unavailable, nothing happens and automation ends.
I have mitigated this for some of my automations like pool heating, because it’s crucial to turn it off when electricity price is too high. For that i use wait_template like this:
This works nicely, but for example if I want to to automation where I want to switch on/off all my outdoor lights (total 5 entities) it become’s quite complex. I cant have one sequence entry to switch them all but have wait_tepmplate + turn on for each of them. And as it’s sequence, processes don’t run in parallel. Do have five automations is even less efficient.
My ask
Would be nice if there would be a option "try until entity becomes abailable) in automation. Maybe here:
This have been suggested soo many times and a search should have brought up several threads with explanation on how to do it in the current setup and the limitations on doing it as a builtin feature.
As you can see, there are several existing Feature Requests along the same lines requesting some form of “retry”. So far, none have been fulfilled.
Here’s what I currently suggest as a means of performing an action more than once, but no more than a certain number of times before conceding failure (to avoid trying indefinitely). The example uses a simple repeat - until to turn off a switch. It gives up after 5 attempts.
Here’s a slightly more sophisticated version that is more responsive than the linked example, because it uses a wait_for_trigger, instead of a fixed delay, for each iteration of the repeat. It tries to lock the door lock but no more than twice.
FWIW, I use this method for just one device in my home. Just like in the example, it’s a door lock and when its batteries are weak it takes more than one attempt to lock the door.
The lock isn’t able to report its battery level. However, when it takes more than one try to lock it, my version of the example also notifies me that the batteries may be weak because it took two attempts to lock the door.
Without specifying a value for timeout, that example will wait forever (when the light is unavailable). In other words, there’ll be an instance of the automation that remains in-progress indefinitely, waiting until the light is no longer unavailable (or until Home Assistant is restarted and purges all in-progress automations and scripts).
When using wait_template and wait_for_trigger, it’s important to use timeout. It can be made even more robust by checking the wait variable’s state afterwards. It reports if the entity’s desired state-change occurred or if it timed out. Based on its value, a decision can be made about what to do next.
BTW, the default value for continue_on_timeout is true so it’s unnecessary to specify it twenty times in your automation.
There’s sufficient repetition in your automation to merit the use a script to control a light (pass the light’s entity_id as a variable). A script can be run in parallel mode. Just be sure to call it with the script.turn_on service call.
