Note: If you haven't already done so, reading the Hobson Home page will provide helpful context.
Being an automation hub, it is Hobson's job to expose disparate types of smart devices (e.g. lights, thermostats, etc.) in a consistent way. Hobson is designed around a completely modular architecture that allows third-parties to easily create plugins to integrate with new types of hardware and sources of data.
The Hobson Hub is comprised of multiple plugins, each of which performs a discrete piece of functionality. Here's an example of some of the plugins you might find installed in a Hub:
Note that plugins are used not only for device control (e.g. Foscam Camera, Philips Hue) but for core Hub capabilities such as scheduling and the web management console.
At it's simplest level, creating a Hobson Hub plugin involves creating a HobsonPlugin implementation that creates one or more HobsonDeviceProxy implementations. Each HobsonDeviceProxy is responsible for monitoring and/or controlling an external entity – a light switch, a weather API, etc. Everything is packaged as a Hobson Plugin Bundle which can then be installed on and used by the Hobson Hub.
Note: There should only ever be one HobsonPlugin implementation per plugin bundle.
Both HobsonPlugin and HobsonDeviceProxy are interfaces that can, in theory, be implemented directly. However, the Hobson API provides two abstract classes that make the developer's job quite a bit easier and it's recommended to use them as a starting point.
Note that the diagram above shows the MyHobsonPlugin creating 0 or more MyHobsonDevice instances. It is not mandatory for a plugin to create devices (see the next section for an example).
Variables provide a way to obtain and/or change the state of an entity. Variables are appropriate when:
Each HobsonPlugin can publish zero or more global variables that aren't specific to a particular device. For example, the OpenWeatherMap plugin publishes a global variable that represents the current external temperature. Another example of a global variable is whether the Hub is in "vacation mode".
Each HobsonDeviceProxy can publish zero or more device variables that provide the capability to obtain the state of and/or exert control of a device. For example, a light will usually publish an "on" variable that provides state information (is the light on?) when it is read and provides control when it is set (turn the light off).
There are three types of variables that can be published:
The presence of variables, through a documented naming convention, indicates the capabilities of a device. For example, the presence of a read-write "on" variable means that a device is switchable. This information is used, among other things, to drive user interfaces.
Actions provide a mechanism for more complex control of plugins and devices. Actions are appropriate when:
Both HobsonPlugin and HobsonDeviceProxy classes can publish actions. Plugin actions are appropriate for actions that are not device-specific and Device actions are appropriate for actions that are.
The Hobson Hub is built on the OSGi framework which in turn runs on a Java Virtual Machine (JVM). However, as a plugin developer, the details of OSGi are hidden by several manager interfaces as shown below:
These manager interfaces (action, device, disco, etc.) hide the OSGi-specific details from your HobsonPlugin. This separation makes it much easier to test the core Hobson code and simplifies dependencies for HobsonPlugin implementations.
As mentioned above, Hobson plugins are deployed to the Hobson Hub as OSGi bundles. A bundle is simply a Java JAR file that includes some additional, OSGi-specific metadata.
Here is an overview of a typical plugin bundle lifecycle: