...
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.
Plugins
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:
...
| Gliffy | ||||
|---|---|---|---|---|
|
Plugin/Device Class Hierarchy
Both HobsonPlugin and HobsonDevice 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
Variables provide a way to obtain information about and/or control an entity.
...
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.
Architecture
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.
The Plugin Lifecycle
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.
...