

Active House Manual


This manual is designed to give a detailed overview of our Active House system. It demonstrates how we use the Cambridge Event Architecture (CEA) to glue together different devices in a distributed environment.

The manual is divided into three major sections. The first gives an overview of our Active House and the devices found within it. Furthermore, it will explain how the devices can be controlled. In the second section, we will explain how simple devices interact using events. Finally, we will explain composite event expressions and show how we can use them in our Active House to implement more interesting scenarios.

The House

In the demonstration, our house consists of six rooms. Certain rooms are connected via doors. The house is occupied by the Simpson family (Homer, Marge, Bart, Maggie, and Lisa). They move through the rooms at random.

The Active House

The Devices

The Active House has a number of networked devices. These can communicate with each other via the event system. Most devices on the network are event sources, as well as event sinks, meaning they can both produce and receive events.

Security Cameras

Each room is equipped with a security camera. These cameras continuously monitor the rooms by taking snapshots of the people in the room (approximately every second). The five cameras are connected to a security system. This extends the functionality of a single security camera. By grouping the cameras into a single device, the security system device (Secsys), one can receive information concerning the whereabouts of the people from a single device.

The security system produces two event types, These are enter and leave events. As mentioned in the overview, events are parameterised. The parameters for enter and leave events are a room name and a person name.

The Toaster

The kitchen contains a toaster. It produces food_ready events when toast has been toasted. Furthermore, it performs an action, namely the start to toast action.

The Doorbell

The doorbell is similar to the toaster device in that it only produces one event and can only perform one action. The event it produces is a doorbell event and the action is a ring.

The Stereo

The lounge has a stereo. It can produce two events, mute and un-mute. Besides being able to perform a mute and un-mute action, the steroe can also be switched on and off (activate and deactivate).

The Lights

Each room has a light. These lights produce light events when switched on or off. They are parameterised events to indicate whether the light is turned on or off. The light can also be set on a timer (default), in which case a light will switch itself off five seconds after everyone has left the room.

The Kettle

The kitchen has an intellignt kettle which can produce tea or coffee. It sends a food_ready event whenever tea or coffee has been made. The food_ready events are parameterised because we have a food_ready event for tea, coffee, and toast.

The Output

The output device allows the owner of the house to monitor specific event occurrences, by outputting them to a screen. Just like the other devices, the output registers interest with specific event sources. When the events occur and the output device is notified, the actual event information is printed on the screen.

Device Controls

Each device has a control panel. This control panel can be opened by double clicking on its name in the list below the virtual house (see above figure). The control panel of a normal device has five tabs. Below we will detail the functionality of a toaster control panel.

Control Tab

Toaster Control Tab
A device can be activated or deactivated from the control tab. This means the user of the house can control which devices are available on the network. Furthermore, if a device can perform actions they can be manually started from this tab. Clicking on the Make Toast button will cause the toaster to start making toast. We can think of this functionality as a remote control, which lets us perform specific actions with our devices.


Toaster Register Tab
Here a device can register interest with event sources. Pull-down menus let the owner of the house choose event sources with which the device can register. The owner may choose from a list of sources. Once a source has been chosen, the event type menu will display all available event types for that source. Finally, the user may specify parameters for an event. This can be done by activating the specify parameters radio button and clicking on the change button. The user can then enter specific parameters for the event.
Parameters allow for fine-grained registration. Since our events are typed, we can specify parameters for the events on registration. For example, we may be interested in an enter event. In the Active House scenario, enter events have two parameters. The first is a name (the person entering) and the second is a location.
Once a device has registered interest with a particular event source, the device will be notified as soon as that event occurs. If parameters have been specified, the source will only notify the sink if the parameters have matched.


Toaster Deregister Tab
This tab shows the user a list of event sources which the current device has registered with. This is a detailed list since it also shows the parameters for each event and the event source registered with.
The user can deregister with event sources by selecting an item from the list and clicking the deregister button.


Toaster Sink Tab
The sinks tab lists all sinks (devices) on the network that have registered interest with the current device. The list also details event parameters upon which the current device will notify. Furthermore, it details the device that registered interest. This tab becomes very interesting when we have composite events. It shows the individual sources which are part of a composite event. For example, if the security camera in the kitchen is part of a composite event expression, the sink tab of this device will list the composite event in its window.


Toaster Rule Tab
The rules tab lets the user specify actions to be taken when specific events have occurred. This is the well known event-condition-action paradigm found in most active systems. By specifying an event, a condition and an action, the user of the house can control the devices. In the diagram to the right, two event-action-condition rules have been enabled for the toaster. The first one states that when anyone enters a room, toast will be made. The second states that whenever the doorbell rings, the toaster will be activated.

Simple Events

In this section we will go through two simple scenarios which should enable the reader to start testing the system by running the Active House Demonstration.

Scenario 1

The first example uses two devices, the toaster in the kitchen and the doorbell. We want the toaster to make toast whenever the doorbell rings. Homers' father is coming over for tea and we would like the toast to be served immediately after he arrives.

To begin, we need to open the control panel for the device Toaster. We must then open the register tab and register interest with the event source Doorbell. We can do this by simply selecting doorbell from both the event source and event type menus. We register with the source by clicking the register button. We can check and see if we actually registered with the event source by checking in the Sinks Tab of the source device, in this case the doorbell device.

Next, we need to specify the action to perform once the event (doorbell) is received by our device. To do this, we need to go to the Rules Tab. Here we must select doorbell from the event type menu and "make toast" from the action menu. The rule is enforced once we click the "add rule" button.

To test our system, we once again go to the Doorbell control tab and click on the "press me" button, at which time our toaster should start toasting. Have a go!

Scenario 2

Here we want to illustrate a somewhat more complex example. We will use the example above as a starting point, but with two minor modifications. Firstly, we want the toaster in the kitchen to start toasting when anyone enters the kitchen. Secondly, we also want to make tea once the toast has finished toasting.

We start by opening the control panel for our toaster. We must register interest with the security system device (Secsys). We choose Secsys from the Event Source menu and enter from the Event Type menu. This time, we need to specify a parameter for the event. Remember, we wanted to be notified when anyone entered the kitchen. To do this, we must select the Specify parameters radio button and click on Change. We then have a new window, which allows us to specify parameters. Parameter List The diagram on the left shows that window. We must choose kitchen as the parameter to match on. Once we have done this, we can register with the source.

We must now register the kettle with the toaster in the kitchen. Again, open the Kettle control panel and choose the Register tab. Select Toaster as the source to register with and the event type food_ready. In order for the kettle to start making tea when we receive a food_ready event from the toaster, we have to specify a rule. Go to the Rules tab and select the food_ready event and the tea action from the menus. Activate the rule. Finally, we must activate the rule for our toaster in the kitchen. We said that we wanted it toast as soon as someone entered the kitchen. In the Rules tab of Toaster choose the enter event from the event type menu and make toast from the action menu. Once we activate the rule, the system is ready to go. See for yourself!

Composite Events

In the overview we have explained the composite event algebra used in the Cambridge Event Architecture. In this section we will begin using this algebra for a few specific scenarios. The table below gives some examples.

Explanation Algebra
A person entering the Kitchen, followed by the occurrence of a food_ready event. enter(person, "Kitchen"); food_ready()
A person entering the kitchen or the Lounge. enter(person, "Kitchen") | enter(person, "Lounge")
A person entering the kitchen followed by a food_ready event (i.e. the toast has been toasted) while the person has not left the kitchen. Thus, whenever a person enters the kitchen, and toast pops-up out of the toaster while that person is still in the kitchen, the composite event has occurred. enter(person, "Kitchen");(food_ready() - leave(person,"Kitchen"))
A person entering the Kitchen and the Office. The order in which these two events occur is irrelevant. The person can first enter the office and then other rooms before finally entering the kitchen. There is no time constraint. Similarly, the person can first enter the kitchen and then the office. enter(person, "Kitchen") & enter (person, "Office")
The first occurrence of a person entering a kitchen. The evaluation begins immediately after the composite event has been created. FIRST(enter(person, "Kitchen"))

Creating a new Composite Event Server (CES) is done by entering a Composite Event Expression (CEE) in the Composite Event window of our applet. We create a CEE by specifying a name and a list of parameters, followed by a valid event algebra expression. We will look at each of the examples from the above table in turn.

The FOLLOWED BY Operator

Composite Event Expression The figure to the left shows our first composite event expression. It uses the followed by operator. With the expression we can monitor the occurrence of a composite event that consists of a person entering the kitchen followed by a food_ready event from Toaster. The name of our new CES is CompEvent1 and the one parameter for the CEE is person. This parameter can be specified once the CES has been created and event sinks register interest with the CES.
It may be that we are interested in Homer entering the kitchen follwed by a food_ready event from Toaster. As an example, we may use the Output device to register interest with CompEvent1. When doing so, the parameter person can be specified upon registration.

The OR Operator

Composite Event Expression In the second composite event expression example we illustrate the use of the OR operator. This time we specify two parameters for the expression, namely person1 and person2. The reason is that we may want to later differentiate between different people entering the kitchen and the lounge. For example we might be interested in a composite event where either Homer enters the kitchen or Marge the lounge. If we had had specified one variable, we would have only been able to monitor for the same person entering either the kitchen or the lounge.

The WITHOUT Operator

Composite Event Expression This composite event expression is somewhat more complicated. It uses three different events and two different operators. The expression monitors for a person entering the kitchen, followed by a food_ready event from Toaster, while that person has not left the kitchen. One variable, person, is specified for the expression, which lets us later parameterise the composite event.

The AND Operator

Composite Event Expression This example illustrates the AND operator. It is very similar to the followed by operator, except that the order in which the individual events occur does not matter. Whether the person enters the kitchen and then the lounge or the lounge and then the kitchen is irrelevant.

The FIRST Operator

Composite Event Expression Unlike the other operators, FIRST only monitors the system for the first occurrence of an event. If you will, FIRST triggers a built-in deactivation mechanism once the event has occured. In this example we use the composite event expression from above. Whereas in the above eaxmple we are notified of all occurences where a person enters the kitchen and the lounge, in this example we are only notified of the first occurence of that event. Once the event has occurred the CES is deactivated. It will at most notify an event sink once.