(Last updated: April 17, 2011)
DollHouse Hardware Notes
In 2008 it was suggested to me that I should try to demonstrate my home automation in some way. I've tried the X10 module, a table lamp and a few other devices but the demonstration always left me wanting for something better. Somewhere along the way I got the idea to simply put together a small computer, a doll house, some electronics and lights to demonstrate automation (Misterhouse). Hence; Linux Doll House Automation (DollHouse). The Misterhouse version is a Perl based program used to demonstrate how automation should work. I intend to spend some time creating a new project with the same goals as Misterhouse but based on a modern OOP language, using Groovy perhaps. Also the entire system software needs to be geared more towards embedded systems. MisterHouse is very much geared towards PC with more resources (RAM, storage, a math coprocessor, etc.) available to the program.
Now jump forward to 2011, at the Trenton Computer Festival I present my most recent presentation on Smart Home Information Technology was a success though it did have it fair share of problems. The 2012 presentation will be much better as I intend to do much less talk and more interactive. At my friend's (D') suggestion we may also have remote access to a home with automation. :-)
To start with we need some goals. One of which is that the Doll House demonstrates actual home automation techniques. Access to the system should be through a web interface, command line and/or other devices (ie TV remotes). A true home automation system works without using the web interface but we're not there yet. Another goal is 'going green'. Wasting fewer resources would be a big plus. The Sheeva Plug handles this nicely. One of my laptops uses 22W, the Plug uses 4W with no drive and 8W with an external USB drive. Also the code has to be written such that it is fault tolerant (easier than it sounds). Finally it must be embedded systems based. This means a slightly different way of thinking when it comes to programming.
What I want:
I've grown up with home automation. Since the early 80's I've had X10 (Atari 800 and the Heath Kit X10 interface). I've read Byte magazine since 1982 and Steve Ciarcia's Circuit Cellar column and magazine. I've written my own software and run Misterhouse now. I now have X10, Insteon, Z-Wave and a variety of other devices. I think I've figured out what I need. I just hope I can figure out how to write the code and build the hardware. :-) So here's what I want (not necessarily all at once):
- Open Source - It's been my way for a long time. I want the majority of the system to be open source. The hardware can be proprietary but I want an open interface.
- Linux based main controller, I'm comfortable with the environment. The remotes can be custom firmware, maybe Contiki or even small embedded Linux too.
- Embedded! Meaning that this is not a system withe excessive RAM, storage or hourse power. Though a 1GHz ARM with 512M RAM and 4G SD doesn't exactly sound like low power (but 4W does :-).
- Web and CLI based - meaning that there is an easy to use web based interface and for the more complicated stuff a command line (like a cisco router, maybe Busybox).
- Support for smart devices such as the smart phones. Yes, it's all the hype but there's good reason. I have an iPod Touch and an Android phone so support won't be ignored.
- A small, low powered system - Green is in (and it saves me a buck too). Try to use as many low powered techniques as possible (hardware and software).
- Easy to work with and prototype language, Perl, Python and Java (with Groovy) fall into the category. We'll probably use assembly and C for the small micro-controller remotes).
- Must be modular (OOP methods help here) this will make it easy to add new hardware too.
- Extensible user language (either a DSL or mini user language). I'd like to see Groovy as the user language in addition to the main program's language
- Dynamic updates to running user code (this won't be easy)
- Minimal down time. I don't like rebooting things to make updates. I'll need to look into something like the OSGI frame work.
- access to system based utilities. I wrote a long time ago why not just access it via call to the system?
- plenty of libraries but not plenty of bagage. Java and Perl work here but the OSGI examples I've seen fail (231M for simple HA? Misterhouse uses a lot less)
- Easy access to the hardware (Windows is a major pain here, I much prefer the Unix method).
- Support for networks! TCP/IP, RS485, various wireless
- The ability to mirror the processor. This would allow for redundancy. My wife and I hate when the system needs to be rebooted but sometimes it's necessary.
- Support for cloud services/being a cloud service. This will be fun!
- Document the dang thing! One of my frustrations with Misterhouse is that the developer API is not really documented. Adding a new device is frustrating! User code is better documented.
Here are some of the devices I have on hand. I'm not sure what will make it into the presentation and what won't. For now here are the devices and my ideas.
- Greenleaf Doll Houses. The doll house has no special purpose other than to represent your home. I hope to paint the house in Victorian colors and then have a few decorations so that it looks a little like someone's home. I'll get my wife to help me as I have no decorating sense at all.
- Sheeva Plug computer - A nice small, 1GHz ARM processor with 512MB of RAM, 512MB of flash, 1 Gigabit Ethernet, 1 USB port, 1 SD flash card port and 1 USB console. Other models include additional USB, ESATA and/or an extra Gig-E port. This tiny computer is impressive in that it uses just 4W by itself. When teamed up with an external USB drive (500G) it uses 8W in total. Compare this to the 22W my laptop (1.7 GHz) uses or the 150W my main server uses. With a few changes to the software (ie MisterHouse) I should be able to get rid of the hard drive. The hard drive is only for storage of log files and data retention. If I can lower the frequency of the writes, I can instead just use the flash drives.
- Kill-a-watt - Actually the Tweet-a-watt - I intend on use this to monitor my "home's" power usage. The tweet-a-watt uses a Digi XBee to interface between the SheevaPlug and the Kill-a-watt. This makes it wireless. When setup in a multi-drop mode (one device polling the remotes and the remotes only responding when polled) more than one device can be monitored.
- Digi XBee - the wireless interface used on a USB for the PC and just the plain XBee board in the Tweet-a-watt project. I'll also have a few boards that either interface directly to electronics or another microcontroller (see below). This makes for a very nice wireless network. Now let us see how much pounding this network can take.
- Elexol Ether IO24 board. This is the device that directly controls the lights (LEDs) and buttons or switches. The reason I'm using this instead of X10, Insteon or Z-Wave is that it is a lot more portable than bringing lamps and switches. The Ethernet board allows for the devices to be further away than the USB cable limit of the USB IO board. The down side to this is the latency and a question of software debounce for push buttons. We'll see how this codes out.
- Elexol USB IO24R board. Like it's sibling, the Ether IO module, the USB IO will control LEDs and push buttons. The USB board has notification on change and a few other features not avaialble on the Ethernet version (such as SPI and 1 Wire support).
- A nice fan which will be used to emulate the HVAC. The heat cycle will have a red LED and the fan will run, the cool cycle will have a blue LED and the fan will run, the blower (not heating or cooling) will have a green LED. When it's off no LED will be lit. I'll need some way of adding a dial or slider to set the temperature.
- TI MSP430 - low powered microcontrollers (uC). And before anyone freaks out too much, yes I could also use Microchip uC or AVR uC or anyone else's chips. I just happen to have a dozen or so of the TI 2012s (16-bit Ultra-Low-Power Microcontroller, 2kB Flash, 128B RAM, 10-Bit SAR A/D, USI for SPI/I2C, 10 GPIO). Their purpose could be signal conditioning, or digital translation or something as simple as a timer with on/off capabilities (such as in a sprinkler system). The cool thing about these chips are that they are low parts count, easy to programs, flexible. If I were designing everything from scratch I wouldn't use these uCs as an after thought. I would design the functionality into the original product. At this time I'm not sure which uC I'd use. Instead I'm taking what I've got and fiting it to suite my needs. I also have a couple of TI 2013 RF boards that I need to spend some time with.
- LEDs - I'll be using these as lamps in the house different colors in different rooms. I'll have to experiment to see what works and what doesn't. Each color has a different power requirement and I'll need to work on that. Also I need to figure out a way to deal with dimming the LED. I've been asked a bit about dimming. This will probably require some form of PWM (hence one of my little uCs above).
- Android enabled phone - I can easily incorporate an Android App to make accessing DollHouse a lot easier. Of course I'll need to figure that part out when I get to it. :-) I've already found links that explain how to exchange JSON objects so that might make creating the App a little easier but we'll see. It would also be nice to have the Android phone tell DollHouse where it is. I have nothing against the iPhone it's just easier to write software for an SDK that I can just download and use. Pretty much everything you can do with Android you can do with the iPhone.
- Various input sensors - Push buttons, temperature sensors, photo-resistors, etc.
- X10, Insteon and/or Z-Wave - Yeah I know I said I that they're difficult to present with but you really can't leave the out of it. We'll see how I can work them into the presentation.