Architecture

Modules

The following figure describes the architecture from a modular point of view, being each of the modules described below.

_images/architecture_ewetasker.png

Task Automation Server

The Task Automation Server is responsible of managing automation rules. This platform provides functions for creating, updating, storing and erasing these rules. In addition, when programming these automations, users need to activate available channels or create new ones to control other smart devices. Finally, the task automation platform has a main role: to automate tasks. It must be able to connect with several channels for receiving events, evaluating them together with stored rules and performing a corresponding action. Task Automation Server module has been designed to carry out all these functions, and it has been split into four submodules: Rule Administration, Channel Administration, Rule Engine, and Action Trigger.

  • Rule Administration purpose is to provide an automation rule editor in which users can configure and adapt their preferences about events coming from all sources.
  • Channel Administration provides users facilities for creating channels. A channel is formed by Actions and events defined using Notation3.
  • Rule Engine submodule is where events will be evaluated together with stored rules generating the corresponding actions. It is based on an ontology model, which uses the EWE ontology.
  • Action Trigger is in charge of trigging the actions generated by the Rule Engine. Some examples of actions triggered by this module may be: opening a door, pushing a commit, sending an email or switching on a TV.

Mobile Client

Mobile Client module provides functions for managing rules from the smartphone. In order to create rules from the smartphone, users should have access to the available channel list which is centralized in the web TAS. For this purpose, Rule Administration connects with the Channel Administration submodule of the web TAS. This way, there are provided the available channels with their events and actions. Once available channels are received, rules can be defined via the graphic interface. It is needed that local repository was synchronized with the rule repository in the TAS, so when a rule is defined, it is sent to the TAS via POST request. Thus, users are able to manage rules in an easy way from their smartphones.

Furthermore, the mobile client is also an event source. It generates events coming from the device itself or from other sensors such as beacons, and sends them to the TAS. Events coming from outside are received by the Contextual Channel, whose main goal is to handle the data provided by different smart devices, and to send accordingly events to the server. The mobile receives from each beacon via Bluetooth the ambient temperature, the humidity and the distance.

Events coming from outside are received by the Contextual Channel, whose main goal is to handle the data provided by different sensors, and to send accordingly events to the server. The mobile receives from each beacon via Bluetooth the ambient temperature, the humidity and the distance. On the other side, the Smart Local Resources submodule receives events from channels such as Bluetooth, Wifi or Screen bright and sends them to the TAS. All events are converted to N3 format before being sent.

In the same way, once the TAS has evaluated the events, the JSON containing the generated actions are received by the Action Trigger submodule. Some examples of actions that may be triggered by this module are: to show a notification, to mute the mobile or to call someone.