Site Tools


Bridging Project

NOTICE: This code is currently on IoTivity master. This code will be found in IoTivity 1.3 and beyond.

As IoTivity is compliant with only the OCF ecosystem (with relatively low to no native devices on the market) the community needs a way to bridge into other ecosystems to leverage ongoing support for the ever-growing OCF ecosystem. It is beneficial for developers and product manufacturers to support the OCF ecosystem as early as possible. The Bridging Project aims to provide the infrastructure and plugins to support developers and product manufacturers. Since IoTivity is open source, any developer or product manufacturers can help create more plugins.

Some OCF & IoTivity members have developed the infrastructure and plugins needed to spur the Bridging Project. For now, some of the material is still undergoing review by the IoTivity community under the IoTivity-dev mailing list.

Every bridging implementation is referred to as a “plugin.” The infrastructure these plugins fit into is referred to as “Mini Plugin Manager.”

Info About IoTivity's Bridging Project

IoTivity's Bridging Project consists of three core components:

  1. Plugins
  2. Mini Plugin Manager (MPM)
  3. MPM Client

Considerations: There are three bridging schemes within OCF & IoTivity. Two are certifiable now with the OIC1.1 specification while the other will be certifiable in the future with the OCF1.0 specification. All enable translation logic to performed in the application layer above the IoTivity API. (IoTivity itself is considered a “Middleware” extension of communications' layers.)

The first scheme you can choose to proxy for an OIC Smart Home device type directly. This scheme works with OIC1.1. (e.g. Philips Hue smart light → OCF Smart Light)

In this scheme you have a single instance of IoTivity per device type and proxy any
discovery, create, retrieve, update, delete, or notify requests between the client and
bridged device.

The second scheme you can choose to implement is to map between ecosystems. This scheme works with OIC1.1. (e.g. ZigBee HA → OCF Smart Home)

This scheme is much like the first one, except you can host more than one OIC Smart Home
device type in a single instance of IoTivity. You set the device type of your instance of
IoTivity to "oic.d.bridge". Then you represent each device you want to host as a collection
resource. Each collection that you create that has a device type (i.e. "oic.d.*") in the
array of resource types is recognized as a device. Each collection recognized as a device
binds the associated resources within it. (Use "bindResource" API for this.)

The third scheme you can choose to implement in to bridge ecosystem-to-ecosystem. This scheme will work with OCF1.0. (e.g. AllJoyn ↔ OCF, ZigBee HA ↔ OCF, …)

This scheme is under implementation in its own project:
Please refer to that project for current status.


Current supported plugins:

  1. LifX Plugin
  2. Honeywell Lyric Plugin
  3. Nest Plugin
  4. Hue
  5. ZigBee Plugin (uses scheme 2 above) (currently in transition from <iotivity>/plugins to <iotivity>/bridging)

Plugin Implementations can be found here: <iotivity>/bridging/plugins/

Mini Plugin Manager

The Mini Plugin Manager (MPM) is the infrastructure component of the Bridging Project. This is implemented as a C/C++ Library. Since this piece is implemented as a library, a sample application “MPM Client” has been developed to flex the usage of the APIs.

The MPM is poised with the following functionality:

  • Load a Plugin.
  • Unload a Plugin.
  • Invoke SARR (Scan, Add, Remove, Reconnect) features of a Plugin.

Although, the MPM is written in C/C++ and the sample plugins developed have been written in C/C++, plugins do not have to be written in C/C++. They just have to be managed by the MPM. (If absolutely needed, you could write a tiny shim layer to connect with the MPM in a higher-level language.)

The Mini Plugin Manager header and source files can be found here: <iotivity>/bridging/minipluginmanager

MPM Client

Since the Mini Plugin Manager is implemented as a library, it required a head (or application-level invocation). The MPM Client was created to fulfill this need. The MPM Client simply wraps the Mini Plugin Manager and offers a command line interface to flex the APIs.

  1. mpm_sample_client.

Note: You may invoke the Mini Plugin Manager APIs directly without the MPM Client.

The MPM Client header and source files can be found here: <iotivity>/bridging/mpmclient

Metatags: bridge project, mini plugin manager, mpm, minipluginmanager, plugin, mpmclient mpm_client, mini_plugin_manager, miniplugin, mini_plugin, pluginmanager, plugin_manager

bridging_project.txt · Last modified: 2017/07/01 19:22 by josephlm