Discovery cycle is too long about netdisco HOT 12 CLOSED

I agree, we should be able to lower this. I think 5 seconds became the default after it was initially chosen arbitrarily.

from netdisco.

I think the proper way would be to leave the listening sockets open in a background thread (at least for HA's usecase) and emit changes to HA, completely avoiding blocking polls. At least the used zeroconf library would allow that, but it would require some refactoring of the code. What do you think?

from netdisco.

I wouldn't want it to be always running. Devices being added to the network is an exception and we should not constantly be scanning for them.

from netdisco.

but it would require some refactoring of the code.

I'd say that would requite a lot of refactoring. Who'd do that? There're real issues to work on HA instead (as an example, I (a random novice user) submitted ~5 bugreports on my first 2 days with HA).

I propose a low-effort way to increase (HA) user satisfaction instead.

from netdisco.

Update:

By decreasing default timeout to 2s, I decreased HA's autodiscovery delay from whooping 30s ("HA is slow!!11") to 15s (majority of which were spent in web UI autoreconnect anyway, so it was like 5s after web UI restart). I'll prepare a patch soon.

from netdisco.

Why are the 5 blocking calls (in your example) running sequentially to take 25 seconds? I distinctly remember that one of my first patches to netdisco was to parallelize blocking detection, so the entire detection phase would not take longer than the longest blocking call. In your example, it would be 5 seconds.

This solution seems much better than to decrease the reply time available, which will increase the risk that slow devices (with a wakeup time) might miss it.

If the detection is no longer multithreaded, this seems like a regression and should be fixed as such.

from netdisco.

I distinctly remember that one of my first patches to netdisco was to parallelize blocking detection

You can see for yourself: https://github.com/home-assistant/netdisco/blob/master/netdisco/discovery.py#L56

This solution seems much better than to decrease the reply time available, which will increase the risk that slow devices (with a wakeup time) might miss it.

This was addressed in the original proposal: "Even better, set default as 2s, and let the caller specify max duration to be used for each individual service. Then, a small value (e.g. 0.5s) can be used on first call to quickly pick up majority of devices after startup, and later, larger durations can be used for slowpoke devices."

If the detection is no longer multithreaded, this seems like a regression and should be fixed as such.

My personal opinion to a similar comment I already shared in #142 (comment)

from netdisco.

If I recall correctly we got rid of the multithreaded approach because users were reporting issues that things were crashing.

from netdisco.

Hey,
it seems that this issue has been been addressed by the PR.

https://github.com/home-assistant/netdisco/blob/master/netdisco/ssdp.py#L13
I've experienced that for Philips Hue Bridge you should wait for a response at least 5 seconds (I ended up using 8 to get a 100% discovery rate for 30 tries).

I'm using netdisco outside of Home assistant.
Just my ten cents, not arguing for it being the best approach or default value. :)

from netdisco.

An update on this.
My issue was more related to this line:
https://github.com/home-assistant/netdisco/blob/master/netdisco/ssdp.py#L16

If SSDP_MX is the same as DISCOVER_TIMEOUT won't it by default miss the
responses when random waiting time of the responses ends up being max?

from netdisco.

Sounds like it indeed, assuming the devices really follow the UPnP spec's SHOULD:

REQUIRED. Field value contains maximum wait time in seconds. MUST be greater than or equal to 1 and SHOULD be less than 5 inclusive. Device responses SHOULD be delayed a random duration between 0 and this many seconds to balance load for the control point when it processes responses. This value MAY be increased if a large number of devices are expected to respond. The MX field value SHOULD NOT be increased to accommodate network characteristics such as latency or propagation delay (for more details, see the explanation below). Specified by UPnP vendor. Integer.

from netdisco.

Going to close this issue as it has indeed been addressed by a PR. Let's move discussion to a new issue. Getting a 100% success rate on Hue is interesting, as right now it's very flaky.

from netdisco.