Tasks

Owned by Daniel Noguerol
Last updated: Aug 10, 2015
3 min read

Introduction

Hobson wouldn't be a very useful system if it couldn't react to changes in the world around it. A user creates tasks to tell Hobson what changes to watch for and what actions to take when those changes occur.

A task is comprised of two primary components:

  • A set of conditions
  • A set of actions

Conditions

Conditions define what must occur for a task to be executed. They can be one of two types:

  • trigger
  • evaluator

A trigger condition is the condition that Hobson watches for to potentially take further action. There can be only one trigger condition in a task.

Some examples of trigger conditions are:

  • A change in device(s) state (e.g. a light in the basement turns on).
  • A change in presence (e.g. John arrives home).
  • A specified time occurs (e.g. it's 3:00pm on January 1, 2015).

When a trigger condition is detected, Hobson will evaluate any evaluator conditions defined in the task. Some examples of evaluator conditions are:

  • Device(s) are in a certain state (e.g. all basement lights are on).
  • The current time is between 8am and 6pm.
  • The outdoor temperature is above 70 degrees fahrenheit.

If all evaluator conditions are true (or if none have been defined) the task is executed.

Actions

Actions represent the work Hobson does when a task is executed. For example:

  • Turn on all lights in the house.
  • Activate an alarm siren.
  • Send an SMS.

A task can define one or more actions and, when the task is executed, each action is performed in the order it was defined.

Condition and Action Classes

The available task conditions Hobson can evaluate and the available task actions it can execute are determined by condition and action classes published by Hobson's installed plugins.

Condition Classes

When a plugin wishes to provide a new conditional capability to Hobson, it does so by publishing a condition class. A condition class defines a set of supported properties (i.e. key/value pairs) that indicate the information required for the condition to be evaluated. A plugin can publish both trigger and evaluator conditions.

For example, the scheduler plugin publishes a trigger condition named "schedule". That trigger condition requires the following information in order to be evaluated:

  • Date
  • Time
  • Recurrence Interval

The condition class published by the scheduler plugin defines those three items as supported properties. When a user creates a task that uses the "schedule" trigger condition, they are required to provide values for the three supported properties of the condition class.

Action Classes

When a plugin wishes to provide a new action to Hobson, it does so by publishing an action class. Like a condition class, an action class defines a set of supported properties (i.e. key/value pairs) that indicate the information required for the action to be executed.

For example, an SMS plugin might publish an action called "sendSMS". That action might require the following information in order to be executed:

  • A destination phone number
  • The message to send

The SMS plugin would publish an action class that defines those two items as supported properties. When a user creates a task that uses the "sendSMS" action, they would be required to provide values for the two supported properties of the action class.

Task Manager

Hobson's task manager provides an API for task management such as the adding, updating and deleting tasks.

Initialization

When the task manager initializes, it sends "create" events to the appropriate plugins for all tasks that exist in its persistent store. The appropriate plugin is determined by a task's trigger condition. For example, the scheduler plugin would receive a "create" event for every task that has a "schedule" trigger condition.

The below diagram shows the task manager's initialization sequence:

Triggering

When a plugin detects that a trigger condition has occurred, it alerts the task manager. The task manager will retrieve the details of the task and evaluate any evaluator conditions to determine whether the task should be executed.

The below diagram shows an example of the sequence for a schedule trigger condition occurring:

 

Task Class Diagram

The below diagram shows the task-related class hierarchy: