Table of Contents:
1 Open the Box Software Stack
2 Open the Box Principles
3 Open the Box Applications Management
This preamble presents the concepts, and technical choices of the Open the Box Workshop. The reader should read these slides first.
1 Open the Box Software Stack
Each HAB hosts an instance of the Open the Box embedded architecture. This architecture is closely related to the OSGi framework, and is organized as described in the Open the Box Software Stack figure hereafter.
Figure 1 Open the Box Software Stack
This stack shows that the Open the Box components are deployed on the top of a classical Java OSGi stack. The standard components like Conditional Permission Admin (access right management), Configuration Admin (configuration), Log Service, Http Service (web server) are used, and implicitely contained in the « OSGi environment, Smart Home Operator APIs » layer. Then, the components named « base drivers » are deployed on top of this layer. They are designed to follow a unique way to represent devices connected to the HAB as OSGi services in the Java OSGi registry. As a consequence, the dynamicity of the availability of the devices locally connected reflects the reality. The application concept is also specified by the Open the Box project via a packaging enabling the publication of the applications in the Applications Store, and their deployment via an administration chain.
The Application Management module, in the figure above, incluses all the embedded software related to the Open the Box environment:
- the link with the administration chain, and the Application Store (MODUS, HABs Management Platform HMP/PFG, linked by a APIs REST layer with the AS, and the platforms of third parties services).
- the binding (via HttpService) with the end-user dashboard. The latter has been designed to be executed on an Android tablet.
- the third-parties applications access rights management (sandbox amongst applications, filtering of access to the Base Drivers services, etc.)
2 Open the Box Principles
The link between devices and applications is based on the use of OSGi services (concepts described in OSGi Core Specification). This link is automatically managed thanks to a format defined in the OSGi Declarative Services specification (see in OSGi Service Compendium).
The name of the service(s) provided by a device is exposed in the development environment via a service identified via its Java Interface name, and its properties.
This name and the related properties are generated by the Base Driver that corresponds to the device technologie (e.g. ZigBee, EnOcean.). More precisely, the Base Driver takes into account the data sent by the device itself. This data is expected to be in line with the OSGi Device Access specification (see chapter 103 of the OSGi Service Compendium). For example, an EnOcean device will be represented by a service registered by the EnOcean Base Driver with EnOceanDevice as Java interface, and the EnOcean specified ChipID, RORG, FUNC, and TYPE properties.
The services used (i.e. required) by a bundle must be declared by the developer in the Declarative Services file in the application bundle(s).
When a developer wishes to use a device, s/he must first have a look to the services offered by this device.
The applications can only access the OSGi services (and then devices) they are granted permission to. This access rights management is based on the OSGi Conditional Permission Admin specification (chapter 9 of the Core Specifications).
This tutorial explains how to develop an Open the Box application.
This one presents the base drivers that control each one of the available connectivity protocols.
3 Open the Box Application Management
Figure 2 High level architecture view
The smart home devices use some radio low throughtput sensors protocols (ZigBee, Zwave, EnOcean, etc.) as well as IP protocols (Philips Hue, Web Cam, etc.). A Java Runtime Evironment – together with the standard modularity level OSGi – hosts different third party applications on the embedded Gateway. This runtime environment can be deployed either on an ‘over the top’ Gateway (e.g., Raspberry Pi) or on an internet home gateway already present in the home for providing “triple play” services (e.g., LiveBox Play). This runtime environment is managed through BBF TR-69 — standard management protocol used by the TelCo to manage their own boxes (Gateways, STBs, network LAN element such as end point WiFi, PLC and so on) — by a distant management platform (Auto-Configuration Server, ACS). One or many Application Store (AS) and the third party application management platform (HAB management Platform, HMP/PFG) are connected to the ACS using an ACS wrapper exporting open APIs (REST).
An applications is available in an Application Store (AS), as soon as published by its provider. An Application Store (AS) presents to the user the list of all applications that are compliant with the user smart home devices:
Figure 3 View of the AppStore directory from the user dashboard
As soon as the user chooses and subscribes to an application in the AppStore directory, the AS allows her/him to control the application instal and its life cycle (e.g. stop and start) on the HAB:
Figure 4 Application management from the AS
A fine tuning of the application configuration is possible from the Dashboard:
Figure 5 dashboard home portal
This shows the installed application list as well as the list of the home devices discovered by Open the Box framework. From this Dashboard the user can start, stop, uninstall applications. The user can also assign in a precise manner the equipments to the installed applications through (Java/OSGi based) permissions:
Figure 6 Permission management from the Dashboard
The example above shows how to assign to an installed application some equipments picked out of the list of devices that are (potentially) required by this application.