Bonjour helper #2087

[Julusian]

This allows modules to use bonjour(mdns) for device discovery with little/no effort.

To use, simply define a config field such as:

{
	type: 'bonjour-device',
	id: 'bonjour-test',
	label: 'Bonjour Test',
	width: 6,
},

And in your manifest.json:

	"bonjourQueries": {
		"bonjour_host": {
			"type": "blackmagic",
			"protocol": "tcp",
			"txt": {
				"class": "AtemSwitcher"
			}
		}
	}

This is a 'magic' config field, where Companion will populate and update the values for you.

The query is only run while the edit panel is open, and newly discovered services will be streamed to the client (the dropdown even updates while it is open).
If the selected device is not detected when the dropdown is opened, it renders that as an option which will disappear when unselected.
The 'Manual' option is forced to be there, as modules also need to provide manual address input fields for when bonjour is not working.
The value behind the options is shown in the brackets, and includes the ip address and port.

Q) Should this output the mdns hostname, or ip address? Perhaps that should be configurable by the module?
bmd-atem won't like the hostname, but it could explicitly resolve it first. and I worry about the reliability of mdns, and the potential for connections to break if it stops resolving correctly.

For hyperdeck:

bonjourQuery: {
	type: 'hyperdeck_ctrl',
	protocol: 'tcp',
},

[krocheck]

I was hoping eventually this type of field would be in manifest.json. On the Connections tab there would be a "Device Discovery" tab on the right (in addition to Add Connection) that would discover everything on the network and you can quick add those devices. But, this type of field to link to the hostname to track for IP changes would likely be necessary. I'd just maybe recommend moving the search definition to manifest.json if able to allow that future option without needing to revisit/move it later and break things.

It would be good to get the IP from the query and return that, but like I said it might want to be tracked for changes on startup? I don't ever trust local DNS unless its being managed in the DNS server, so I'd lean on IP in my implementations.

I'll have to do some packet sniffs on Shure to figure out what my options for filtering are compared to what you've found for BMD stuff, but that won't be in the short term.

[Julusian]

I was hoping eventually this type of field would be in manifest.json.

I was thinking about doing that, but it becomes more of a challenge to link things up, because we will need to know how to map that query back into a config field.

But perhaps if it is something like:

manifest;

{
  "bonjourQueries": {
    "query1": {
      "filter": {
        "type": "blackmagic",
        "protocol": "tcp"
      }
    }
  }
}

config:

{
	type: 'bonjour-device',
	id: 'query1',
	label: 'Bonjour Test',
	width: 6,
},

With that query1 being the link between the two?

It doesnt feel elegant to have it split like this, but its not something that will ever be changed once defined

[Julusian]

It would be good to get the IP from the query and return that, but like I said it might want to be tracked for changes on startup? I don't ever trust local DNS unless its being managed in the DNS server, so I'd lean on IP in my implementations.

Yeah I was wondering if it should use the address, hostname or let the module choose. I am happy to start with only allowing ip addresses. That is still friendlier than today, but not the best it could be.

Tracking changes could be interesting, but could also be a bit tricky for us to do on the modules behalf. Until the module is running we don't know its config fields (unless we start caching those too).
Perhaps we could mess with the dns resolver in the modules? That might be a bit far.