Home Automation System (to rule them all!)

Lots of circuit boards form OSHPark, read to be soldered into awesome.

This proof of concept transceiver will be modularly constructed, with a backplane (pictured at lower right), and a plethora of modules (pictured at left) that will be inserted into edge connectors on the backplane. Once I have decided on a transceiver design, I will make a compact and inexpensive module that can be used with an Arduino, AVR, PIC, ARM, or most other embedded microcontrollers. Pictured at top right is a simple junction box that will be used to connect multiple devices together.

We want to provide a system that is extensible enough to include anything and everything that can be manipulated by electomechanical contraptions. While most interaction with the automated devices will be done through simple reading and writing of blocks of data, each device's descriptor will contain the information needed by the master node to identify the device and how to communicate with it. So far, we have a large and growing list of device classes that can be used not only for this project, but for future development as well, both by us and by the community:

- Lamps (colored or white with color temperature, brightness)

- Occupancy sensors (motion sensors, entry/exit sensors, anything that can detect a person or a movement)

- User input devices (switches, sliders, buttons, touch/touchless controls)

- User feedback devices (lights, buzzers, alphanumerical and graphical displays)

- HVAC control and detectors for smoke, CO2, radon, etc.

- Smart outlets

- Physical access (doors, locks, windows, intrusion detection, access control devices)

- Clock, alarm clock (can be integrated with occupancy sensors)

- Home entertainment integration (your music or video can follow you as you move through the house)

- Security camera or video conferencing device

- Plant watering and monitoring devices

- Doorbell notification

- Automatic pet feeding devices

- Kitchen appliances that can be both automated and unplugged for safety when the kitchen is not in use

- Collecting personal fitness, exercise, or other biometric data

In addition to the device classes we are defining, which can be used by anyone, we are also reserving a private use space in the protocol that will work similarly to 192.168.x.x and 10.x.x.x in the IP address space. This will allow anyone to develop their own device classes to be used in their automation system without conflicting with any future standardized devices.

Here's another pretty picture (and i use the term "pretty" loosely...)

The top diagram shows two bus masters and a web gateway attached to the control network. This control network can be an existing Ethernet or WiFi network, powerline, RS485, or any other network that the master nodes can use to communicate with each other. Each master node drives a network of inexpensive nodes that provide lighting, occupancy information, user interaction, or anything our community develops to control electromechanical contraptions. To the right, the web gateway then connects all of this to a browser or phone app that the user can use to access it. Another option would be an application that can communicate with the maser nodes directly over Ethernet.

One possible candidate for the master node is the Raspberry Pi. This was selected for its mainsream use and ability to bridge the gap between full-featured, scriptable operating systems and embedded hardware like Arduino. The lower diagram shows a Raspberry Pi connected to the control network using Ethernet, and a network of device nodes. An API will be developed to store device information in a database-like format than can be accessed by user scripts, web applications, or the infinite cominations of infinitely diverse products of our users' immaginations.

So this horrid jumble of wires was one of my first attempts at developing the low level protocol.

At top right is a Teensy 2.0 acting as the master node, controlling a set of ATTINY2313 slave nodes. One has an IR motion sensor, and another has transistors switching red, green, blue, and white LEDs being used as place-holders for the high current LED drivers of a light fixture. The communication protocol has gone through several iterations since I wired up this hardware, so it's back to the drawing board now...