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:

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:

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.