Global Constant
Steve Nay's ramblings

Building a home automation system prototype

This is the first in a series about the home automation prototype system.

In my research lab, we’re developing a prototype of a home automation system that uses Kynetx to glue all the pieces together. The two main components of that system are things (devices) that raise events and things that respond to directives. Let’s take this example from Phil Windley:

One of the significant benefits of evented systems is that they exhibit extreme loose coupling. To understand this consider the situation where you want your DVD player to pause when you get a phone call. Assuming each has an API, programming your phone to send a "pause" command to the DVD is easy enough to do. Now suppose you decide you want to also raise the room lights when the phone call comes in; you have to program the phone to also send a "raise lights" command to the room lights. Each new interaction requires an explicit command from one system to another. Such point-to-point connections make changes difficult. Change out the DVD player and every device sending it commands has to be reprogrammed. Now, imagine instead that the phone merely raises a phone:inbound_call event. The DVD and lights can both listen for such events and do the right thing. Add something else to the mix and it can easily listen for the phone:inbound_call event and do whatever is right for it. Nothing else needs to be reprogrammed or even told its there as long as it can listen for events of interest. Each actor in the event-driven system interprets the event according to its own context and purpose. Loose coupling leads to better resilience in the face of errors and configuration mistakes.

(Phil also discusses this example here and here.)

To get that loose coupling, the devices raising the events must be thought of separately from those responding to events. The phone receives a call; it might raise that event over the home Wi-Fi connection, or it might do it over its 3G connection. The DVD player and lights that are listening for that event are sitting behind a proxy that can speak several protocols: it knows how to communicate with the dimmer and the DVD player (perhaps through a proprietary API, as Phil suggests), and it knows how to speak HTTP so it can raise events and receive directives from KNS. This is what it looks like:

A sample interaction:

  1. Cell phone receives an incoming call, raises the phone:incoming_call event to the home automation ruleset in KNS
  2. Ruleset has two rules that respond to phone:incoming_call event, which do the following things:
    • Send a set_media_state(“pause”) directive to the DVD player
    • Send a set_light_level(8) directive to the dimmer
  3. Those directives are routed over the Internet to the HTTP proxy for the home
  4. The proxy sends commands to the light dimmer and DVD player in their native protocols
  5. Dimmer and DVD player respond

The phone could also raise a phone:hung_up event to signal that the call had finished. When that happens, we restore the state of the DVD player and lights to what they were before, using the same process.

Here’s an example implementation in KRL for the ruleset responding to the events. I use several functions that communicate with the HTTP proxy; their details are not given here, but the behavior is self-explanatory. Also, the rules are using app variables to store the previous state of the DVD player and dimmer so they can be restored later.

Future posts will explain in more detail the connection between KRL and the HTTP proxy and how the HTTP proxy is implemented.