An important capability of 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 SSDPis that of device discovery. Whenever possible, plugins should automatically detect smart devices to eliminate (or at least minimize) manual user configuration.
To support this, Hobson has a special manager – the DiscoManager – and an associated DeviceAdvertisement class. The relationship is as follows:
| Gliffy | ||||
|---|---|---|---|---|
|
Plugins can provide a DeviceAdvertisement object to the DiscoManager which will, in turn, publish it as a DeviceAdvertisementEvent. Other plugins can indicate interest in receiving DeviceAdvertisementEvents (by returning a protocol-specific topic name from the getEventTopics() method – see EventTopics.createDiscoTopic()). There is also a mechanism for plugins to request all device advertisements that occurred before the plugin became active. This decoupling is useful because often plugins that know how to generate DeviceAdvertisement objects are not the same plugins that can make use of them.
A DeviceAdvertisement, among other things, has both a protocolId and rawData:
| Gliffy | ||||
|---|---|---|---|---|
|
The protocolId attribute indicates the channel from which the device advertisement originated. This might be a network protocol, local hardware, etc. The rawData attribute is the advertisement data in its raw form. The object property is the device advertisement data in a more useful, structured form if applicable.
An example will help illustrate the concept.
Many devices broadcast their availability as SSDP services. The knowledge of which SSDP services are useful could be is likely distributed across multiple Hub plugins . For example, each plugin may only be able to identify one particular type of advertised SSDP service– for example, a Sonos plugin would only care about Sonos-related services while a Roku plugin would only care about Roku ones. However, it would be inefficient (and possibly cause network congestion) for each plugin to send out its own 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 service information and passing pass 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 configurationIn this example, an SSDP plugin would create DeviceAdvertisement objects (with a protocolId of "ssdp") and provide them to the DiscoManager. Plugins that care about SSDP advertisements would listen for DeviceAdvertisementEvents that contain SSDP DeviceAdvertisement objects.