Antoine Savelkoul

The smart phone application I was talking about is of course eControl. I already told what eControl will do and I even posted some screenshots. But what distinguishes eControl from other home automation applications? I agree, it will not be it’s name.

It should be a year of 7 or 8 ago when I came up with the idea of a framework that should make it possible to synchronize object models between software applications running at different devices. While frameworks for synchronizing objects where also at that time not something new, my ideas went a little bit further by making it possible to define different kinds of behaviour like permissions at higher abstraction levels, load data via XML like documents and a self organizing network of connected nodes. However, also some other things got my attention like domain specific modeling and those ideas disappeared to the background.

When I started the development of software for controlling home automation systems, my ideas of synchronizing objects got a second life. What I wanted to create was software that collected all information from home automation devices in home and handles that information in a uniform way, making it easy to build user interfaces and other application on top of it. The design that resulted from there made it into a smart phone application I call eControl.

Many home automation systems work with a central device or server (also called Home Automation Gateway). All home automation devices in home will become registered on this central unit and smart clients will control them through this central unit. The central unit will function as a kind of translation device. To be able to controll devices from the Internet, the central unit will connect to a kind of forwarding service on Internet. The image below gives an impression of such a set-up.

Home Automation System Centralized

eControl however is designed in a way that it will be less depending on a central unit. Where possible, eControl will connect directly to devices in a self organizing way, making setup of a home automation system much easier. eControl will also make optimal use of services available with the smart phone, like cloud storage. In many cases, this will even take away the need for the end user to set up additional user accounts. The image below shows the same set-up with eControl.

Home Automation System with eControl

Of course, to profit from all these advantages, the home automation systems to connect with should also support discovery mechanisms and automatic port forwarding. Also some additional security precautions have to be taken and multiple data connection can have advantages but also disadvantages around data efficiency.

The architecture of eControl is also suitable to be used in other kinds of home automation software. A framework is already under development and will form the base of eControl. For the moment, only elements that are crucial for making eControl a functional application are implemented.

Maybe it’s time to show more about the projects I’m working on at night and in the weekends in relation to my ambitions. As many people know, I’m working on some applications for smart phones for controlling home automation equipment. What some of them know is that the real product behind these applications will be a framework for home automation software. This framework will allow home automation software to be extended easily with support for additional devices, protocols and cloud based services. What nobody (except for myself) knew till now is the real intention behind these projects, developing valuable assets that can be used to realize more ambitious projects.

My projects can be compared with a multistage rocket. To bring one project on a higher stage, it needs anther project to lift on. My home automation projects are projects that are needed to bring other projects of myself to a level they can be launched. From the first stage off launch, untill the last launch, the rocket will look like:

• Smart phone application for controlling home automation equipment
• Home automation framework
• Offering custom build home automation software at license base
• Automated software product line for home automation software
• Platform for creating automated software product lines
• Platform for automated software creation by using knowledge from expertise systems
• Automated software creation using AI algorithms

Each stage will result in it’s own products that are part of a much more ambitious vision. Unlike a multistage rocket I hope that jettisoned stages will grow further in a way that they will profit from the results of following stages instead of burning into the atmosphere. However, they are primarily meant to serve a higher purpose. For example the smart phone application will be build in a way that it can grow with the framework. Thereby, the smart phone application will influence the design of the framework. The framework will be designed in a way that it extensions can be made at minimal efforts, making costs more predictable and making it possible to offer custom build software at licence base. And this way it will go further.

The ultimate goal will be a situation in which programs (simple as well as complex) will be created from scratch without the involvement of software developers. This sounds like science fiction, but I really believe it will be possible. Of course it will take us many years to get there, but it will provide us with enough challenges for the next decades.

I will write a blog post about each of the stages. By doing this, I hope to get in touch with people who share my vision and also see opportunities.

Recently I build a prototype of a RGB-controller which can be controlled over a home network using eControl (a smartphone application I’m building for controlling home automation devices). The RGB-controller is based on an Arduino with network shield, which should proof that a ‘Internet of things’ with low cost devices is realizable right now.

The Arduino uses a ATmega328 which is a 8bit microcontroller with only 32KB of flash memory and running at a max of 16MHz. The ethernet shield is using a simple W5100 controller, which means that all TCP/IP protocol handling should be done by the micrcontroller. So I’m not cheating by using an ethernet controller with build in webserver.

To compare, the average home router (sold around 25 Euro) contains a 32bit microprocessor running over 100MHz and contains at least megabytes of flash. The average smart phone (sold around 200 Euro) comes is around1GHz containing gigabytes of Flash. For the people not knowing what I’m talking about, it will be hard to find cheaper hardware then the hardware I used for this prototype.

The prototype includes the following functionalities:

• Automatically obtaining an ip-adress from an home router using DHCP
• Advertising the device (making it detectable) using a online service connected to using DNS
• Simple HTTP server making it possible to smartphones, computers etc. to connect
• HSV like color cycling

And there is even enough memory left for applications like:

• The addition of an RF Transmitter making it possible to control for example wireless wall switches
• Running time schedules, scenes etc.
• Addition of climate sensors
• Addition of an IR-receiver

A YouTube movie will be created soon!

Best wishes and a happy 2012 to everyone!

My good intention for this year is to share more about my activities on code generation, home automation and mobile development. I would like to invite you all to follow me on Twitter @a_savelkoul and @ExtundoApps.

Today, April 1, I officially started my own (part-time) business. With Extundo Apps, I will focus myself on the development of software for home automation systems.

Within the next year, a number of applications for smart phones and tablets will be developed and released. Many of my ideas that are now just concepts will find their way to the world through these applications.

Thursday I went – together with my brother (Martin) – to an event on Home Automation (Beurs Domotica & Slim Wonen). On this event a number of installers and manufacturers of home automation equipment were represented. We used this opportunity to do some market research.
Most significant to realize, and what we knew before going to the event, is that the companies at the event focus mostly on the higher segment of the home automation market. Examples are Philips with their Pronto, Siemens with KNX hardware and a lot of manufactures of touch screen units.
Software solutions
We were mainly interested in manufacturers of software solutions. We talked to some of them which gave us a good indication of where the home automation market stands today. Some of the most remarkable things were the user interfaces. Some of them were so messy that we didn’t understand where all the buttons were meant for. Others were kept as generic as possible which made it difficult to distinguish features by importance and type. There were some more impressive ones, but they need to be configured by the installer. We think a lot of improvements are possible here.
Another significant thing is the support of systems of external parties. KNX is by far the most supported standard enabling manufacturer independent extendibility. Some companies will also support the X.10 which is popular in the lower segment of the market. Extensions to other systems like a/v equipment however are something that seems to have a lower priority. One system we saw had an integrated web radio, but this was limited to one party. If they supported DLNA, lots of other a/v applications would be possible as well.
The lower segment 

Within the lower segment of the market we find manufacturers like KlikAan-KlikUit and Marmitek (X.10). They also offer software, but these are very limited in functionality and often support only their own systems or single protocol. Their equipment however is affordable for a much larger audience. An example of not manufacturer specific software is HomeSeer, which offers extensibility through APIs. An advantage of the HomeSeer software is that is has a large community of enthusiastic peopele developing add-ins for even the more affordable equipment. However, the average computer user would not have enough experience with finding and configuring these extensions. So, where the price is the barrier to a large audience within the higher segment of the market, the complexity is the barrier for the lower.
Significant players in the future
I believe that sooner or later home automation will become as common as the telephone and internet access. A growing market that is related to home automation is that of the Smart Metering. Within the near future utility companies will roll out many electricity, water and gas meters that send ‘usage information’ to a central system. Each meter will have its own data connection. This data connection will however have a lot more potential. This is something companies like Microsoft and Google also realize. These data connections might become a new gate for them to deliver information based services. Smart meters might also contain communication interfaces to home automation systems, so this might also be an opportunity to them to get access to this part of your house to without the need of a home server or internet connection. And so there are many other examples of existing multinationals that might extend their market this way.
Conclusion
Home automation is a living and growing market with enough space for innovations. Complete solutions can been found within the higher market segment. To make these complete solutions accessible to the lower segment of the market, home automation systems will have to become less complex and the need of custom development and configuration needs to be taken away. At this moment a lot of innovations comes from small start-ups, but it would not be inconceivable that large companies like Microsoft and Google will enter the market soon.

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.

From the embedded prototyping systems I considered, the Arduino is one of the cheapest and the most popular ones. The combination with the ethernet shield will make it the perfect addition for my home automation project. This weekend I received the one that I have ordered online.
  

The ATmega328 microcontroller used by the Arduino includes a serial connection, PWM outputs, I2C bus, analog inputs and more. This will make it ideal for connecting my LCD TV, RGB Led lighting, climate sensors and other equipment to the network. Running simple macros on the controller will in some cases take away the need of a home server being on 24/7. It seems that I’m not far away from generating my first code for embedded devices.

In my previous posts I have given an impression of the current situation (how the hardware is connected, which software I use). It is very tempting to dig into hardware and software details now, but during previous experiences with designing DSLs I learned that this will be the wrong way.
During my Master’s thesis a few years ago I did an investigation at one of Netherlands major insurance companies. During this investigation, I designed a number of DSLs for the domain of medical statements. I did this in cooperation with domain experts. The methods I used were very promising. One of the methods I was inspired by is Interaction Design. A lot of papers and articles about designing DSLs will start with an analysis of the problem solution domain by discussing complete hardware designs and software architectures (including some of my own). However, I decided to have a look at the how medical statements were defined by medical advisors, evaluated by legal advisors and implemented by software developers. This resulted in a totally different design as I primarily had in mind. I also believe that the methods I used will create more efficient DSLs that will really decrease the time needed per project phase because it covers the most relevant business logic while representing the language of the business. Thereby, the created models can even be used to validate requirements with domain experts saving valuable time on writing documentation.For my home automation system, I will apply these successful methods as well. With the only exception, that the group of volunteers who can act as domain experts will be smaller this time. The next step will be to form a list of personas that will have an important part in the process of designing and using this system.
The personas are:

• Residents of the automated home (e.g. a family with kids or elderly people)
• Owner or maintainer of the home automation system (normally the person in house who also configures the thermostat and television set)
• The installer of the home automation system (might be a small company or the owner self)
• Equipment manufacturers who want to make their equipment compatible with my home automation system
• Hobbyists who want to create their own hardware for the system
• Hobbyists who want to add existing (not by the manufacturer supported) hardware to the system
• Manufacturers, retailers and hobbyists who want to design their own user interfaces for the system

In short (when writing an article about my project, I will give more details);

• The average residents just like to have an overview of the system, e.g. knowing where which equipment is located. They will not design their own system but at most define some simple macros.
• The installer of the system wants to be able to configure the system, e.g. how everything will be connected. They will also need the possibility to make some adjustments to the user interface and define some more complex macros.
• Equipment manufacturers and hobbyists who want to make their hardware compatible with the system need to create a software add-in. They need to be able to define what the capabilities of the hardware are, how they can be configured and implement the communication protocols. In the case of hardware that still has to be developed, the communication protocols might be even in scope for the design.
• Finally, some manufacturers, retailers and hobbyists might give their own touch and feel to the system by designing their own user interfaces.

These are a number of personas I have identified so far. For the first phase of my project I would like to limit my scope to the device side because without having them connected, other parts like customizable user interfaces will be useless. In one of my next blog posts I will show an initial design of my first DSL.Recommendation for reading:   

• Alan Cooper. The Inmates Are Running the Asylum.

The hardware that I have selected offers the functionality that I will need for this project. Unfortunately, this is not the case for all the software that was provided with the selected hardware. PlugWise is the only one providing software with webinterfaces and some kind of webservices. The other software is simply not focused on extensions to other type of systems.

The table will give an overview of the solutions chosen for the first prototypes of my home automation system.

The solutions that I haven chosen will raise the abstraction level and will make it easier to integrate them. In a next phase of my project, when the first DSL will be defined, I will give a more detailed look at the APIs.