Home Automation System (to rule them all!)

Open automation system, starting with lights and occupancy sensing and expanding to encompass anything that has wires or electrical contacts

Similar projects worth following
Open automation system, starting with lights and occupancy sensing and expanding to encompass anything that can be automated. Key requirements will be an open architecture to allow expansion and general hacking by the community, inexpensive components to lower the cost of creating an automation network, ease of integration with inexpensive and lightweight platforms like Arduino, and extensibility to support devices requiring higher data rates and more advanced capabilities.

This project was created to address a number of issues found with most commercial automation products. They include being focused on a single problem (e.g., lights, or security), closed architectures that prevent customization, inflexible in terms of connection type (WiFi vs. XBee vs. Ethernet vs. etc...), and centralized control (which can be less reliable and more difficult to modify).

This project will describe a basic home automation system with an open architecture that will allow users to hack, customize, and improve it. In our experience it is difficult to find this capability in current automation products. The architecture will be as device agnostic as possible. This means that it won't be centered around solving a specific problem like lighting or security. It will include features like negotiable data rates, plug-and-play style device discovery, and detailed device descriptors that allow master nodes to programmatically assess each device's capabilities.

A two-layer networking architecture will be used. The first layer will be a wired bus-style network that will provide connectivity between simple and inexpensive nodes. This network will be designed to integrate easily with common embedded systems such as Arduino. Power and data will be provided on the same cable making device installation simple. Multi-master support will allow multiple controllers on the same bus for redundancy and to provide modularity. Ideally a popular SoC type solution, such as the Raspberry Pi, would be used as a master node. It would provide a gateway to higher level protocols such as HTTP and allow users to write custom scripts or software to meet their individual needs.

The second layer will be built to function over existing infrastructure, such as Ethernet, WiFi, XBee, powerline, etc. and provide connectivity between master nodes on separate buses. This also helps in cases where a wired bus cannot conveniently reach a device (e.g., installing smart lighting in an existing home). This layer will be as infrastructure agnostic as possible, giving the user the flexibility to choose a connection that fits. It will also be peer-to-peer; each device or master node can function independently eliminating the single point of failure common to many current automation systems.

We want to define an open, standardized, and extensible architecture with accompanying API for connecting any device that can be automated to the system. We will also provide a fully functional and open set of example implementations for such a system.

  • I Can Has Boards?

    The Hat08/21/2014 at 04:38 0 comments

    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.

  • All the Things

    The Hat08/21/2014 at 04:15 1 comment

    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.

  • Architecture is for Architects...

    The Hat08/21/2014 at 03:30 0 comments

    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.

  • Redesign is a recursive process...still looking for the base case...

    The Hat08/20/2014 at 23:32 0 comments

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

View all 4 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates