Antoine Savelkoul

First designs for the home automation DSLs

When writing this post I realized how many design choices I have already made while designing the first prototype. Too much to blog about, so I will only discuss a few design choices I have made. Firstly, I would like to start with describing the domain of the first DSLs.

The first DSLs will be used to define the capabilities of devices that will be controlled by the home automation system. Examples of devices are light switches, dimmers, energy meters and the TV. It should not only be understandable by the designers of the devices, but also by its users. A high level description of the basic functionalities of a television might look like:

The television has a power button that can be used to turn the television on and of. Furthermore, the volume can be set to a variable level or muted on and off without losing the previous sound level. The user can switch between the sources "HDMI", "VGA", "Composite in" and the build in tuner. The tuner has some pre-sets the user can choose from.

 A visualization might result in an image like below:

From this drawing we nearly have a language, we only need to formalize it. A pseudo description of the language might look like:

• A device type has a name
• A device type has zero or more device functions
• A device function has a name
• A device function should be one of the following types:
• On / off
• Variable
• Fixed choice
• Dynamic choice 
• A fixed choice should have one or more pre defined options
• A variable should have a minimum and maximum level

A second DSL is used to describe how the devices will talk with the home automation system. My first observation was that, each device will receive commands through a transmitter unit or another connection. For example the light switches will receive signals from a transmitter and the television via a serial connection. But by defining it this way, each device implementation will depend on a specific transmitter or connection while, for example with the wireless light switches I have used, the user has the choice to use an original manufacturer's transmitter or one of RFXCOM. So, the original design was not completely in line with my goal to have a manufacturer independent solution.

However, I came up with the idea to include communication protocols so that a manufacturer independent solution is possible. These communication protocols can be best compared with web services. The DSL for the communication protocol will have some resemblance with for example the Web Service Software Factory.

Some simplified examples of two communication protocols within my home automation system: 

Wireless light switches

Request:

TV Serial Control

Request:

Response:

Parameters can have a "Is address" flag. This flag will be used to add configuration parameters when adding devices to the home automation system.

The last DSL I would like to discuss is the DSL used to assign the protocols to the devices. Within the image below we see how, by using the protocols, compatibility between devices can be modelled without creating direct dependencies.
 

One interesting scenario for this DSL is that it should be easy to work with multiple people on. There will be several ways on how the model will be created. People can assign self defined or existing protocols to devices they have defined, but might not interested in all the transmitters that are available or all devices that can be controlled by a specific transmitter. On the other hand, protocols might be designed to control specific type of devices. For the end user there is no difference between a light switch controlled using a wireless protocol or using Power Line Communication. So, how the model above will be created and visualized is still something to think about.

Some things that are not yet covered by the DSLs described in this blog post are:

• The translation of commands (protocol) to device functions
• The translation of commands to, for example, to a textual representation used for communication over a serial link

These will also be covered by the first DSL prototypes I am designing. As soon as I have built these prototypes I will make some parts of my project available for download.

For who is interested in other home automation DSLs too I can recommend the following interesting papers and blog posts of other people (thanks to Steven Kelly for providing some of the references):

• Online draft from Martin Fowler’s next book. His DSL is based on a state machine.
• Steven Kelly discussing the DSL of Martin Fowler
• The Making Of User-Interface Designer, A Proprietary DSM Tool and The Practice of Deploying DSM Report from a Japanese Appliance Maker Trenches by Laurent Safa.
• Chapter 7 of the Domain-Specific Modeling book from Steven Kelly and Juha-Pekka Tolvanen. See also the example on dsmforum.org.
• OSLO is running my house by Kris Horrocks.
• HAAIS DSL. You need a ACM account to download (unfortunately I don’t have such an account) and HAAIS DSL Presentation (free download). The domain of the DSL on page 25 has an overlap with the domain I described in this blog post.