Zeta Framework

ZetaFramework is the software intended to operate the Zeta devices, providing a framework where we can develop our custom applications to work with zetas, based on an OSGi environment.

We can build ourselves the ZetaFramework following these guide, or we can download a pre-packaged binary distribution.


The ZetaFramework architecture is organized into several layers:

Serial Communication Layer provides raw access to the serial port which allows communication with the ZlitaUSB. The serial middle-interface defines a SerialConnection service, which basically allows writing bytes and notifies about incoming bytes, and a SerialDriver service, which is in charge of creating and discovering available SerialConnections. Main bundle implementing SCL operates the UART interface, but other stream-based interfaces, such as a Bluetooth connection, may adopt the same middle-layer interface, allowing communication with Bluetooth devices transparently to the upper layers. In our particular case, we have implemented an application service that wraps a SerialConnection into a TCP socket, and at the remote client, another bundle creates a SerialConnection that allows communication with the SerialConnection on the server side like a local one.

Zigbee Layer comprises two sub-layers: Zigbee Gateway Sub-Layer (ZGSL) and Zigbee Driver Sub-Layer (ZDSL). This is because there are several versions of the communication API with the ZlitaUSB, which lead us to split the layer to ease development. Zigbee Gateway Sub-Layer encapsulates the communication with the ZlitaUSB, implementing its communication protocol by means of a ZigbeeGateway service. When a SerialConnection is published by the SCL, the ZGSL bundle checks whether it corresponds to a ZlitaUSB, and it publishes a ZigbeeGateway in such a case. Above it, the Zigbee Driver Sub-Layer creates a ZigbeeDriver service that uses the ZigbeeGateway to accomplish network operations, such as network creation, devices discovering or error maintenance. For every node discovered on the network, the ZigbeeDriver creates and publishes a ZigbeeNode service representing that device, which allows sending and receiving messages to and from the physical device, and provides ZigBee related properties such as its MAC address or its type.

On the upper layer of the architecture is found the OSGi4AMI devices layer. OSGi4AMI states for ontology which model devices that can be available on Ambient Intelligence environments. The OSGi4AMI middle-interface provides generic interfaces for common sensors, actuators and tangible interfaces. For example, TemperatureSensor or OutletActuator, which allow reading temperature or actuate over mains powered devices, respectively. The OSGi4AMI driver bundle publishes an OSGi4AMI Driver service that tracks for ZigbeeNode services, discover the functionalities that physical devices provide (temperature sensing, humidity sensing, etc.), and creates OSGi4AMI Devices services which encapsulate those functionalities.