The interactions between the gateway and other entities are performed through an extensible set of northbound and southbound bridges.
Southbound bridges are specialized into the interaction with devices, which can be sensors or actuators. Each bridge is in charge of the communicating with a specific kind of device, using a given protocol. Out of the box, sensiNact ships with southbound bridges for using a lot of common devices including Zigbee (motion sensors, force sensor,etc.), EnOcean (remote controls, windows opener detectors, etc.), CoAP (sliders, buttons, etc.). It also provides a bridge for retrieving context information using NGSi 9/10 protocol. Thanks to an OSGi based architecture, it’s possible to add bridges on the fly, while the gateway is running, to allow the communication with new kind of devices. Of course, the creation of bridges relies on an API which delegates most of the integration work to the gateway, letting the programmer focus on the communication protocol and the data model of the device to be integrated.
Symmetrically to the southbound bridges, northbound bridges are in charge of publishing information to remote systems. It can be using common protocols, for example MQTT, XMPP, NGSi 9/10. The set of northbound bridges is also extensible, for tailoring special needs or singular systems. The REST API, which is a northbound bridge, is a key part in our architecture. It is designed for the administration of the gateway, thanks to a well-documented API. This administration can be performed directly by an administrator, or using third parties, such as a studio (see below).
The Generic module provides a set of intermediate data structures at different complexity levels to ease and accelerate the integration of new southbound bridges (see the corresponding tutorial to learn more about it).
All the communications managed by sensiNact Gateway are converging to a central piece: the Core gateway. This element is in charge of the overall coordination of information, involving two managers: the device manager and the application manager. The device manager, with its associated database stores all the information regarding devices. This include devices availability, devices properties, location, etc.
The application manager
The application manager (also known as the AppManager) is a bit more complex. Its goal is to instantiate and execute applications, listen for devices availability and update applications lifecycle. Application management is performed through the REST API. The application is sent to the gateway packed into a JSON file. Then, the application is installed by the gateway, and can then be started, stopped or uninstalled.
The application manager provides a plug-in facility to extend its behavior. The two main plugins are the Basis plugin, and the Complex Event Processor plugin. The Basis plugin provides the basic structure for creating applications. It allows the triggering of rules, based on events. Then, a condition can be evaluated, and actions performed accordingly. Of course, events, conditions and actions are related to devices, using the device manager. Using the Esper Engine, the Complex Event Processor plugin is able to generate high level events based on low level ones. For example, it’s possible to know that two events occur in a given time interval, with a given order. The events generated by the CEP plug-in can be used in the Basis plugin.