IGD review fixes

[StevenLooman]

Description:

Changes after review by @balloob

Related issue (if applicable): fixes #16300

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass

If the code does not interact with devices:

• Tests have been added to verify that the new code works.

[balloob]

I'm actually thinking, why is it that we need both http and discovery to begin with?

[StevenLooman]

discovery is required as the device is detected via upnp/M-SEARCH.
http is required to determine the port home assistant is listening on (really only used the port mapping is enabled.)

[balloob]

But that is not needed for running this component, the SSDP response is stored in the config entry.

I think that we should remove both http and discovery, because marking it as dependencies means that we're setting it up.

If port mapping is enabled but http is not enabled: don't setup port mapping.
Not requiring discovery: nothing breaks?.

[StevenLooman]

If we get a SSDP response discovery is enabled already. The original component already (only) worked with discovery, but used its own library for it. Now the component is using more existing libraries, such as netdisco and async_upnp_client (used also by the dlna_dmr-component).

The 'externals' (config, workings from the perspective of the user, etc) are mostly kept the same compared to the original upnp component. Thus, depending on the http component for getting the hass-port for port mapping. discovery is required as the user has (as before) no way to manually enter a SSDP description URL. Learned from the dlna_dmr component, finding this URL is hard for the average user and discovery is preferable.

I get your point and I'm fine with not requiring these, but then there should be:

• a message in the logs clearly stating that discovery is required otherwise it will not work (as before)
• a message in the docs clearly stating that discovery is required otherwise it will not work

[balloob]

Philips Hue will, during their config flow, do their own discovery to find the device. The upnp component should do the same.

[StevenLooman]

That what is the purpose of netdisco/discovery if every component has to do its own discovery? This feels like unnecessary duplication of functionality, and hence, more suspect to bugs.

[balloob]

It serves as purpose to find config entries. However, manual config entries will have to rely on their own scanning logic.

[balloob]

btw I notice that you're calling get_local_ip inside an async context in upnp/device.py. That call does I/O.

[StevenLooman]

btw I notice that you're calling get_local_ip inside an async context in upnp/device.py. That call does I/O.

Creating port mappings does I/O as well. Where do you suggest to do it?

[balloob]

Outside the event loop. No I/O allowed inside it.

ip = await hass.async_add_executor_job(get_local_ip)

[balloob]

We should not depend on discovery.

[StevenLooman]

Work has been slow, but will pick this up soon.

[balloob]

It's already ok, will merge it. I removed the discovery dependency.