core: 819LMB: Devices become unavailable intermittently and then permanently until reboot

The problem

I have a Liftmaster 819LMB MyQ Home Bridge integrated with Home Assistant, along with two garage doors that are also paired.

Everything works perfectly when Home Assistant first starts up (such as immediately after a reboot), although there are intermittent disconnections. Then, after a period of time, usually several hours later (I think I’ve seen up to 12 hours before), the bridge and paired entities become completely unavailable without another restart of Home Assistant.

Here’s an example from today: Screenshot 2022-10-18 210925

It had gone unavailable, and after a reboot, it stayed available for several hours with intermittent disconnects before becoming unavailable again.

There are no accompanying log messages, although I did add information about reloading the integration below.

What version of Home Assistant Core has the issue?

core-2022.10.4

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

HomeKit Controller

Link to integration documentation on our website

https://www.home-assistant.io/integrations/homekit_controller/

Diagnostics information

homekit_controller-3b1f1c38512aad5bc75f0bdad8a923dc-MyQ-0B6-673f2ab1d2254696445baa746c8353fd.json.txt

Example YAML snippet

No response

Anything in the logs that might be useful for us?

Although there are no log messages when there are disconnections, going to Settings > Devices & Services > HomeKit Controller > <Hub> > Reload does produce the following error:

Retrying setup: Timeout while waiting for connection to device 0.0.0.0:80

Additional information

I checked the config/.storage/core.config_entries file after seeing the error message above, and the IP address for the bridge was set correctly. After trying to reload the integration once, it will periodically continue to reload with the same error.

Disabling and re-enabling the HomeKit controller integration for the bridge has the same result, producing the timeout error message from above.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 18 (9 by maintainers)

Commits related to this issue

Most upvoted comments

We’ve got a bunch of zeroconf fixes going into the next release. These include coping with link local addresses better, better behaviour at startup and a bug where ip changes weren’t noticed.

These will fix at least a couple of issues in this thread, but if you still have troubles in 2022.11 please raise fresh issues. We’ve ended up tracking separate bugs under the same issue, which is why the fixes that have landed auto-closed the issue.

Interesting. I have an Aqara hub (an e1) and don’t have any problems. There were a couple of releases where I did have the same version you describe but it was fixed. Since then it’s been stable.

Although mine is a different hub, I know from supporting Aqara users that they do have a similar defining feature (so likely similar software). They actually restart their HomeKit stack at least once a day, and that means the TCP port it uses changes to another random one.

Given you see this behaviour for multiple products and I see multiple products working just fine we are probably looking at environmental factors.

Recovering from the state I just described for Aqara relies on your network having working mdns. A frequent problem for users even using the official apple apps is that aggressive performance features in consumer networking gear breaks or partially breaks multicast (especially over wifi). WiFi repeaters can do this and as mdns is UDP poor wifi signals can be a factor too. That is probably where I’d want to start digging. I’m away from my desk for a few hours, unfortunately.

Do they all break at the same time?