Understood. In which case my original WTH still stands. HA knows that one of its integrations/libraries has failed to achieve something it tried to do, this shouldn’t be a silent event, as it is likely to have frustrated the user - or should is say “WHAT THE HECK!?”.
2 Likes
Adding one analogy;
- you use tv remote and click power button to turn on or off the tv
- remote is somehow not pointing on tv so tv did not receive the command and nothing happened
- it is up to user to retry based on output/response
There might be some service calls, which is not updating the internal HA state, so it is very tricky from HA perspective to decide. Maybe, we can just make an automation action parameter or service call parameter, as retry condition (in which condition to retry), retry timeout and retry count.
While I understand your analogy in the context of Home Assistant vs libraries, I don’t want that to be a reason to not implement a change in one or the other. As a hobbyist, it sounds like an interesting challenge - does HA enforce a new standard on devs?
As a user, I agree with HarvsG. The ideal state for many users is to never have to use a “remote” again, instead automating their lives through triggers. When I walk into a room, I expect the light to turn on without my intervention (handled via motion sensor, presence detection, or other trigger). I expect things to work and don’t care if it took 1 or 100 API calls to get it done, that’s all behind the scenes. If I have to “use” anything, then I might as well have used my light switch and throw Home Assistant out the window.
Point is, as a user, it doesn’t matter to me if it’s not technically Home Assistant’s responsibility or the library dev. Home Assistant gets the axe and my Nabu Casa subscription gets cancelled.
1 Like
Nobody said that… 
Agree 100%, nobody ever said otherwise. Not sure what it triggered, nobody said anything about this.
Sorry to hear that, nevertheless good luck on your future journeys! 
…/Frenck
3 Likes
I don’t think SteveHome meant this in an accusatory tone I think he was just trying to highlight that there is a difference in a dev vs a user perception of (this/any) problem and playing the devil’s advocate in doing so! Probably in response to
“That is a library implementation, which is considered out of scope for HA. Such retries do not take place in HA, but in a level UP.”
I don’t think it was an actual threat to cancel his subscription.
Oh the joys of written forms of communication on the internet… /s
1 Like
It doesn’t add value in discussions. In the end, I’m personally fine with that. One should use something one like. If something else fits better, that is completely fine and up to them.
In the end, everybody tries their best to find common grounds and solutions, trying to make HA better every day… together.
4 Likes
Great point on discussing technical matters, I am not part of nabu casa or home assistant dev team but this statement has zero contribution, other than sound threatening
Yeah HarvsG you got the tone, sorry Frenck! I thought Frenck saying “out of scope for HA” meant “we can’t/aren’t going to do anything about it” - which wasn’t the case (?)
The feeling I was trying to express in response to this was that others might quit HA if nothing is done, so HA needs to do something. That’s all. Not going anywhere, you guys are awesome! 
Well my bad, I really wasn’t trying to threaten…I was just trying to encourage the HA team to deal with this issue rather than declare out of scope and leave it to the integration devs that haven’t implemented it yet (or this wouldn’t be a WTH…)
The cancellation statement was simply to say that casual users don’t/shouldn’t have to differentiate between HA and integration devs’ responsibilities. They pay HA. So if devs don’t make things work and people give up, HA doesn’t get paid. Therefore it’s HA’s problem.
Not a threat. Not implying HA is greedy or devs are lazy. None of that. Simply trying to say that it should be within scope of HA or HA requirements to devs if devs haven’t implemented this yet. That’s all.
1 Like
I’m working on this now because stuff not turning on and hacking automations with retry loops is time consuming. Unfortunately not all integrations retry and many don’t even return errors if the destination device is offline…or the command gets lost due to RF (zwave :-()
Anyways, I have a very early implementation that I’ve been using, it’s based on using shell scripts to autogenerate the retry stubs for entity service calls as scripts. Once we get the nuances mastered we’ll create a python integration. But for now, scripts are quick and easy to work with. RIght now it has a very limited set of methods; but extensible.
Looking for power users who can work on this with me and/or do some evaluation to see how it works in your world. Right now you’ll need some shell scripting capability to use it.
It auto-generates a lovelace dashboard so you can see the metrics:
And look at overall execution times:
2 Likes
We created a service which wraps another service with retry mechanism - GitHub - amitfin/retry: Home Assistant Integration with Retry Service
It can be installed via HACS by using this link.
While developing it, the most surprising thing was the fact that when an entity is marked unavailable (e.g. temporary connectivity issues) it’s being silently skipped by HA (in this code.) Therefore, the retry mechanism verifies the availability of the entities explicitly (and not only errors).
5 Likes
Any idea if this is on the horizon?
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.
1 Like
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.
1 Like
Hi all, I’ve added a feature request that is about a similar functionality: