Hobson plugins will sometimes have to use external entities to communicate with devices. For example, Z-Wave controllers typically require the use of a serial port and Philips Hue bulbs require the use of a bridge device. Hobson refers to such entities as device bridges.
In order to make plugin configuration as simple as possible for the user, the Hobson Hub needs to automatically discover and expose device bridges that could be used for configuration. An ideal user experience would have the user selecting from a list of serial ports that are available when configuring the plugin rather than having to identify valid serial ports through some other means.
A more complex example would be services that are advertised over SSDP. The knowledge of which SSDP services are useful could be distributed across multiple Hub plugins. For example, each plugin may only be able to identify one particular type of advertised SSDP service. However, it would be inefficient for each plugin to send out SSDP discovery packets as the network could become congested. It is better for a single "gatekeeper" to be in charge of sending/receiving SSDP data and passing it along to objects that know how to analyze it.
This is the premise behind the Hobson Device Bridge mechanism.
An DeviceBridgeScanner searches for device bridges via some channel (e.g. local hardware, network, etc.). The scanner doesn't try to make sense of what it discovers – it merely captures the raw data (in the form of DeviceBridgeMetaData objects) for analysis by another entity.
All DeviceBridgeDetector objects registered with the runtime are given the opportunity to analyze DeviceBridgeMetaData objects created by DeviceBridgeScanners. If a detector is unable to identify it, it does nothing. However, if it does identify it, it creates a DeviceBridge object containing structured information about the bridge that can be queried for and used by other Hub mechanisms such as web console configuration.