Basic components and system architecture of the Zigbee module.

ZigBee Layers

• Zigbee Device Access Adapter Layer - Provides integration of the Zigbee core services with the Device Access system so that ZigBee devices can be managed through the abstraction layer of DA.
• Zigbee Driver Layer - Provides interfaces for discovery and management of Zigbee PRO devices. Handles communication between the OSGi Framework and the ZigBee PAN via the PAN coordinator connected to the gateway.

ZigBee Components

• Zigbee Devices- Two types of devices:
  • Coordinator: A central device that creates a Zigbee(PRO) network. Again it runs all Zigbee layers - MAC, NWK and APS. For a list of supported coordinators see the Setup Guide.
  • End Devices: An end device, running the Zigbee (PRO) stack and implementing all layers - MAC, NWK and APS.
• Zigbee OSGi Driver Bundles - Driver bundles for the diffrerent Zigbee Coordinator brands. A driver bundle establishes a connection with a Coordinator (over a serial port or TCP/IP) and manages its network. The communication with the coordinator is based on a proprietary API.
• ZCL Metadata Processor and Providers - This component defines a Java API reflecting the Zigbee Cluster Library (ZCL). By using the ZCL Metadata Service applications can obtain cluster and profile descriptions from the module's metadata.

  The metadata itself is stored in separate metadata components and thus it is possible to add metadata support for new profiles/clusters.

  ZCL Metadata Providers describe a set of clusters, profiles and devices, which the ZCL Metadata service uses to process ZCL frames exchanged between our Zigbee stack implementation and your network. They provide XML-based descriptions of ZCL clusters and profiles to the other components of the Zigbee module (console commands, visual editors and test tools). Optionally it can include interfaces and constants used in the descriptions.

  The Zigbee Module has built-in metadata providers for all functional domains defined in the General ZCL specification. In this case the definition of each functional domain is included in a separate metadata provider. Home Automation and Smart Energy profile providers are also included in the Zigbee Module. In the common case one provider defines one profile and the clusters and devices defined by this profile.

  In the OSGi context each metadata provider is represented by a separate bundle. The first condition which distinguishes a metadata provider bundle is the presence of the "zcl-metadata" folder that contains the resources of clusters, devices and profile definitions. A metadata provider is identified by the symbolic name of the bundle that contains the "zcl-metadata" resources. The second condition is to declare the symbolic name of the provider in the Metadata configuration.

  The metadata configuration of the Metadata Provider bundle contains two properties: the one specifies the symbolic names of the bundles, which are considered Default Providers for the ZigBee Module, the other - the Provider Extensions.

  When a bundle is installed in the framework, it is checked for availability of zcl-metadata resource folder in its jar file. If present, it is considered a Metadata Provider. Then based on a check in the metadata configuration, the bundle is considered either a Default Provider or an Extension Provider.

  • Default Providers - providers which are preliminary built-in and installed with our ZigBee module. They are mandatory and persistent for the configuration, that is, they can't be deleted at runtime. It's required the metadata implementation to process all ZCL definitions from the default providers before registering the OSGi service and taking further actions.
  • Extension Providers - additional providers which can be installed in order to provide some customization into the Zigbee Module. For some applications the ZCL Metadata must be extended with extra clusters and profiles. The extensions are optional depending on the functionalities which the Zigbee module must provide. The metadata configuration is updated with the symbolic name of the bundle when a provider extension is installed and processed, and when the bundle is uninstalled its name is removed from the configuration.

  The ZCL Metadata Service is registered asynchronously. It waits to parse and store all pending providers, which means all required default providers and initially registered extensions.

• Zigbee DA Protocol Adapter - Provides central control over Zigbee devices from the Device Access by mapping Zigbee Clusters to Device Access Device Class Objects.

  The module contains Cluster-to-Device-Class-Object mapping for various Zigbee profiles and It is possible to add support for new profiles.

• Zigbee Console Commands - A set of text console commands for monitoring and control of the devices in a Zigbee network. It uses the ZCL Metadata Service to provide friendly description of the commands to any device and the Zigbee driver services to send requests from users to target devices.