Failed to find device with identifier

[Veldkornet]

Describe the bug After initially setting up the AppleTV in HomeAssistant 0.102.2 in Hass.io, you restart HomeAssistant, and the AppleTV no longer works. 2019-11-27 22:57:08 ERROR (MainThread) [custom_components.apple_tv] Failed to find device with identifier xxxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx The only way to make it work again is to remove the AppleTv and re-add it again.

To Reproduce

• Configure the AppleTv integration
• Restart HomeAssistant

Expected behavior

System Setup (please complete the following information):

• Os: Hass.io
• Python: 3.7
• pyatv: 5d20516

Additional context

[jayfbeast]

I'm not sure to be honest, it just happens at seemingless random times. Usually zeroconf stops working at all, at least for atvremote. I have seen this behavior several times when I have Home Assistant running with my component connected to ATV. When running atvremote on the same machine usually return zero result. My best guess is that it has to do with port re-using (since you have to specify that a UDP can be re-used when binding to it), but I haven't investigated that further. It's also hard to tell if it's the same issue.

hmm hmm... how often the port usage check is made? I mean, when the port is being re-used, atvremote isn't aware of that change and everything stop working at that point?

Also, I've been running your component for a few hours only and so far, it is working flawlessly. After how much time you end up having issues? a few days? weeks?

[postlund]

With mDNS/Zeroconf, the request is multicasted out on the network to a specific address (224.0.0.251). All clients must listen on port 5353 UDP on this address. When a request is received a response is sent back to the requester at the same port, 5353. If an application already listens on this port you can't bind to it, that wouldn't normally make sense. Since UDP is datagram based and has no retransmissions, segmentation or other complex mechanisms, it works two have several listeners anyways and that they receive the same data. But you have to say that you want to reuse a port when binding to it. So you only do it initially.

Last time I saw it it happened instantly, more or less. I started Home Assistant and shortly thereafter I tried atvremote in another shell and it didn't find any hosts.

[jayfbeast]

So chances are the solution might reside somewhere else in mDNS/Zeronconf? I mean, you won't be able to take care of that issue from within pyatv or atvremote ?

[postlund]

Yes, I see that as an inherent risk. But that doesn't mean it's not solvable, we just have to make a PR somewhere else or point to some issue stating where it's potentially fixed. If it's a bug in python for instance, then it's not much more we can do then require a specific version of python in case it's fixed.

[postlund]

I'm trying to create a workaround for the scanning issues, please have a look at #343.

[postlund]

I have managed to complete #343 and integrate it with the component, but I need to do some clean up and additional testing of it. To summarize how it works:

• Unicast scanning (as implemented in #343) will be used when entering an IP-address in the add-dialog in Integrations. This means that if you enter an IP-address when adding a new device, pyatv will scan for that device only by sending a request directly to the device. This should work even when normal scans doesn't work. Entering an identifier or name will trigger a scan just like before in order to find the device.
• IP-address of the device will be saved in the config entry. So the configuration in .storage/core.config_entries will contain the last known-to-be-working IP-address.
• When starting Home Assistant, a unicast scan will be performed on the saved address. This will greatly speed up initial connection, assuming the device has not changed IP-address.
• If the device has changed IP-address (compared to what is stored in the config entry), a scan will be performed. If the scan finds the device, a connection will be established and IP-address updated in the config entry, so it is up-to-date when connecting the next time.
• If scan fails, unicast scan + regular scan will be retried again after a while.
• The error message in the title of this issue has been removed. You will have to look at the device state/title to see what is happening (or enable debug logs). The reason for this is to not spam the log with retry-attempts in case the device isn't found (e.g. because of issues or it being turned off). My intention is for this integration to reach Plantinum level on the quality scale in due time, so this is necessary.

This should work good for all users. My assumption is that scanning works sometimes, even for users that have problems. This approach hopefully makes the connection recover at some point in time. If it doesn't, then the integration must be removed and added again for now. I will have to look at an approach to edit IP-address manually in the future.

My intention is to release an update to the component today/tonight. I would be extremely happy to get some testers on this, especially if you have said problems.

This will be a breaking change: you must remove and re-add your integration when updating!

[postlund]

Updated version of the component is out now!

[aidanblack]

Do you have an updated version of the beta add-on? If so, could you post a link?

[postlund]

Latest commit in https://github.com/postlund/hass-atv-beta is always latest "version".

[aidanblack]

Thank you!

[nikolaykasyanov]

@postlund seems to be working great, thank you!

[postlund]

@nikolaykasyanov Great, thanks for trying! 👍 Did you by any chance test unicast scanning, I.e. adding device by specifying IP-address?

[nikolaykasyanov]

@postlund yes, I'm adding the device via IP and it survives HASS restarts.

[postlund]

@nikolaykasyanov Perfect, thanks again! 👍 Seems to be a problem lurking somewhere, as seen in #363, so it is good so see that it works for at least someone else.

[postlund]

Problem is partially solve via unicast scanning (entering IP-address). A foolproof solution is something we probably won's see near time. But I hope this is good enough.