Home Assistant
Exponential backoff for Add-On watchdog #743
Replies: 2 comments 3 replies
-
|
I just had this issue myself (not enough restart tries when I'm updating my router and have a little network downtime). I did some research on how I can fix this, I found this https://www.zigbee2mqtt.io/guide/installation/15_watchdog.html Now I can not say for sure that this fixes it, I don't want to take my network offline to try, but I believe this should be what I want? |
Beta Was this translation helpful? Give feedback.
-
|
This might help but it's specific to Zigbee2Mqtt, and even then it looks like it's only going to result in a fixed number of retry attempts. This should be addressed in HA so that it resolves similar issues with all add-ons. I've had the same happen with OpenThread Border Router, for example. It's a potential reliability issue with any add-on and I'd argue that giving up forever is never the right thing to do (unless you're 100% sure that the problem won't resolve itself, which HA doesn't know). For now I've set up an automation that starts all of my important add-ons every 10 minutes, just in case. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I fully agree with you and would hope for a proper fix within Home Assistant itself. |
Beta Was this translation helpful? Give feedback.
-
|
Home Assistant allows you to control add-ons using switches and others, so you can write automations that will keep your add-on running. You don't have to use the built-in watchdog. I doubt such a change will be added to the core, because each application may actually require a different retry policy. |
Beta Was this translation helpful? Give feedback.
-
|
I've tried going down this route but checking whether the add-on is running is hard and non-intuitive - you need to manually enable "Running" entity for each add-on and keep track of relationship between the add-on ID and its "Running" entity ID. It's doable but overly cumbersome. I think it would be wise to do something here to improve reliability, things like this can needlessly sour people on using Home Assistant and give it the reputation that it's only usable for very technical users. It's true that different application might require a different retry policies but it should be user-configurable with sane defaults chosen by the add-on author, something along the lines of: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe the feature
I would like the incremental backoff concept to be applied to the Add-On watchguard. So instead of trying to start an Add-On only a couple of times, then stop when it keeps failing, it should be retried forever, extending the retry-delay each time (or maybe starting this logic after trying regularly for X times).
Use cases
We use HA at our company with an SLZB-06 over TCP with PoE. We did some work on our Network Infrastructure, which included disrupting the connection from HA to the device. Z2M noticed the dropped connection, and the Add-On was restarted 10 times, but eventually failed and ended up in the stopped state.
If the watchdog would have retried for longer, our Zigbee Network wouldn't have been down, preventing some of our automations from running.
Here's what happened from Z2Ms perspective. At 12:17:30 I started the Add-On manually, because I noticed it being stopped.
Current workarounds
For now I have set up an automation which monitors the state of the Add-On and sends a notification so I can take care of this manually.
Anything else?
No response
Beta Was this translation helpful? Give feedback.
All reactions