Satter Ramblings

Scenario Builder

Source of Activities

Using Visual Studio 2005 will make H.A.S. pretty easy to build however one key feature is pretty tough, a scenario builder. Fortunately, for us Microsoft has solved that problem and it will come free in future versions of Windows.

Microsoft has been working on a set of foundations for programming called WinFX. It includes managed APIs for Presentation, File System, Communication, Idenitity Management and Workflow. It is this last item Windows Workflow Foundation (WF) that will be a huge boon to H.A.S.

The workflow component contains a workflow engine and even an XML file format called XOML for creating new workflows on the fly. This is huge because one of the problems with home automation systems is that every system is unique from the equipment, wiring, even how the occupants want to use the system. No one is smart enough to figure out everything that a user would want or how they will use the system. With WF that is no longer required. WF will allow H.A.S. to be a collection of components and services bound together using XOML.

Once H.A.S. is deployed the integrator can use XOML to create new scenarios that the user can execute. This is accomplished by picking a type of workflow and building it using Visual Studio.

To test this out I built a couple of test activities to control Premise. If you don't have Premise you can download a 30 day trial from Motorola's Premise site. You will also need the Windows Workflow Foundation from Microsoft and Visual Studio 2005. I am not going to regurgitate an introduction, Microsoft does a great job. Instead, I will show you a quick hello world version using Premise’s MiniBroker. The source can be found here.

Step one is building a Workflow Activity Library once you have installed WF. This will house various activities. The other project to build in the solution is a Sequential Workflow Console Application to test the activities.

To start the library I built a base activity that the get and set activities can inherit. This will enable a single connection to the server for the workflow if it executes all at once. In addition, since checking the connection status it should detect if the minibroker should reconnect (although do not count on this, I believe the status is actual broken).

The next part is writing the get and set activity execute methods. Nothing magically just use the minibroker get and set value method after finding the object. You can use the object path or guid. The property value is a string since Premise will make sure to do the type conversion for you. You will notice in the sample code that I overrode the property value in the get activity. This was so I could mark the property as read only in the property inspector. The last part was to create a validator to minimize the errors in the activities.

To test the activities just build a workflow in the test application. I used localhost and changed a light power state from on to off. I also grab the value and publish it to the console.

Using WF you can easy integrate Premise into a variety of tasks that require access to outside applications, services, or even interactions with people. If you use it drop me a line (rsatter at hageeks dot com).

Tools of the Trade

I am now going to break a core rule when building a system. I am going to pick a tool before I have written my use cases. I can get away with it since I have written a complete home automation system. However, as a rule even then I would rather focus on features, feature sets and use cases before formulating architecture and choosing technology.

So what technologies and tools should be used to build an automation system that could handle a home like this? Let’s review the salient facts:

• Reliable


• Performant


• Dynamic User Interface


• Multiple Control Systems


• Extensible

Now a lot of people would say use LAMP (Linux, Apache, MySQL, and PHP). After all Linux architecture is cheap and reliable. The problem in my opinion is the development tools suck. And well PHP may be great for web pages but as a control system we need something a little faster. That leaves a couple of options Java or .Net.

Now you might say how neither one is going to be performant enough. However, I would say that either is more than fast enough. In fact, the devices are the limiting factor not the PC or a PC based control system.

Here is a real life example. The system I did for Intuitive Homes was written to run on Win2k backend with various clients including XP touch panels. The architecture originally was Flash front end talking to a socket server written in C#. The socket server translated commands from Flash into web service calls and forwarded any status changes to the Flash client.

Click image to enlarge.

To turn a light from a touch panel:

1. Touch Button


2. Flash builds command to turn off light


3. Flash Sends command and now ready to accept new command


4. Socket Server receives command


5. Socket Server interprets command


6. Makes call to web service


7. Web method figures out what control system adapter to pass actual method implementation


8. Premise adapter gets light using MiniBroker


9. Premise adapter tells light to turn off


10. Premise script sees light change and build message for MSMQ


11. Premise script sends message to MSMQ


12. MSMQ Router reads new message


13. MSMQ Router puts message on event log queue and socket server queue


14. MSMQ at its leisure reads the event log queue and posts event into database


15. Socket Server receives message from queue


16. Interprets message header and sends message to subscribed clients


17. Flash client receives message and changes light state to on or off

Without going into too much detail that is a lot of code and communication going on. This occurs within a second. In fact some subsystems could not process commands as fast as we could spew them out. So for example using Lutron HomeWorks and RadioRA the lights across a retrofitted home took almost a minute to turn completely off due to command latency across 4 RadioRA systems. That is a lot of light!

So my point is most modern semi-compiled languages (Java, C#, VB.Net and VB) are going to be more than fast enough. I would give the advantage to C# and VB.Net since you can pre-JIT the code. So there is no performance hit for JITing.

In addition, the new version of .Net (2.0) with language extensions like generics and improved performance makes it ideal. Add on top of that Visual Studio which has to be the most productive IDE I have used and HAS can be built fairly quickly.

Another item to look at is Flash. I would replace it. With today’s browser improvements and AJAX the notion of a completely dynamic runtime UI is possible. The UI renders will send a tailored UI that runs in the browser making Web Service calls using HTTPClient. This will allow for a dynamic low resource demands on the server without the need to write a custom socket server which could be a source of failure. IIS is pretty robust after years of development. In addition with Atlas coming out and AJAX.Net available it should be much easier to write a UI since Flash is really not a programming tool.

And if you do not think Windows is reliable then use Mono and Linux. So with .Net I get the best of all worlds: productive IDE, reliable modern language and framework, and cross platform support.

Target Home

Another thing we need before we look at tools is the target system. This article describes a medium sized system without going overboard.

The biggest concern for HAS is reliability and performance. In a home scalability of users is not an issue. I just do not know of a home with 100s much less 1000s of residents. On the device side the largest home we did was 48k sq/ft with at most several dozen control systems or subsystems. These subsystems then controlled several hundred devices. All in all the bandwidth usage was minimal. A smaller home (3k – 5k sq/ft) like my own would consist of at most 50-75 devices including counting each individual electrical load.

Let’s take a look at a typical family home. According to National Associate of Home Builders for 2004 the average was 2,349 sq/ft for a new single family home. In addition, over a third of new homes have more than 2400 sq/ft and 4 or more bedrooms. So our hypothetical home will be a 4 bedroom home. It will contain:

• 4 bedrooms


• Master Suite


• 2 kids room


• Guest room


• 2 1/2 bathrooms


• Kitchen


• Living Room


• Dining Room


• Den/Media Room


• Patio


• Pool

The devices and subsystems to control:

• 2 zone HVAC


• 35 light loads


• 8 zone audio including the outside


• Master Suite


• 2 kids room


• Guest room


• Kitchen


• Living Room


• Dining Room


• Den/Media Room


• Patio


• 4 zones of video


• Master Suite


• 2 kids room


• Guest room


• Den/Media Room


• Matrix Switch w/volume control


• A/V Receiver for Den/Media Room (9th audio zone and 5th video zone)


• Radio Tuner


• DVD/CD Player


• 4 MP3 Players (Roku, Windows Media Player, iPod type device)


• 2 Video Players (Roku or Windows Media Extenders type device)


• 2 Satellites w/PVR


• Pool pump


• Sprinkler system


• 2 video cameras (front door and backyard)


• Security System


• InWall touch panel at the front hall


• RF/IR remotes for the den/media room, and 4 bedrooms


• Control System either PC based or hardware based like Crestron or AMX

This is a pretty complete setup for most people. You could go crazy adding addition things like weather station, water sensors, etc but for now it makes a reasonable target.

Home Automation Servers

With news that my old employer would be completely changing its software strategy, essentially abandoning it in favor of a proprietary system from Crestron, I have decided to share my experience from the work I did. This will take the form of an open source home automation server, a.k.a. HAS.

The main goal of HAS is to provide end-users with dynamic room and home control based on the user’s device and security level. This is very important in my view. Home-owners, occupants and guests should have varying levels of control. So for an example a guest should be able to control the room they are in with their iPaq. For example, I can get up and turn off the lights in the room. So, I should be able to remotely turn off those lights. The same is true for the A/V system. However, the home owner certainly would not want me to control other rooms that I could not reach nor should I be able to access the security or HVAC system. In addition, the homeowner might allow them to play MP3s but probably would not want to give the ability to create a permanent play list or order a movie from MovieLink.

Another item to consider is that control could be across multiple systems. Not because of the end user, rather because the system should support multiple vendors including Crestron, Premise, and others. This is so that the software can be used by dealers to support their clients.

This brings us to the most crucial feature reliable, fast device control. The system must work and work at the speed of a light switch, i.e. you flip the light switch and the lights go on or off immediately and with no discernable delay.

If I was prioritize the list it would be ordered as follows:

1. Reliable – works without fail
2. Fast – performance must be
   1. sub second response times in device control
   2. sub second response time for device status
   3. Reasonably fast for informational display i.e. retrieval of room display, list of lights, media library, etc.
3. Multiple control system – the system should support major control systems and be able to add new ones rapidly
4. Security – the system should give appropriate control to the user preferable by role i.e. house guest, baby sitter, children, homeowner, etc.
5. Dynamic – the system should present a user interface dynamically based on security, device and location.
6. Extensible – the system should be easy to extend to new devices and services.

With this in mind I have put together an architecture that should get HAS the ability to accomplish my vision.

Click image to enlarge.

Below is a rough architecture. It is broken into several layers:

• Presentation – this layer is responsible for providing a user interface for a client device based on the services that are available to that client device and user.
• Services – this layer is composed of various services available
  • A/V – control of audio and video components and media libraries
  • Electrical – control of lights, ceiling fans, pumps
  • Climate – control of HVAC, refrigeration, saunas
  • Security – control of both computer and physical security systems
  • System – information about the home and system
• Logical – this layer provides a consistent API to control devices independent of the actual control mechanism. In addition, the information about the home is stored at this layer
• Physical – this layer provides the actual device dependent control. The architecture of the logical and physical layers is similar to ADO.Net. The programmer only learns the logical interfaces. The physical layer is implemented for a specific database for example MS SQL or Oracle.

The idea is as follows:

1. The device sends a request for a UI
2. The UI sends the appropriate UI based on the device type, location, and user access control level
3. The user can then use that UI to control various functions like lights, A/V, etc.

The key point to this system is that the user gets a UI that is appropriate for the device location, and who they are. So for example, I walk into the home and go to the front hallway touch panel. Touching the panel, I see a room control for the entrance way and front living room. The system knew what to display because it knows that the device is an embedded touch panel in the front entrance. If I want more control I can touch a button for more control. At that point the panel will request that I identify myself. Based on my response it will unlock more functionality, like the ability to control another area, or see all the thermostats.

This is just one way the system can be architected. The next part will be on what tool to use for building the system.