External integration - Apple TV

Development
21

Thanks for the analysis :slight_smile:

In that case, the external integration shouldn’t work even when they are on the same network?
Unless when you are on the same network it sends unicast requests and the explanation could hold up

22

@valentinhttr

It’s strange that during the second scan, one fewer device is found when I unplug my Apple TV

[2026-08-16T18:35:13.529Z] [INFO] [apple-tv] Gladys captured 5 AirPlay announcement(s)
[2026-08-16T18:35:13.529Z] [INFO] [apple-tv] Verifying 5 candidate address(es) with pyatv
[2026-08-16T18:35:21.531Z] [INFO] [apple-tv] Found 0 Apple TV(s)
[2026-08-16T18:35:55.134Z] [INFO] [apple-tv] Scan requested
[2026-08-16T18:36:03.139Z] [INFO] [apple-tv] Gladys captured 4 AirPlay announcement(s)
[2026-08-16T18:36:03.139Z] [INFO] [apple-tv] Verifying 4 candidate address(es) with pyatv
[2026-08-16T18:36:11.141Z] [INFO] [apple-tv] Found 0 Apple TV(s)

Is there a way to have a debug mode to see which device it sees and potentially find out why it doesn’t add them to the discovery? :wink:

23

Thanks, this test is very useful: the transition from 5 to 4 after unplugging the Apple TV confirms that Gladys sees its AirPlay announcement and retrieves its IP (at least I think so). The issue then occurs when pyatv attempts to complete the information with a direct mDNS request, which is ignored between subnets.

Version `1.1.0` of the integration is currently being built; it now details the name, host, IP, and port of each announcement/candidate in the logs. This will clearly confirm which address corresponds to the Apple TV, even if the network fix remains necessary to retrieve the other required services.

24

Thank you :slight_smile:

Here is the result:

[2026-08-17T18:15:52.654Z] [INFO] [apple-tv] AirPlay announcement 3/5: {"name":"Chambre._airplay._tcp.local","host":"Chambre.local","addresses":["fe80::7:3db5:2499:xxx","fdfd:9ce7:d5fe:4961:c02:da41:da37:xxxx","192.168.xx.10","fdfd:9ce7:d5fe:4961:6:fda9:17a6:xxxx"],"ipv4":["192.168.xx.10"],"port":7000}

[2026-08-17T18:15:52.655Z] [INFO] [apple-tv] Candidate address 3/5: {"address":"192.168.xx.10","sources":["AirPlay announcement","manual configuration"]}

[2026-08-17T18:15:52.655Z] [INFO] [apple-tv] Verifying 5 candidate address(es) with pyatv
[2026-08-17T18:16:00.657Z] [WARN] [apple-tv] No candidate answered pyatv's direct mDNS query: 192.168.xx.12, 192.168.xx.9, 192.168.xx.10, 192.168.xx.7, 192.168.xx.8. On routed networks or separate VLANs, Apple devices normally ignore direct mDNS queries whose source is outside their local subnet.
[2026-08-17T18:16:00.658Z] [INFO] [apple-tv] Found 0 Apple TV(s)

Strange that we only see Chambre._airplay._tcp.local
And not Chambre._companion-link._tcp

25

Thanks for the feedback, the logs confirm the diagnosis: Gladys receives the AirPlay announcement and the correct IP, but the direct pyatv check gets no response between the VLANs.

The absence of _companion-link._tcp is currently normal: only _airplay._tcp is declared, and Gladys so far only scans the first mDNS service of an integration.

@pierre-gilles I proposed a fix on the Gladys side: PR #2951 that allows retrieving and merging all declared mDNS services.

@prohand In principle, if this change is integrated into Gladys, we can plan a new version of the Apple TV integration that will directly use these announcements instead of making another mDNS request from its container. The 1.1.0 improves the diagnosis, but inter-VLAN support will require this next version.

26

Perfect, thank you :slight_smile:

27

Thanks, I’ve added my feedback :slight_smile:

28

Thanks, I ran Claude on it :+1: