Trigger-Action programming recently emerged as a paradigm for supporting end-users in defining the behavior of Internet-of-Things devices. It is often implemented by allowing users to define Event-Condition-Action rules visually. The possibility of using either states or events in triggers has already been discussed in the literature and their distinction may be difficult to understand for users. In this paper, we discuss how the definition of Event-State-ConditionAction (ESCA) rules to customize the behavior of IoT devices could be implemented in a Task Automation System (TAS), by adding a lay-er for monitoring events/states.
Trigger-Action programming (TAP) is emerging as a paradigm for supporting end-users, particularly
those without programming skills, in defining the behavior of Internet-of-Things devices and digital
web services. TAP is a simplified form of the Event Condition Action (ECA), a common approach for
rule-based systems, originally employed to manage databases [
A source of complexity in the TAP paradigm derives from the fact that triggers can indicate both instantaneous events or states [3], and users are not always able to understand the difference between the two [4, 5]. One of the most important causes is the temporal aspect of triggers and actions [4, 5] since users are often confused when they have to distinguish triggers based on events (i.e., that occur in a specific moment in time) and states (i.e., that are true over a time span).
Task Automation Systems (TAS) [6] are web-based tools that support users in defining smart objects’ behavior through visual interfaces. Among the most popular ones there are IFTTT [7], Zapier [8], and EFESTO-5W [9-11]. They typically support users in the definition of the smart object's behavior through the visual creation of Event-Condition-Action (ECA) rules. From a technical point of view, one of the most critical aspects of TASs is trigger monitoring. Let us consider the following ECA rule:
IF the alarm is turned on
THEN switch off all the lights
Two main solutions are currently adopted by TASs to monitor the triggering events, and this depends on the technology implemented by the smart devices. The simplest and less effective solution consists of periodically invoking the smart object’s API related to the triggering event. Considering the previous rule, a TAS must invoke the API of the alarm to check if it is turned on. This is a low-effective solution because of the overloading of connection and the overusing of device energy. A more efficient and effective solution is the use of a Publish-Subscribe architecture, such as the MQTT protocol. In this architecture, there are three main actors, i.e., the publisher, the subscribers, and the broker. The publisher is an entity, a smart object in our case, that sends a message to other subscribed entities. The subscriber is an entity, a TAS in our scenario, that receives the messages from the publisher. The broker is a virtual component hosted on a web server that implements the publish/subscribe mechanism: the publisher notifies the broker only when an event occurs (e.g., the alarm is turned on) and the subscribers are notified by the broker only when the event is triggered. An advantage of this architecture is that several entities can subscribe to the same publisher, in our case several rules can subscribe to the same event without overloading the smart object. 2.1.
The majority of the smart objects expose sensors data to third party-applications as (instantaneous) events. In order to allow TASs to monitor the states of those smart objects exposing only events, the proposed solution is to create a middleware in the TAS rule engine where, for each smart object, the internal representation of the device is extended to generate states starting from its events. As reported in the following code, the first time a smart object is connected with the TAS, there is an initialization phase: for each event i, its API is invoked and the variable statei is set according to a mapping between the event values and the state values, previously defined by the TAS administrator. For example, in the device Smart light, the API of the event “Is turned on” can return two values, i.e., true or false; these values are mapped in the values “Is on” and “Is off” that can be associated with the variable state.
Then, every n seconds, the event value is read through the API and the state variable is updated if differs from the previous value. The device states are made available to the TAS through MQTT APIs automatically generated so that, if the state value changes, all the subscribers are notified. Initialization:
Var statei = map(eventi) loop: if (map(eventi) != statei) then:
statei = map(eventi); endif; endloop;
Although most of the smart objects expose their sensor data as events, in some cases, smart objects could provide API for monitoring only their states. Similar to the solution presented in the previous section, in the middleware the internal representation of the smart objects must be extended to provide its states as events. In this case, to generate the eventi starting from the statei, a specific component in the middleware has to continuously query the API of statei and, if the state value is changed with respect to the last query, the eventi is triggered. For example, in the smart device Thermostat, the state “Temperature hot” would be associated with the event “Temperature goes above 25°C”; if the state changes from False to True (e.g., if the temperature goes from 24°C to 26°C), then the event is triggered. This behavior is summarized more formally in the following pseudocode:
Initialization:
Var eventi = map(statei) loop: new_statei = API_state(i) if (statei != new_statei) then: trigger(eventi);
statei <- new_statei; endif; endloop;
In this position paper, it has been proposed an approach to enrich a TAP architecture with coordinated states and events for a more expressive definition of ECA rules. The main goal is to inform designers and developers of TASs of the possibilities offered by the Event-State-Condition-Action paradigm and on the possible technical solutions to implement it in their TAS.
This work is partially supported by the Italian Ministry of University and Research (MIUR) under grant PRIN 2017 “EMPATHY: EMpowering People in deAling with internet of THings ecosYstems.”.