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:

• The touch screens I use are actually usually sold as point-of-sale terminals. (The trick was finding small, cleanly designed units that look good in a residence.) These are just LCD screens with a resistive touch itnerface. (These aren't multi-touch, though I've tested with a Windows 7 multi-touch laptop and it works.) For the most part, touching the screen is equivalent to clicking with a mouse. Of course, from a software perspective, "touch UI" and "mouse UI" need to be completely different to be successful—that was a key design principle of HomeUX.
• The client PCs aren't dedicated to HomeUX; I just connect touch screens to existing PCs. In fact, one of the client PCs also doubles as the server PC.
• All client PCs communicate with a single server PC over the home network. The server runs the HomeUX Windows service, which keeps track of the global state of the system and is responsible for communicating with controlled equipment. The server PC doesn't need to be particularly special hardware; in my case I've used Windows Server 2003, Windows Vista, and Windows 7 as servers at various times. In fact, it's a good idea to set up a second machine (perhaps just one of the clients) that can be used as a HomeUX server if the first machine fails. (Fail-over is currently manual, but all you have to do is start the HomeUX service on the second machine.) To keep configuration simple, IIS isn't required—I use HttpListener instead.
• HomeUX includes separate music server software, which is basically a wrapper around Media Player. The server software runs either as a tray icon or a Windows service; it plays music through an external amplifier. When used with the corresponding music client components, you can choose music to play using a touch screen. The music server software can run on the same computer as the HomeUX server, or even a client.
• Much of the equipment in my house was purchased specifically because it could be controlled by a computer, and the ubiquitous interface is RS-232. It's not convenient to require the the equipment be placed within RS-232 cable range of the HomeUX server; more precisely, I don't want to require that the server be in a specific location (see the comment about fail-over above). So, I use a couple of "serial hubs", each of which have an Ethernet port plus a number of serial ports; the server connects to the hubs over the network. I place the hubs near the equipment to be controlled—in my case, that's two locations (my mechanical room and my A/V closet).

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.

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 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