Call MisterHouse to Regulate Your Heat
There must be a failsafe at least to keep the pipes from freezing should the home automation system fail. I have no provisions for dealing with an extended loss of power during severely cold weather—very few modern heating systems will work without power. Even the failsafe will fail absent another source of power to drive the circulators and ignite the water heater in the event of a prolonged power failure. A failsafe is accomplished by wiring a traditional cheap thermostat in parallel with the home control system on a sufficient number of dispersed zones to maintain temperatures above freezing.
Feedback is more important than reliability—it is not important that a zone starts heating at a specific instant. It is important that over the course of time, the zone temperature does not wander too far outside the tolerance from the current setpoint for that zone. That tolerance is critical. Expecting to maintain a temperature of exactly 70°F in a zone all the time is unrealistic. Doing so would make the system turn on and off constantly. All environmental control systems have some tolerance built in. The primary difference in my system is that both the setpoint and the tolerance are controllable. Feedback is important in that it allowed me to use an extremely inexpensive means of controlling AC power: X10 appliance modules.
X10 is fairly ubiquitous. It is readily available and cheap. In a lot of installations, it is highly reliable, but some are highly troublesome. Feedback is also important because if all else fails, my heating system needs to attract my attention to solve the problem.
The controls and sensors need to be cost-effective devices easily interfaced to and managed by the home control computer—did I mention that I am cheap?
The X10 appliance modules to turn on and off AC power to the AC devices (circulators) that are being controlled are Dallas Semiconductor DS1820 1-Wire temperature sensors. These are extremely inexpensive and are an easily interfaced means to sense temperatures. Each zone may have one or more temperature sensors. Eventually, I intend to place sensors at different heights within the zones to explore the radiant heating premise that rooms with warm floors are perceived as warmer even if the room temperature higher up is cooler. Furthermore, I monitor the supply and return temperatures for each zone. This provides feedback, and it provides a means of monitoring system performance. The heat supplied to each zone is the differential between the supply and return temperature, the flow rate and the cycle time. The flow rate for the circulators is approximately constant, and all other factors can be monitored. This means the output and performance can be monitored in real time.
Finally, there is a need to determine human input—I need to be able to demand that my living room be hotter or colder. This is done in a number of ways.
For my first heating season, a single $10 US thermostat was used to turn on all circulators for all zones concurrently. At initial startup, the hot water heater started about a minute after the circulators and ran for about 17 hours straight. I was starting to panic, wondering how large a loan I would need to afford heat. Then it stopped. After that it became a game trying to catch the system running the rest of the winter. Once each zone was up to temperature, they very rarely ran.
During the second season, I used a simple MisterHouse Perl script. Changing a zone's setpoint involved simple changes to that Perl script. It worked, but it was not a human-friendly user interface.
Ordinary thermostats can be installed and connected to digital inputs. There are numerous ways to do this, and there are relatively cheap 1-Wire digital input sensors. The thermostats are not used to set the temperature; they are used as inputs to determine whether I want the temperature altered. I use these primarily because all users, regardless of their competence with computers, tend to be comfortable with and understand them, which is important in a guest room. However, because they are inputs to the control system, they constitute requests, not demands, and they are not a failsafe.
The user interface for the normal computer-savvy users (my wife and I) is an evolving Web interface with status and alterable settings for each zone. The Web interface can be used from any computer on the home net, from a wireless PDA supporting a Web browser or even from remote locations, provided sufficient security precautions are taken.
Nothing about an environmental control system is particularly time-sensitive. I develop embedded and sometimes real-time systems. Environmental control is not real time. This means the demands of the control software on the Linux system are relatively low and not particularly time-critical. In fact, in my home, the heat source for the radiant heat is shared by domestic hot water. This has advantages and disadvantages and is not permitted by some building codes. When domestic and heating demands exceed the capacity of the hot water heater, such as when someone is taking a hot shower, domestic needs trump those of heat. It is unlikely I will notice if the heat delays a few minutes before starting. But if I am in the shower, I will notice if I am deprived of hot water just so the heating cycle can start immediately.
The open-source MisterHouse Project provides a capable and highly programmable home control system, with capabilities well beyond those required for this project. It runs on Linux and Windows and supports a wide variety of controls, sensors and other hardware. It provides a very capable Web interface that I was able to extend easily to support my zone controls. And, it has features, such as floor plan integration, that I hope to take advantage of later. There already have been several environmental control systems implemented using MisterHouse. These have used expensive computer-monitorable thermostats controlling traditional HVAC control systems. In my implementation, MisterHouse does all the heavy lifting.
MisterHouse is written in Perl and has provisions to allow MisterHouse users to incorporate their own Perl routines easily, as well as an API with functions and events targeted at home control. It is fairly simple to create a bit of Perl code and have it execute every minute, every three minutes or only on Sundays when there is a full moon. It is easy to monitor or control 1-Wire and X10 devices—all the elements needed to make a working system.
I love programming in Perl, because it is easy, powerful and forgiving. You do not need to be a Perl monk to create custom scripts for MisterHouse. The MisterHouse distribution and Web site include numerous examples, many of which are only a few lines of fairly simple code. A substantial amount of home control can be accomplished with MisterHouse without doing any programming at all.
I primarily used Debian Linux, and I created a Linux Vserver (lightweight virtual server), specifically for MisterHouse. This is not strictly necessary, but it is cheaper and easier than a dedicated machine, and it's simpler and cleaner than running a mess of different dæmons on a single machine. I highly recommend Vservers; they make experimenting with configurations fun and easy.
MisterHouse can be installed under Debian with apt:
apt-get install misterhouse
It requires a collection of Perl modules, and these dependencies should be taken care of by apt.
While planning this system, I decided on a computer X10 interface, the ACT TI-103, specifically because the most common X10 interfaces, the CM17 and CM11, have been known to have issues. The TI-103 sends a stronger than normal X10 signal and can receive a weaker than spec X10 signal. Furthermore, it supports X10 extended addressing, allowing the use of more than 255 X10 devices in a single home. Unfortunately, I mistakenly assumed that there would be MisterHouse support for it.
For early development, I used an old CM11 I had lying around, but eventually, I wrote a new MisterHouse driver for the ACT TI-103 that is now part of the MisterHouse Project. The ACT TI-103 is a nice controller and was easy enough to talk to—with some effort you can manipulate it directly using minicom as it uses ASCII command strings. Developing the TI-103 driver was more complex and time consuming than the rest of my MisterHouse HVAC software. So far, it has not proven to be any more or less reliable than the CM11. But, my TI-103 driver has been part of MisterHouse distributions since MisterHouse 1.102. After I was well underway with this effort, Insteon came out with a new series of power-line devices that are superior in many ways to X10 devices. However, they are still more expensive than X10 modules. Neil Cherry should have MisterHouse support for Insteon completed by the time this article is published.
MisterHouse needs to be configured for the controllers and sensors. The X10 controller is set by assigning the correct port, such as /dev/ttyS0, to the correct X10 device in the MisterHouse configuration file /etc/misterhouse/mh.ini:
cm11 = /dev/ttyS0
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Secure Server Deployments in Hostile Territory, Part II
- Hacking a Safe with Bash
- KDE Reveals Plasma Mobile
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python