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 define what must occur for a task to be executed. They can be one of two types:
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 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.
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:
- 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.
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.
Hobson's task manager provides an API for task management such as the adding, updating and deleting tasks.
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:
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: