LAN Driver Search Parameters

I have seen a search-parameters.y*ml file popping up in the ST version of LAN drivers. I don’t see it documented, but it looks like there may now be some platform support for discovery. Is this true? Does it also now handle conflicting drivers searching for the same devices? If this enables platform discovery, how do drivers register for events?

Sonos:

ssdp:
  - searchTerm: "urn:smartspeaker-audio:service:SpeakerGroup:1"

Hue:

mdns:
  - service: "_hue._tcp"

Bose:

ssdp:
  - searchTerm: urn:schemas-upnp-org:device:MediaRenderer:1

Wemo:

ssdp:
  - searchTerm: urn:Belkin:device:*

Samsung:

ssdp:
  - searchTerm: urn:samsung.com:device:RemoteControlReceiver:1

The search parameter files have been added over the last couple of weeks but seem to be completely independent of the source of the drivers at the moment. I was wondering if they might be intended to control the automatic installation of the drivers, as having a shed load of drivers pre-installed is an obvious nonsense.

1 Like

I’m thinking it may be similar to the fingerprints but for LAN devices. One issue I had with Hue was that a user could install my driver, but scanning would produce devices for the ST version of the driver as well. I ended up re-writing my driver to get around it. I reported that issue to the ST team. Maybe this is their solution?

Hi @blueyetisoftware let me ask it the team :saluting_face:

1 Like

@nayelyz can I resuscitate this thread and see if there is an answer? Is the search params file just a hint we can give ST to help it be more efficient? Does it provide any value to the drivers themselves? Is there some sort of callback that is hit if the hub finds a match?

Thanks

That’s how I came to understand it.

Thanks for the link. It does say we will get a “discovery start” if they find something, but it sounds passive. I’m guessing the driver still needs to keep the implementation for active searching.

It also says the driver needs to be running to receive the event, so I’m not sure how this helps with initial discovery.

My understanding is that it makes not a jot of difference to your driver’s discovery code.

It just prevents your driver being woken up to do a discovery when there is absolutely nothing to be found.

1 Like

I think that is the case as well. Even their notes say it would making debugging more difficult since your driver will be off if it doesn’t work. No logs to diagnose discovery issues.

Sorry I missed this thread back in ‘23 otherwise I would have chimed in.

But you two basically have it. We have quite a few LAN drivers installed by default on hubs and each time discovery was attempted we would have to start every one of them. This is pretty hard on the hubs, especially busy ones. The search terms just provide a way for the hub to skip starting drivers unless it can see a device on the local network that might be what the driver is looking for. No information is passed to the driver from this scan; It is only used to filter out drivers that don’t have a matching device on the local network.

I would recommend just not including search terms for your drivers as any user that bothers installing a driver probably has that device.

3 Likes

Great insight. ST needs it because they come pre-installed.

1 Like