core
core copied to clipboard
Apple_TV discovery failing
The problem
Expected Behavior:
Home Assistant connects to Apple TV
Actual Behavior:
Home Assistant immediately exits connection loop and declares "No devices found on the network"
Additional Testing:
Can see records which appear to contain the correct information for the desired Apple TV devices in zeroconfServiceBrowser under the following: _companion-link._tcp. _srpl-tls._tcp. Apple Airplay (_airplay._tcp.) Remote Audio Output Protocol (AirTunes) (_raop._tcp.) Sleep Proxy Server (_sleep-proxy._udp.) _meshcop._udp.
Network is flat, all devices and services on a single VLAN, subnet, and prefix
atvremote scan output:
Scan Results
========================================
Name: Home Theater
Model/SW: Apple TV 4K (gen2), tvOS 16.2
Address: 192.168.1.154
MAC: [redacted]
Deep Sleep: False
Identifiers:
- [same as MAC]
- [same as MAC minus ':' separators]
Services:
- Protocol: Companion, Port: 49153, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
- Protocol: AirPlay, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
- Protocol: RAOP, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
Name: Bedroom
Model/SW: Apple TV 4K (gen2), tvOS 16.2
Address: 192.168.1.155
MAC: [redacted]
Deep Sleep: False
Identifiers:
- [same as MAC]
- [same as MAC minus ':' separators]
Services:
- Protocol: Companion, Port: 49159, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
- Protocol: AirPlay, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
- Protocol: RAOP, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
atvremote is able to connect to, pair, and control the devices using the protocols found by the scan
All other Home Assistant integrations tried are working, including other mDNS services
What version of Home Assistant Core has the issue?
2023.1.4
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant Container
Integration causing the issue
Apple TV
Link to integration documentation on our website
https://www.home-assistant.io/integrations/apple_tv
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Logger: frontend.js.latest.202301100
Source: components/system_log/__init__.py:256
First occurred: 2:31:55 PM (3 occurrences)
Last logged: 3:31:25 PM
:0:0 ResizeObserver loop completed with undelivered notifications.
Additional information
No response
Hey there @postlund, mind taking a look at this issue as it has been labeled with an integration (apple_tv
) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of apple_tv
can trigger bot actions by commenting:
-
@home-assistant close
Closes the issue. -
@home-assistant rename Awesome new title
Change the title of the issue. -
@home-assistant reopen
Reopen the issue. -
@home-assistant unassign apple_tv
Removes the current integration label and assignees on the issue, add the integration domain after the command.
(message by CodeOwnersMention)
apple_tv documentation apple_tv source (message by IssueLinks)
Additional Testing Continued:
I was unable to use pyatv within the container to discover any Apple TV devices on the network by broadcast. The same broadcast-based script on the container host running the same version of pyatv was able to find all devices. I was able to use unicast to connect to a known IP using pyatv's manual_connect.py example from within the container, but received a failed authentication. My next task is to understand the HSGID and where it should be retrieved from.
Based on the pyatv examples and the connect routine in __init__.py
, it appears to me that pyatv is broadcasting for a list of devices before trying to connect in most instances, which will occur on the container's network, which is not the host network, unless run on a Linux container host in "host" or "macvlan" networking mode to put the container on the same network as the devices to be managed. On Docker Desktop for Windows, which is where I am running it while I develop the configuration, networking is always performed through NAT unless two containers are on the same bridge network. Host and macvlan based networking only work on Linux.
This means that configuration routines must be entirely unicast to function in a Docker Desktop for Windows installation method.
One possible solution could be to have an optional unicast-only discovery flow with instructions on how to obtain authentication. If there is a way to trigger one that already exists and I am not seeing it, please feel free to say so, but at this time, it appears that the Apple TV component will not work on a container install on a Windows host due to protocol design and pairing method. If I manage to obtain a spare machine to load Linux on and containerize it appropriately there, I will give it another try at that time, but the VM method is even more fraught with problems.
I'm not sure if I experience the exact same issue, but it sure is awfully similar. It's been happening for about a year now and finally had some tome to take a deep dive into this. I'm not as knowledgeable as @cmgrayb seems to be, but here are some of my findings.
Home Assistant Core in Docker, Ubuntu host. Spinned up a completely clean HA container on my Synology NAS, with the exact same behaviour as my live installation on the Ubuntu machine.
atvremote scan
This command finds 2 devices on the network; a MacBook and a Bluesound Powernode media player. It finds neither my Apple TV 3 gen or Apple TV 4k, which are on the same 192.168.1.0/24 subnet.
atvremote --scan-hosts 192.168.1.212,192.168.1.253 scan
When I manually specify the exact (static) IP-addresses of both ATV's, atvremote does find them.
Scan Results
========================================
Name: Woonkamer
Model/SW: Apple TV 4K, tvOS 16.3.2
Address: 192.168.1.212
MAC: [redacted]
Deep Sleep: False
Identifiers:
- [redacted]
- [redacted]
Services:
- Protocol: Companion, Port: 49153, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
- Protocol: AirPlay, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
- Protocol: RAOP, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
Name: Slaapkamer Apple TV
Model/SW: Apple TV 3, ATV SW 8.4.4
Address: 192.168.1.253
MAC: [redacted]
Deep Sleep: False
Identifiers:
- [redacted]
- [redacted]
- [redacted]
Services:
- Protocol: AirPlay, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
- Protocol: DMAP, Port: 3689, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
- Protocol: RAOP, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
However, I'm unable to pair with any of the available options. I believe I've tried every possibility, including manual address, all different protocols, manual ports. All to no avail.
Edit: probably irrelevant and/or obvious, but I'm both able to ping and nmap the AppleTV inside the docker container shell.
bash-5.1# nmap -Pn 192.168.1.212
Starting Nmap 7.92 ( https://nmap.org ) at 2023-03-10 19:37 CET
Nmap scan report for 192.168.1.212
Host is up (0.0010s latency).
Not shown: 994 closed tcp ports (reset)
PORT STATE SERVICE
5000/tcp open upnp
7000/tcp open afs3-fileserver
7100/tcp open font-service
49152/tcp open unknown
49153/tcp open unknown
62078/tcp open iphone-sync
Nmap done: 1 IP address (1 host up) scanned in 72.23 seconds
One potential issue here is that Home Assistant wait for all services that it paired with when adding the device. Looks to me like MRP is no longer amongst the announced services but it most likely did when you added the device. So simplest test: remove and re-add the device and see if that helps?
@grolnn Check AirPlay access settings in your Apple TV and make sure it is set to everyone on the same network.
@postlund I completely removed the integration a while ago. And I thought it would be smart to check this with a completely new Home Assistant installation, so there's nothing to remove and re-add in my case. It's a completely clean intstall with zero integrations just to test this.
AirPlay Access on the ATV is set to Same Network. I've also tried it with the Everyone setting, and tried toggling the Home Hub-setting (not sure what that does though), without success. Still the same behviour. Just to be sure, I've temporarily disabled the firewall on the host machine.
atvremote --id [redacted] --protocol mrp pair
2023-03-10 20:03:07 ERROR [pyatv.scripts.atvremote]: Could not find any Apple TV on current network
I've tried all protocols with the exact same result. It's like atvremote is unable to find the ATV's by ID. It can find them by IP-address, but is unable to pair when specifying the address. Really odd.
I experience something similar to what @cmgrayb is seeing. However, in my installation hass runs in a docker image on a linux host (with network_mode: host). It appears, for some reason, that multicast traffic isn't making it through the docker networking. To resolve this, I run a mdns-repeater between the vlan where the Apple TV is located, and the docker0 interface.
After this, "atvremote scan" detects the Apple TV, listing its IP address. And under "services", the following is reported:
"Protocol: RAOP, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory"
From time to time, the field "MAC" is empty ("MAC: None"), but at times the correct mac address shows up (and then airplay is also reported under "services"). I can also pair with the Apple TV from the command line, no issues. I get a token.
But regardless how I try with the Apple TV integration, I always end up with "No devices found on the network" trying to configure the integration. I also tried the beta version of the integration, but same result. It does seem to me that something is broken here?
Responding to my own post with an update. My issue was related to PEBKAC. Home assistants network component automatic selection of interface for multicast had picked the wrong interface. It was resolved by simply going to Settings-->System-->Network and selecting the right one.
Hmm. How do you know what te right one is? I only have eth0 and lo so I assume it’s the first one. It listed as 172.18.0.4/16 (LAN subnet is 192.168.1.0/24)On 20 Mar 2023, at 11:43, Fredrik Ljunggren @.***> wrote: Responding to my own post with an update. My issue was related to PEBKAC. Home assistants network component automatic selection of interface for multicast had picked the wrong interface. It was resolved by simply going to Settings-->System-->Network and selecting the right one.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
You are likely running your docker container with the bridge network driver (which means docker has set up a L2 network between the host and the container). What I found out was that hass needs to be able to send multicast to your zeroconf-devices (not only receive). So, run your docker with host networking. And if you have several interfaces (like I do), make sure hass is configured to use the right one (facing your zero-conf devices).
@postlund I'm going to close this issue, as it is not a code problem. Perhaps others will run across the issue in the future, so I will leave some final thoughts.
In my case, the problem was an unsupported configuration of Home Assistant itself. Container on Windows just will not work with mDNS-based or true broadcast-based services due to the Docker network capabilities on Windows. I was able to free up a machine, and as soon as I loaded the machine with Debian Bullseye and a Supervised install, the Apple TV integration not only worked, but discovered all of my devices on its own after restoring the original machine's configuration onto the new machine. I would have gone with Home Assistant OS, but the machine is somehow too old for UEFI, yet all of the requirements run fine. For other containerized configurations, please have a look at the comments left by @fredriklj. I believe he is on the right track.
Thank you for your time @postlund, and my apologies for wasting it.