Pyatv: Use of aiozeroconf causes issues in Home Assistant

[jjlawren]

Describe the bug
Having aiozeroconf installed in the same environment as Home Assistant leads to various aiohttp errors on unrelated components: https://github.com/home-assistant/core/issues/37303

To Reproduce
Have the latest apple_tv custom component installed on Home Assistant 0.112.0+.
System Setup (please complete the following information):

• OS: Ubuntu 19.10
• Python: 3.8.3
• pyatv: 0.6.0
• apple_tv custom_component: https://github.com/postlund/hass-atv-beta/tree/d2a081ead8deb82896bb634d03ac5b4a1676262a
  
  
  
  • Apple TV: AppleTV 4
  
  

[bdraco]

from homeassistant.components import zeroconf
zeroconf_instance = await zeroconf.async_get_instance(hass)

If you want to avoid aiozeroconf and can use the sync one, you can get the above to get the main instance that is running in HA.

You'll need the following in your manifest.json

  "after_dependencies": [
    "zeroconf"
  ],

[postlund]

I actually did use the synchronous version before, but switched to aiozeroconf due to bad results. Now I have implemented parts of zeroconf myself to circumvent limitations in the libraries that prevents me from implementing certain features. I will not be able to finish that part any time soon (I.e. not dropping the dependency) and I'm quite hesitant to switch yet another time. So, I'm trying to understand the root cause. It must be something in aiozeroconf, right? Or does it have to do with two libraries trying to act as mdns responders at the same time?

[bdraco]

It is something in aiozeroconf for sure. Both of them should be able to run together just fine (with the performance penalty of running two zeroconf implementations at once -- this can be significant). It looks like aiozeroconf is stomping on open file descriptors somehow.

[bdraco]

Can you provide some more detail on what is broken in zeroconf?

[postlund]

In the beginning of this project I had a lot of trouble reports with users not being able to discover their devices. I was never sure why that was, but switching to aiozeroconf at least made it better for a lot of users (it did not solve it completely though). Why that is, I have no clue. When writing my own implementation I have however seen some patterns. When a device is woken from deep sleep for instance, creates a short period (around 10s or so) when neither the Apple TV not the sleep proxy managing its sleep responds to any requests. So, if scanning happened during that interval it will not be found (and that is agnostic to implementation). There are some other things that's not possible with the generic zeroconf implementations as well (like asking for multiple services in the same request or sending unicast requests).

[pvizeli]

We support now multicast/mdns also inside Hass.io Network which maybe help that the sync version could work fine today?

[postlund]

@pvizeli Unfortunately this was a problem long before you started the Hass.io project, when running in a venv was the default approach. So I don't think it's any better now I'm afraid. Currently I don't even use aiozeroconf for scanning, only when publishing services. So it's somewhat a catch 22 situation here.

[bdraco]

zeroconf has received a lot of fixes lately so the issue users were experiencing may be solved at this point.

aiozeroconf is stale (last commit Nov 14, 2018) at this point so it hasn't had the benefit of these fixes.

[postlund]

Yeah, that aiozeroconf is not maintained is a good point and changing to it was a risk because of that. The synchronous version has always been in a similar situation, but as you say it seems to have gotten a bit of attention lately. This doesn't change the facts that I have my own implementation for the things that worked poorly before, the only thing I rely on externally is publishing services. So the net gain would only be more work since I would have to re-work mocking of zeroconf in the tests again. But since pyatv is not usable in Home Assistant because of this and since I don't feel like fixing aiozeroconf, I guess I don't have much choice 😕

[postlund]

I have finished the migration back to zeroconf in #756, but I do need to test it live first to be sure it works as expected. Hope to be able to do that tonight. This should also conclude the changes I'm making for 0.7.0, just need to update some documentation before I can make the release. But if #756 works, I can hopefully make the release tonight and bump version in the beta component as well.

[bdraco]

Nice work 👍

Please feel free to ping me if you have any trouble fetching the shared zeroconf instance from HomeAssistant

[postlund]

@bdraco I think I got it covered now 👍

The latest updates I pushed uses pyatv 0.70 which reverts back to zeroconf. Perhaps someone can try it out so we can see if this issue is resolved now,

[bdraco]

Thanks. Will check it after dinner

[bdraco]

@postlund

Traceback (most recent call last):
  File "/config/custom_components/apple_tv/config_flow.py", line 266, in async_begin_pairing
    zeroconf_instance = await zeroconf.async_get_instance(hass)
NameError: name 'hass' is not defined

[postlund]

@bdraco Woopsie! Pushed an update for that.

[bdraco]

Discovery is working

[bdraco]

One more traceback

2020-07-15 05:20:49 ERROR (MainThread) [custom_components.apple_tv.config_flow] Unexpected exception
Traceback (most recent call last):
  File "/config/custom_components/apple_tv/config_flow.py", line 267, in async_begin_pairing
    self.pairing = await pair(
  File "/usr/local/lib/python3.8/site-packages/pyatv/__init__.py", line 103, in pair
    return handler(config, await net.create_session(session), loop, **kwargs)
TypeError: __init__() got an unexpected keyword argument 'zeroconf'

[postlund]

Oh, that is a bug in pyatv. I will look into that.

[postlund]

A fix has been pushed!

[bdraco]

Confirmed fixed

[postlund]

Great, thanks for verifying! Closing this now.