Hi @amitfin,
retry.call sounds like exactly what I’m looking for.
I was using a retry loop in the automation, but failed services calls were causing the automation to abort anyway…
I’ve installed via HACS, but HA doesn’t recognise the retry.call service:
Any tips?
Yep, totally missed that. 
Thanks for pointing out the obvious!
I wonder if this concept should be revisited in light of the upcoming changes in 2023.7 - services can now respond. So many of frenk’s concerns about retrying without knowing what the device has done may well be allayed.
There would be a few ways to do this which I think would be an architecture decision. i.e retry on no response, or service responses which recommend retries etc etc.
Service response is indeed not playing nicely with background retries. I’m open for suggestions 
To be explicit for people who are reading this thread: nothing is broken with GitHub - amitfin/retry: Home Assistant Integration with Retry Service even with 2023.7.
BTW, we might want to wait a while and learn more on the popular use cases involving service responses. It might help with making the right tradeoffs.
A UI friendly service was added to the retry integration. No need to use YAML anymore.
Additional details can be found here.
I’m using a Honeywell T9 thermostat that I’ve blocked from the internet but is still accessible on my LAN. Occasionally a request to set the temperature would fail with a timeout error. Your retry service totally resolved my issue.
Hi all, I’ve added a feature request that is about a similar functionality:
