Welcome!

Hello, and Welcome to Dwell.Net. This is a personal Web site I set up so I could share my home control software with others. (The software published on this site is free, and source code is available—click here for details.)

Here's an overview of the site:

This page introduces me and paints a bit of a background picture.
Home Control Software is where I publish home control software. There's not much there right now since I'm still working on my "big new project", DnHost (see below), but I though it would look dumb to have an empty Home Control Software section of a Web site devoted to home control software, so I posted a simple X10 component in case it's useful to anyone. More to come...
Utility Software is where I publish software not related to home control. (I'm too lazy to set up a separate site.)
Code Sharing / Terms of Use contains the legal stuff, including the Dwell.Net Software License that you need to agree to if you want to use software published on this Web site.

About Me

Let me start by introducing myself. I'm Eric Ledoux, a professional software developer since the late 1980s. I live in Bellevue, Washington. I spend too much time working with computers. Home control software (often called home automation software) has been a hobby of mine for most of that time. I started by dusting off my old Radio Shack TRS-80 Model 100 and writing a silly BASIC program that blinked an bright LED (turned on using the machine's cassette recorder relay) to remind me to water the plants or take the garbage out. Yes, I'm a true computer geek. :-)

Sometimes, Simple is Better

Home control can take many forms—and it doesn't need to involve a computer. For example, you may own a coffee maker that lets you set a time, such as 7:00 AM, at which it will turn itself on and make coffee. (I find it amusing that "turning on the coffee pot" was a commonly-cited example of early PC-based home control software, when in fact this is true overkill: Why would I want to fill my coffee maker with water and coffee, and then walk to some other device (such as a PC) to set the startup time? Although, I'll admit I like the idea of one less clock to set in the house... Anyway, my own coffee maker is "configured" to turn on when I press the "On" button.)

When I lived in a condo a few years back, I experienced another simple example of home control that doesn't involve a computer. I noticed that every night after work I'd walk into the living room and turn on a pair of table lamps. I liked the lamps, but their switches were annoying to reach, and I had to walk through a dark room to get them since the builder didn't bother to install switched outlets. The solution was simple, and it involved a cheap and common technology called X10. X10 uses standard house wiring to transmit commands, such as "turn light on", from a controller to a device module. You can also transmit an X10 command from a wireless controller; the matching receiver, plugged into a wall outlet, relays the command through house wiring. In my case, I bought a pair of lamp modules (for controlling lamps), a wireless receiver, and a wireless transmitter that was simply affixed to the wall with double-sided foam tape. Not terribly sophisticated, but it got the job done: I could press a button at the doorway to my living room to turn the lights on or off. Of course, in that case it would have been even better to have a good old-fashioned hard-wired wall switch—that was an example of using technology to work around a dumb non-technical problem.

That simple X10 solution allowed me to turn on the living room lights without knocking my shin on the coffee table. Then I could sit, get comfortable, and watch some TV. Since I often worked late, I recorded most of my TV shows on videotape (this was the 1990's, before TiVo). That required sorting through my array of remote controls to turn on the amplifier, set it to receive from the VCR, turn on the TV, set it to receive from the VCR, turn on the VCR, and start it playing. I eventually bought a "universal remote control" to reduce the number of remotes on my coffee table. That's another example of home control that doesn't involve a computer.

Universal remote controls help reduce clutter, but there's still a basic problem: the user interface for controlling home equipment is often terrible. Despite the amazing technology we have, if we want to watch TV using an A/V system we still need to turn on multiple pieces of equipment (e.g. TV, amplifier, TiVo) and configure them using inconsistent user interfaces and terminology (e.g. what's called "Source 2" on your TV might be labeled "S-Video Out" on your DVR). That's like having to configure your car each morning, pressing one button to select the "brake output" for the "left pedal" and another button to assign "accelerator" to the "right pedal". There are several logical reasons for the complexity of A/V equipment, of course: An obvious one is that you're hooking up equipment made by different, and competing, manufacturers. Another is more subtle: why can't you tell, by looking at your remote control, whether your TV is set to Video 1 or Video 2? Because that would require an indicator on the remote control that would make it more expensive and reduce battery life. And, if you have a way of of switching video sources from the TV itself, the remote control would have to receive that information as well—further increasing the cost and reducing reliability (what if the transmission fails?) A/V equipment manufacturers have a lot of constraints to work within.

Rocket Science

So, what would the "perfect world" user interface for A/V equipment control look like? A few of my thoughts and opinions:

How about a speech UI? I could tell my entertainment system: "Watch Battlestar Galactica." (Oops, my true geek colors show again. I don't care, I love that show.) That would be cool. Obviously the TV and amplifier would turn on automatically and all the video and audio sources would be switched correctly. And the voice recognition would be high quality: speaker independent, capable of asking for corrections or clarifications, capable of distinguishing commands from conversation. It's not perfect, of course; for example, what if you have three episodes of "Battlestar Galactica" on your DVR? It could say, "which episode?". I might reply, "well, I don't know... which episodes are there?". Maybe it will start reading off the titles, or descriptions, or dates... but then maybe I'd interrupt and say "wait, just tell me the episodes that aren't reruns". Maybe it would be better to have voice input coupled with a video display of all the episodes—I can read, or at least scan a screen, much faster than the home control system can speak to me. Then maybe I'd say "number three" or something like that.
How about a touch screen? There are various touch screen devices available today; some are basically just fancy remote controls that don't receive status from the A/V equipment, others are integrated into high-end proprietary home control systems. What I'd look for in a touch screen is one that's task-oriented, or at least can operate in that mode. If I want to watch TV, show me information related to the tasks I want to do: view a list of available TV programs recorded on my DVR, switch the room lighting so it's appropriate for watching TV (including lowering blinds if the sun is coming in at an angle that would cause glare), pause playback, control volume, etc. Again, of course, the details of powering up specific pieces of equipment, setting sources, etc. should be taken care of automatically. Although voice control seems inherently cooler to me, touch screens have a few practical advantages: they're more reliable, at least today (speech recognition is getting much better, but it's far from perfect), and a touch screen has better discoverability: a visual display can show you what your choices are more quickly than having them spoken to you. (My cell phone has excellent voice recognition, but you have to remember to say "lookup Sue Ledoux"—if you say "find Sue Ledoux" it doesn't know what you mean. Knowing to say "lookup" is a discoverability problem.)

"Home Control"? "Home Automation"?

You may notice that I use the term "home control" more than the term "home automation". The reason is that I think the core problem and opportunity is related to finding ways to make common tasks easier, and, perhaps, new tasks possible. My new house has a Lutron lighting system, and by pressing a button on a wall keypad as I leave the house all the lights turn off. That's simple, and pretty darn useful—it's a big house, and, being lazy, I'd be more likely to leave a light on than to run around the house and turn them all off. But it doesn't feel like anything "automatic" is going on. "Automatic" would be my house knowing that I'm leaving for work and turning off the lights for me. (In the condo I used to live in I experimented crude home automation: when I entered the house, I'd cross an infrared light beam in the hallway that caused my typical evening lights to turn on. When I left I'd press an "All Lights Off" button, located on the other side of the beam so I wouldn turn trip the beam again. Simple but clever, I thought, except too often I'd find myself stepping over the light beam because, I wanted to pass by (e.g. to go to the garage or mailbox) without turning on any lights. Perhaps the solution was too clever, or not clever enough; either way it was dismantled before too long.) Anyway, to me (for now, anyway), it's all about controlling my home, not "automating" it. Having said that, I have nothing against the term "home automation", and I frequently find myself using it as a synonym for "home control".

Rationalizing My Hobby

So, I'm interested in home control. Aren't there lots of off-the-shelf technologies that solve home control problems? Definitely! And many of them are very good. Why don't I just use them? First, I should say that some of them I do use: for example, as I mentioned above, my house has Lutron lighting system which provides all sorts of functionality on its own (as well as reducing the number of ugly light switches I'd otherwise have). But I didn't buy an off-the-shelf touch-screen-based (or other UI) system for several reasons:

Those systems are proprietary. Nothing inherently wrong with that I suppose, but I worry about being locked into a specific manufacturer's hardware and then they go under. This is particularly worrisome for the various small but very innovative vendors. Part of the problem is simply due to the fact that home control hardware is currently a pretty small market, at least compared to the market for much of the other stuff in your home (lighting, home A/V, etc.)
Existing systems all have limitations. Of course they do—that's to be be expected. But, since they're proprietary, they don't always interoperate well with other systems that could "fill the gaps". This problem is exacerbated by the fact that there aren't many interconnection and intercommuncation standards in the home control industry, and the few existing standards don't seem to have much traction.
Hardware gets obsolete quickly. In my new house I specifically avoided putting LCD displays on my walls—I was certain they would feel "dated" very quickly, and it's difficult to swap out hard-wired equipment like that.
Finally, and perhaps most importantly, I'm a tinkerer at heart, and since home control is interesting to me I have an urge to "do it my way", and see if I can create some cool technology myself.

Wire, Wire, Everywhere

So, I decided to put together my own home control system. To be more specific, I decided to write my own home control software—I'm not a hardware engineer, and in fact an early criterion of my system was to be able to work with off-the-shelf parts. While I think there is plenty of room for innovation on the hardware side, custom hardware is expensive, and if it breaks it can take a long time to fix or replace. With home control, reliability is very important.

The next decision I had to make: what hardware toplogy to use? There are many possibilities; for example (and these are not all mutually exclusive):

A central computer with cables running to each piece of equipment to be controlled and each input device (e.g. touch screen).
Several computers throughout the house, each controlling nearby devices.
A central computer running back-end software, with "satellite" computers running front-end touch-screen software.

In the end I chose a variant of the last topology, as follows, for my own home:

Early on I decided it would be simplest for a single computer to be the "central hub" of my home control system: it would keep track of the state of all equipment and all requests (e.g. turn on TV). In fact, any computer in the house can play that role—there's nothing special about the PC I normally use for this purpose.

Whenever possible, for the equipment I intended to control with my software, I chose equipment with a serial port interface. (I was surprised to find out that quite a lot of equipment, especially higher-end A/V equipment, has a serial port, specifically to allow it to be connected to a home control system.) The "central hub" computer communicates with that equipment over a standard serial cable (RS-232)—but, rather than running serial cable throughout the house, I used a pair of ethernet serial hubs. These devices plug into an Ethernet network on one side and a number of serial devices on the other side; the serial devices appear as local serial ports (e.g. "COM17") on the remote computer.

For equipment I couldn't control with a serial port, I used an infrared transmitter, which converts serial port commands into IR commands. The equipment thinks it's being controlled using an IR remote control. (The downsides of IR control: (a) it's not as reliable as as serial control, and (b) there's no way to get equipment status back to the computer.)

I decided I wanted a few touch screens set up throughout the house—I'd write my own touch screen user interface software. Taking advantage of the fact that I had several PCs scattered around the house for use as normal PCs, I added a secondary monitor to each to use as a touch screen. (The touch screens are regular LCD montors that have a touch-sensitive surface, just like many cash registers and ATMs. When the screen is touched, the PC is notified of the coordinates via a serial port interface.) The touch screens I use tend to be smaller than the regular screens (to make them stand out less in a living space—who wants a 19" monitor beside their TV chair?), and in some cases they are placed 15 or 20 feet away from the PC (using high-quality VGA cable—mine runs through conduit in the floor). The idea is that my software runs on the secondary monitor at all times, separate from whatever may be running on the primary monitor. (Of course some applications, especially games, can disable the secondary monitor while they're running. That's fine with me.)

By the way, I can't claim credit for hooking up all the hardware in my house. Although I think it's perfectly reasonable for a hobbyist to be able to set up a home control system, in my case I had too much equipment and too little time. I hired a local company, WireWays, which later merged to become part of a larger company, Home Technologies (no, I'm not affiliated with them). While it would have been fun to do it all myself, I must admit it was helpful to have professional installers handling the hardware side of things. And, when something breaks, it's good to have someone to call.

A Non-Controversial Topic

The next decision I needed to make: what operating system to use? Mainstream? Embedded? Open-source? In the end, my hardware topology (above) called for a desktop operating system, and since I use Windows for everyday PC tasks I clearly needed to use Windows for the touch-screen software. What about the back-end "central hub" computer? I chose Windows for that as well. Why not Linux and Java? Or Macintosh, for that matter? For me, in all honesty, it mostly boiled down to "you use what you know". Although my early programming exerperience was on Unix systems (primarily in university), and I've used Linux on several Web sites I run, I can't claim to have any real expertise in Linux, so I won't try to compare it with Windows. (I'll leave that religious debate to others.) Java is great, though my knowledge is a bit stale (I used it professionally a few years back, but only for a short time) and I wasn't a huge fan of the Java programming tools at the time. In any case, as a professional software developer I use Windows-based developer tools in my "day job", so it was natural for me to choose them for my personal home control projects. I will say that the newest .NET technologies are very cool—I love C# and the .NET Framework, and WinFX is shaping up to be a very powerful foundation to build on.

"My House Crashed... Again..."

Earlier I pointed out that with home control, reliability is very important. So, is a Windows-based system reliable enough? I ran the first generation of my software for five years (more on that below), and I can say that Windows itself was rarely a problem, though of course running touch screen software on a machine that's also used for Internet browsing means a higher chance of downloading a virus that will kill the machine you run that touch screen on. Bigger sources of reliability problems:

I have a lot of hardware (see the diagram above), and bits and pieces of it will fail from time to time. My first-generation software wasn't always robust enough to deal with that: small hardware failures sometimes caused larger software failures.
I get many power outage where I live, especially during the winter, and I've found that equipment that's rebooting after a blackout or brownout doesn't always recover gracefully. My first-generation software didn't deal well with that very well. Good learning experience.
Running a PC 24/7 puts a lot of strain on it. (One good thing about using a ubiquitous operating system is that if the machine dies it's not hard to find new hardware and set up the operating system again.)

My goal isn't a home control system that's as reliable as a good old-fashioned light switch—I don't think that's realistic, at least not yet. My reliability goals are a bit less aggressive:

No bugs during normal operations (e.g. watching TV).
Behaves well during manual reboots (i.e. I restart Windows).
Behaves well during reboots caused by Microsoft Update.
Usually behaves well during reboots caused by a power failure or equipment failure (e.g. Lutron serial port breaks). At worst, I manually restart my software. (I expect reliability in this department to increase over time, as I learn more about what happens "when good hardware goes bad".)
If a machine running my "central hub" software or touch screen software dies, it should be easy to set up my sofware on another PC.

Beyond Turn-of-the-Century Software

Above, I mentioned my "first generation software". That software, called DnCmd, was written in C++ using COM and custom prototocols to communicate between the "central hub" computer and the touch screen PCs. I wrote DnCmd in 1999 and 2000, and it's been use in my house ever since. Using the experiences I gained being a guinea pig with DnCmd, I'm now writing entirely new home control software, DnHost, based on Windows Communication Foundation (WCF) for inter-machine communication and Windows Presentation Foundation (WPF) for touch screen UI. The key lessons I learned from DnCmd are:

Never block. All commands should run asynchronously. Blocking causes performance problems; for example, my audio switcher takes up to a second or more to increment the volume level. That may not seem like a long time, but when you use the touch screen every day it really gets old. (A better design: I press and hold "Volume Up", and at some point it stops trying to increment the volume and instead waits and then sets it to a new absolute value.) Also undesirable: if the touch screen blocks on a back-end task, and that back-end task fails, the software ends up in an unplanned state that's difficult to predict and hard to debug.
Expect failure. All hardware components will fail. DnCmd simply didn't account for failure well enough. I think a large part of this will be fixed by running commands asynchronously: if you call a function asynchronously, it's more likely that your code will handle the case in which the function never returns.
Use C#. It's much easier to write reliable code in a managed-code environment. (DnCmd has a bug in it, somewhere, probably a race condition of some kind, that causes the DnCmd service to hang in certain rare situations. One such situation was almost amusing: it turned out that one of my Lutron keypads wasn't grounded correctly, so about once a week it sent spurious signals indicating that the level of a light changed several times in a fraction of a second. That triggered the DnCmd bug, and the system crashed. I only realized the nature of the bug after several months, when the Lutron problem increased in frequency to about once per minute and it became easier to diagnose. That particular problem would be less likely (though not impossible) in a managed-code environment with a solid communication foundation like WCF.)

I'm hoping to get key parts of my new home control software, DnHost, up and running by the end of 2006. (This isn't my day job, and I intend to "do it right" rather than "do it fast", so it won't happen overnight.)

It's All About Sharing

During the process of designing and building DnHost, I've found myself, like most software developers, frequently learning from others who post on the Internet. It started my thinking: maybe I should do the same? When I started using "DwellNet" and "Dwell.Net" as a moniker for all my home control work, I purchased several domain names, including "dwell.net". My "dwell.net" site was never really used for much, so I turned it into this code sharing Web site. And now, you're here. Welcome!

Dwell.Net contains software in both compiled (executable) and source code form. If you want to use this software, you need to agree to the terms of the Dwell.Net Software License. Take a look—I think you'll agree it's a pretty reasonable license.

So, what's can you expect to find on Dwell.Net?

Cm11 is simple X10 interface sofware that lets you write a C# or Visual Basic program to control lights and other devices using X10. Eventually it will likely serve a secondary role—a "hardware driver" for DnHost—but my goal is to always allow it to work in "standalone mode", without DnHost.
When DnHost is ready I'll post it. (I won't be posting my first-generation home control software, DnSvc. I'll stick with shiny new .NET-based C# code.)
CodeDoc is the tool I used to compile documentation for this site—see below. While it's not related to home control, I published CodeDoc anyway in case it's useful to others.

One relatively unique characteristic of Dwell.Net (I think) is the way I've published my source code. The CodeDoc tool described above turns C# code into a mini Web site complete with formatted source code (with C# XML comments converted to embedded "documentation blocks") and a table of contents and index. Each "project" published on Dwell.Net can be browsed online or downloaded for offline usage.

Contacting Me

If you have any comments—or bug reports—please email me. (Please be patient if I don't reply right away—this is a hobby, and my day job takes most of my time.)

Thanks!

--Eric Ledoux

July 2006