Hue SSDP discovery about netdisco HOT 4 CLOSED

So this could be caused by the discovery timeout being less than the time given for the device to respond over the MX header. I think it would be just fine to set MX to 1 to see what happens. If the number of devices connected in the network is not huge, I doubt that there's a problem when devices answer simultaneously? In any case, MX should be set to smaller than the generic discovery timeout.

I'll just copy my relevant comment over, based again on @TheMeaningfulEngineer's findings:

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.

I rather not set it to 1. Rather have SSDP_TIMEOUT default to MX+1.

However, @TheMeaningfulEngineer mentioning that he can discover Hue reliable with an 8 second timeout 🤔

from netdisco.

Hey,
regarding what I wrote before.

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).

That unfortunately ended up to be an exception. It happened only for that test can't really diagnose why.
As if the Hue Bridge sometimes doesn't send the responses.

from netdisco.

The devices may have some sort of protection against spammy requesters, so maybe that could explain the situation? Anyway, what I meant with my comment was that if @TheMeaningfulEngineer could test (locally) if setting the MX to 1 helps in his case, we can at least be sure that this is the issue indeed.

from netdisco.