The Siegel Family

Das Solarhäusle - Home Automation System


Entry photo example

During the design process for our active and passive solar home, we quickly realized that the sheer control aspects of all the features we wanted exceeded the capability of existing control systems. The design called for 14 zones, each with its own thermostat and hygrostat (to prevent condensation on the cooling ceilings), actuators for radiant floors and ceilings, as well as a total of 27 sliding shutters. Then there is the ventilation system and solar collectors to be controlled. Nice to have items, like keypads for entry, control for lighting and essentials like the security system with motion detectors, glass break sensors etc. added further complexity. A review of all commercially available systems revealed that none of them would cover all these ascpects in an integrated fashion. This is when I decided to develop a network based home automation system from scratch, the design of which is outlined here. It is based on embedded automation modules (Nodes) that communicate with each other over a CAN Bus network running CANOpen software stacks - with a central server running Linux and LabVIEW implementing all of the software modules that require user interaction. All setting adjustments and user interaction happen through Nokia Web Pads or regular PCs and Laptops with a web browser interface. For details, read on.

Network Hardware Design Descisions

Given the size of the house and the number of different components, a traditional centralized system with wiring home runs from each item to be controlled was ruled out from the beginning. This leaves two choices, one is a wireless network, the other a wire based network. While wireless is all the rage these days, in my opinion it is severely hampered by the fact that we yet have to invent wireless power supplies. Thus, I started looking into wired networks, the most popular of which is of course Ethernet these days. The problem is, that this is again a home run type system (from each component to a router or switch), and relatively expensive to implement in terms of hardware components. Software wise, it also puts a high demand on resources in terms of memory and CPU power - I was looking for a simpler solution and found it with the CAN Bus. Two wires and a ground, daisy chain, cheap silicon from many suppliers, any node can communicate with any other node (without a bus master), proven and tested for decades, and ultra reliable - what else can you ask for. The bus length is limited based on the bus speed, for our home I picked 125kBps which allows for up at least 500m (1500ft) of bus length. On this length of wire, up to 112 nodes can be connected to the network. If that is not enough, one can always install more than one network - our house was designed with two individual CAN bus networks.

Network Software Design Descisions

With the CAN bus selected as the bus medium, one can choose to use a number of diffrent software prototocols to run on the bus. The most straightforward choice seems to be to develop one's own message transmission standard - but I did not feel up to this task which is somewhat like reinventing the wheel (since there are nice protocols available) and possibly winding up with a flat tire in the process. Instead, I picked CANOpen as the network protocol, which has the advantage of being non-proprietary and reasonably well documented. Historically, one would have to shelve out a small fortune for the source code of an implementation of this protocol to run on a small embedded CPU. However, thanks to the hard work of Janez Paternoster, a LGPL licensed CANOpen stack is available from sourceforge. Beyond the stack, the distribution comes with an excellent tutorial that allows you to plug together a couple of nodes on a breadboard, program them and see them talk CANOpen over the CAN Bus. While you can potentially recompile the C source code for any embedded CPU, it is set up for the Microchip PIC 18Fxx8x family of controllers. These also happen to be among the smallest and cheapest CPUs that have the resources in terms of flash and ram to run a CANOpen stack. Microchip supplies their C compiler free of charge (with some optimization feature limitations) - thus you can write the entire software with no cash investment whatsoever.

Node Hardware Design

While I love tinkering with electronic circuits, I had to limit myself as much as possible in terms of circuit complexity within this project. If you are planning to hand solder hundreds of home automation nodes during weekends and evenings, there better be a relatively finite amount of parts in each. With this in mind, I set out and designed a basic embedded node that features nothing more than the CPU with crystal, the CAN bus interface chip, and a switch mode DC-DC power converter. All of this fits on one side of a double sided PCB. The other side can either hold six pushbutton switches and three LEDs, which make it a drop in replacement for a wall mounted toggle switch (or rather three of these). If, on the other hand, you fit it with a thermistor, humidity and light sensor, you have a network based thermostat. In either case it fits into a typical wall mounted single gang switch rough-in box, and can get further functionality with an additional small daughter board. Add a daughter board with 2 relais and you have a wall mounted switch that can control two AC or DC loads up to 240V / 8A. Either operate it from the pushbutton switches, or send it a command over the net to apply or remove power from the loads. This is the CANOpen version of a traditional light switch. For details on the different nodes that I designed, use the links on the right top of this page.

PC based Controllers and Web Interface

All of the home automation nodes do not feature any user interface to speak of - no display, mouse or keyboard. At most, they feature a few switches and LEDs. In order to accomplish configuration of the Nodes, which is done over the CAN bus, a PC running Linux is employed. A PCI CAN bus interface card connects the CAN Network(s) to the PC. Software wise, one of the easiest ways to design elaborate user interfaces that communicate with data acquisition, networking, and hardware that I know of is National Instruments LabVIEW. The LabVIEW software has three main components: The CANOpen Message router handles all CAN bus traffic, and provides an API for all other software modules. It also monitors the node activity and restarts nodes if they stop communicating. The CANOpen Network user interface allows for configuration of all nodes in terms of internal software settings. The third part of the software is a variable number of Home Automation controllers. These use the API to communicate with the nodes, e.g. send and receive messages. An easy to understand exanmple of a controller would be the so called Zone Controller. It handles all HVAC zones into which the house is divided, where each zone has a thermostat and a number of radiant heating and cooling loop valve actuators. While in a conventional system the thermostat will activate the heating valve actuator directly if the temperature drops below the set value, in the CANOpen based system the thermostat will merely send temperature updates at a regular interval. The zone controller compares these to the set point (adjustable through the web interface), and sends a command to the node controlling the heating valve actuator one the temperature drops too far. The advantage of this setup is that a newer fancier controller can be implemented without reconfiguring any of the home automation nodes - all it takes is a new zone controller software module on the PC. This makes system upgrades easy, as the Zone controller is entirely independent from all the other software modules. It can, however, interact with other controllers - for example, it will trigger the shutter controller to close sliding shutters on sides of the house that are exposed to the sun when the radiant cooling system is active.

In Summary

A home automation system based on the components described here is currently running our house. While only a small subset of the nodes and functionality were there when we moved in, the system is currently still being expanded in terms of nodes and functionality. This is made possible by the fact that nodes can be hot plugged, and all network wires being in place before the walls were closed off. The CAN bus CAT 5 cable is in every single switch rough-in box looped through, and all it takes to install a node is stripping of the insulation and attaching a connector. We have about 80 nodes online on two CAN bus networks; and a total of 7 controllers run everything from a weather station to the solar collectors. The main piece still to be implemented is replacement of the regular light switches with CAN bus enabled ones. Since this was the least pressing item, it got pushed back in favor of more important things - like heating and cooling of the house. All of this despite the fact that the very first CANOpen nodes that I wired up on a breadboard were predecessors of the current version of the simple network connected switch.

Update: The home automation system has been published on circuit cellar! A two part article in the May and June 2010 issues features the home automation system described here.

Posted by Stefan on May 9th, 2009. Updated August 1st, 2010
Tags: CAN Bus, CANOpen, PIC, home automation, Linux, Labview

How to get in touch

In this day and age of email spam, we let you do the email address composition. Since you have found this home page, you know the domain name. You can reach each of us by our first name (all lower case letters) before the @ sign. That would be, all of us who are able to read and write :-). But, of course there also are the old fashioned ways of communication:

By phone:

(++1) 719-545-7835

Or snail mail:

1111 Lavender Way

Pueblo, CO 81001, USA