HomeUX Documentation

HomeUX is an open-source home control software featuring a Silverlight-based touch screen user interface.

Note  Use of HomeUX is governed by the Microsoft Public License (Ms-PL) (http://homeux.codeplex.com/license).

This documentation is intended for technical hobbyists and/or software developers. HomeUX is a playground for home control development, and isn't intended to be deployed by consumers.

Page contents:

See also:

Introduction to HomeUX

HomeUX is software that provides a unified, touch screen based user interface for controlling equipment in a home. The "UX" in "HomeUX" means "user experience", which is a term that encompasses all aspects of how a user interacts with software.

User experience is the reason why HomeUX exists. It's not about "automating" your house (which is why I prefer the term "home control" to "home automation", though admittedly the two are basically synonyms). For example, the point isn't "turn on the coffee pot at 7AM". To be honest, the main reason HomeUX exists is in response to the proliferation of really bad user interfaces that exist in the home. Just look at the array of remote controls you need to control audio/video equipment, with lots of small buttons with tiny, inscrutable labels. Remote controls need to be the way they are because a better UX would be much more expensive. (In fact, one solution to the problem of bad remote control UI is to buy a good-quality touch screen-based remote control. That's a fine solution, and it solves part of the problem addressed by HomeUX, but it's not the solution presented here.)

Another example of a bad user interface: a typical thermostat that controls both heating and air conditioning. Perhaps the old mechanical interface was best: move a knob or lever to the temperature below which which the heat should turn on, and another to indicate the temperature above which the air conditioner should start. In contrast, many modern thermostats require you to press a "mode" button, then up/down buttons to adjust the first temperature, then "mode" again (quickly, because it will time out), then up/down again to adjust the second temperature. Often the same "mode" button also serves to change the operational mode of the system, e.g. AC-only or heat-only or both. Can you imagine modern professional computer software getting away with an interface like that? And there are many more examples.

Higher-end houses have an additional issue: lots of equipment to control. For example, a large "great room" (combination of living and dining room, and possibly kitchen) may have quite a few lights, and possibly motorized blinds, a raised/lowered TV or projection screen, a gas fireplace, etc. Each one of these can have its own button or knob, which has the advantage of simplicity, but it's inconvenient to run around a room pressing buttons, and nobody likes a couple of feet of wall switches. A better user experience organizes this functionality into logical groupings, perhaps arranged by task (e.g. "watching a movie") instead of by hardware function. (A partial solution is to use a system like Lutron® HomeWorks®—in fact I use such a system in conjuction with HomeUX. The Lutron hardware does the "heavy lifting" of lighting control, and the wall-mounted keypads work even when HomeUX doesn't.)

The HomeUX project was started by me (Rick Ledoux) as a way of experimenting with home control user experience. And it is an experiment: HomeUX is the second major version of software I wrote to control the house I had built in 1999, and I still consider it to be a prototype. In fact, I built my house, in large part, to be a prototyping platform for home control experimentation: I specifically selected many systems (lighting, HVAC, security, A/V, etc.) to be as computer-controllable as possible (e.g. via RS-232 serial ports). I recognize this isn't typical—home control more often uses hardware like X10® or INSTEON®—which are probably more practical, and definitely more economical), but I wanted to see what was possible if you push the boundaries a bit. (By the way, there's no reason HomeUX can't control X10 or INSTEON—but at the moment I don't use those system so I haven't written drivers.)

One key choice I made up-front was to use touch screens that are Windows®-based secondary monitors. This somewhat defies conventional wisdom—PCs are seen as complex systems that can fail too often, and reliability is key in home control—but on the other hand PCs are cheap and ubiquitous. I knew I'd have several PCs in my house anyway; attaching a secondary monitor for use as a HomeUX touch screen is pretty simple. And the tools and techologies available on Windows for developing user interfaces are top-notch. (Disclosure: I'm a Microsoft employee, and you won't see my biting the hand that feeds me. :-) However, HomeUX is a personal project.) When Silverlight 2 came along, it seemed ideal to me: one thing I'd learned from my earlier version of my software is that it's very helpful to be able to quickly access the home control software from any laptop in the house without complicated setup, and by building the UI in Silverlight it's as easy as navigating to a web page. (When run on a touch screen there's an additional small component that helps the UI runs full-screen on the correct monitor, even after a reboot. Surviving Windows Updates is a key requirement of HomeUX.) Also, I added encryption to the HomeUX client/protocol so that I should be able to securely control my home from anywhere on the web—but so far I've been too paranoid to open up a firewall port, except for brief testing.

So, how has my experience been with Windows PC reliability? Well, PCs do fail, but in truth I've found that fixing or replacing a PC—a true commodity—is a much simpler matter than fixing or replacing a custom proprietary piece of equipment. For example, I'm so fearful about my IR blaster failing—and then discovering that the company that makes it has gone out of business—that I bought a couple of spares (and they're not cheap). In comparison, I'm not worried that the PC platform will "go out of business".

Here's a simplified picture of how HomeUX is configured in my house:

What's in the picture:

HomeUX on CodePlex

HomeUX is available for download on CodePlex. I'm not currently looking for additional project contributors—HomeUX is published for these reasons:

  1. It's one example of how to do touch-screen UI in Silverlight. I figured it might be useful to share what I've learned so far. (Again, note that HomeUX currently doesn't exploit multi-touch features of Windows.)
  2. It shows one approach to home control. This is really a secondary goal for publishing HomeUX—I'm realistic enough to understand that home control is still a pretty niche application. And, in order for anyone to actually use HomeUX in their home, they'd almost certainly have to write new HomeUX drivers. That's a pretty big investment.

So, for anyone except me, HomeUX is basically just a big ol' sample app.

Currently, HomeUX is available in source code form only (except for a demo version on the companion web site, HomeUX.org). My assumption is that if you want to play with HomeUX you need to be a developer. Specifically, a C# developer.

Using HomeUX

In case you're one of the very few people who might want to build, install, and play with HomeUX yourself, here's what you need to know:

  1. Download the source code and build it. It currently requires Visual Studio 2008 and Silverlight 3.
  2. Update Server\App.config to reflect the hardware you're using. You may be able to use some of the existing HomeUX drivers but most likely you'll need to write your own&mdash. see the server code documentation**.
  3. The Client directory contains the sample HomeUX client. You should customize this to correspond to your hardware. See the client code documentation**.

** PLEASE NOTE!  HomeUX documentation is currently under construction, and many topics are still blank. I'm slowly filling in the documentation, over the next few months.

HomeUX Driver Collection

HomeUX has its own driver model. A HomeUX driver is a managed-code assembly that's loaded by the HomeUX Windows service (in user mode). See server code documentation for more information.

The following table lists the HomeUX drivers that are currently included in the HomeUX distribution. The "Simulator" column indicates if there is a hardware simulator available—a simulator is a library which behaves much like the real hardware (in many cases implementing a virtual serial port interface) but which doesn't control real hardware. (Simulators are useful for debugging and for demonstrating HomeUX user interface without requiring connection to real hardware.)

NOTE  In addition to the documentation currently being incomplete, I haven't even finished writing drivers for all my own equipment. The topics below (even the ones with incomplete documentation) reflect the drivers that are implemented so far.

Driver Name Description Simulator?
AggregatorDriver Under construction. No
AspDriver Controls one or more Sound Control Technologies ASP Audio Matrix 8x8 devices connected together to implement an N-input, N-output audio router. AspSimulator (in AspSimulator.dll) Yes
JdsDriver Under construction. Yes
LutronDriver Under construction. Yes
MusicPlayerDriver Under construction. Yes
SunfireDriver Under construction. Yes