CHAPTER 6 ■ DATA SOURCES
213
In Chapter 7, you’ll learn how Minerva supports even more complex actions by sending a status
message to different places, according to whether you are at home, at work, or on the train.
Occasional Control with At
In addition to the periodic events, you will often want to invoke extra events, such as a reminder in ten
minutes to check on the cooking. Again, Linux is prepared with the at command, such as the following:
echo "say default Check on dinner" | at now + 10 minutes
This syntax is necessary because, by default, at accepts the commands interactively from the
command line (finishing with a Ctrl+D). Every at event goes into a queue, enabling complete recipes to
be produced for multipart events.
Alas, this example works fine in its current scenario but has a fatal issue for tasks requiring finer
granularity since the scheduler works only with whole minutes, meaning that a task for “now + 1
minute” actually means “at the start of the next minute,” which might be only five seconds away! So, you
need to employ the “sleeping seconds” trick:
echo "sleep `date +%S`; say default Check on dinner" | at now + 10 minutes
It is also possible to use at to trigger events at a specific time:
echo "say default Time for CSI" | at 21:00
This always takes place when that time is next reached, meaning it could be on the following day.
Error Handling
In any development, reporting and handling the errors are the most time-consuming parts of the
project. HA is, unfortunately, no different. You have some things in your favor, primarily that you’re in
control of the house and (most of) the other software running on the machine, so you can work out in
advance if there are likely to be problems. But if you send a text message to your video, for example, you
have no way of knowing whether the command worked or where in the chain it failed. There are three
rules here:
• Always acknowledge commands and requests.
• Always reply using the same medium.
• Always log the replies into a local file and optionally send them by e-mail.
The second one is probably the nonobvious one. If someone sends a command by SMS, then the
reply should also go back to SMS, even if it’s more costly. This is because the sender is using SMS for a
reason—maybe they don’t have access to e-mail or the web site has broken—so they’ll only be reassured
of its delivery by the same route. Certainly, it’s acceptable for the message to ask that replies are sent
elsewhere, but the default should take the same route.
This rule applies at every stage in the pipeline. So, in a chain of SMS to e-mail to IR, if the IR unit has
a failure, then the script that invoked it (and is processing the e-mail) must pass that error back in an e-
mail. At this point, the SMS to e-mail gateway picks up an e-mail–based error and passes it to the end
user as an SMS.
CHAPTER 6 ■ DATA SOURCES
214
An adaptation of the ideas in HTTP are useful here, where you adopt a three-part response to every
request in the form of number, argument, description:
• The number is a numeric code describing the result of the operation. Use 200 for
OK, perhaps, along with the various error codes for “device not found,” “disk full,”
and so on. This means that on the lowest-bandwidth devices, you will get an error
that is descriptive enough to start diagnostics.
• The argument covers the specific device or unit involved.
• The description contains a device-specific error, which should not repeat any
information pertaining to the error number or the device name (since they’re
already present).
Since the size and format of the various error messages will be unknown to everyone in the chain,
this layout ensures a unified view of the system and means that a custom formatting script is able to
prepare the information for the target medium, maybe by including full descriptions of the numeric
error code, or maybe it will crop the description text on SMS and tweet messages.
Conclusion
There are essentially two phases to data processing in a smart automated home. The first is the
collection, usually by screen scraping, RSS feeds, or API access, to provide a copy of some remote data
on your local machine. This can either occur when you request it, such as the case for train departure
times, or when you download it ahead of time and cache it, as you saw with the weather forecasts and TV
schedules. The second phase is the processing, where the data is converted into something more usable
such as a short, spoken, weather report or a list of CD tracks that can be clicked to play that track. You
learned about a wide variety of different data formats, including private calendars and public news
feeds. All are available to the geek with a little time to spend. As I mentioned in the introduction to the
chapter, content is king and is a great stepping stone to making it appear that your computer can think
for itself and improve your living.
C H A P T E R 7
■ ■ ■
215
Control Hubs
Bringing It All Together
Most people are interested in features and benefits, not the minutia of code. Unfortunately, the barrier
to entry in home automation is quite high, since basic features require a lot of underlying work. The
comparatively simple process of being able to e-mail your video at video@myhome.com requires preparing
a DNS record, e-mail server, message parser, network functionality, and IR transmission. Now, however,
you have these individual components and can look at combining them into processes and features and
abstracting them so they can be upgraded or changed without breaking the home’s functionality as it
stands.
Integration of Technologies
As I’ve mentioned previously, your home technology is based around Node0—or, more specifically, a
Linux machine based in a central location that performs all the processing and thinking tasks. This is
your single point of failure in several ways. Most obviously, it means you lack media control or playback
when the machine is offline or broken. Being Linux, this is fortunately a rare occurrence. But it is the
standard security model of Linux itself that makes it the most vulnerable. Ironic, huh?
Linux provides access to every file and device1 through a three-stage set of permissions: user, group,
and other. Additionally, each file can be designated ownership by one user and group. This is normally
enough control for standard files and documents, but in HA you are controlling devices that are used by
several different systems. Audio in /dev/dsp, for example, is used for MP3 playback, speech synthesis,
and the soundtrack of a movie playing. It is easy to see from this how several programs and users should
be allowed to use the audio device to report errors through speech but not be allowed to control the
whole house audio system. Similarly, the use of the serial port to back up a mobile phone SIM over
Bluetooth needs different permissions when the same port is used for reprogramming an Arduino or
sending IR signals. Unfortunately, there is not a fine enough granularity of control because the only
genuine protection is offered by the operating system. And because of that, you can only restrict access
to the devices as a whole. You can’t even limit access to software since you could simply write the MP3
1 Since every device is also a file.
CHAPTER 7 ■ CONTROL HUBS
216
playback script (or rebuild the package from source in a local directory) and run it as any user to avoid
any restriction placed on the software. Again, you are limited to whatever access rights you place on the
device file.
■ Note Some distributions, such as SELinux, provide explicit access rights for each program that allow this level
of fine control. It is time-consuming to set up, however.
Our solution, as it has been throughout the book, is to ignore the problem! There are two
components to this. In the first instance, you simplify the situation by creating only a minimum of local
users on the Linux box, preferably one, and add only the primary users to a group called homecontrol, for
example. You can then apply permissions for this group to each of your devices. When you allow control
to this device through a web or SMS interface then, naturally those daemons must also be added to the
group so that they have access to the device.
■ Note Remember that most daemons, like Apache, need to be restarted after any changes to group membership
are applied.
The secondary part of the solution involves, as it always does, the knowledge that anyone in the
house has both a level of physical access and a level of social coercion that prevents them from abusing
the system as others might do.
Both of these, in the given scenario, are acceptable trade-offs between security and ease of use. After
all, most other family members are unlikely to be using the server directly and instead through an
interface (such as a phone or the Web) where security can be applied.
The Teakettle: An Example
When discussing my home automation system to people, one topic that always comes up is that of my
online electric teakettle. Its functionality includes the ability to initiate a boil from a web page or
command line and have a fresh cup ready the second I get home from work. From a hardware level, this
requires nothing more than a basic pair of X10 modules—a CM11 from which the computer sends the
message and an appliance module like the AM12 to control power to the teakettle—but the subtleties are
in the software and attention to detail.
■ Note In all cases, the teakettle must be always switched on and plugged into the AM12. Furthermore, there
must always be water in the teakettle to stop it from boiling dry.
CHAPTER 7 ■ CONTROL HUBS
217
Making a cuppa from the Web is the same as triggering one from the command line or anywhere
else. Namely, there is a basic trio of commands:
• “Switch on”
• “Wait”
• “Switch off”
Traditionally you might implement a script for this like this:
heyu turn kettle on
sleep 215
heyu turn kettle off
And it works! This script can be triggered from anywhere, at any time, to provide the necessary
function. Naturally, if it is executed directly from a script on a web page, the page will take 215 seconds
to return and will usually have timed out, so it should be run in the background:
shell_exec("/usr/local/minerva/bin/kettle &");
The next subtlety comes from the configurability of the teakettle itself. Each has its own peculiarities
with regard to boiling times, so you create a configuration file for your home indicating the X10 address
of each teakettle and its respective boiling time.2 This is then processed by the main kettle script. I use a
configuration script like this:
#!/bin/bash
DEVICE=$1
CMD=$2
# DEVICE here refers to a particular kettle, for those that need
# to differentiate between one in the bedroom, and kitchen.
if [ "$CMD" == "time" ]; then
# report the number of seconds the kettle takes to boil
echo 215
fi
if [ "$CMD" == "device" ]; then
# the x10 device
echo e3
fi
2 The boiling time of most kettles shortens when there is less water, so empirically test the boil time with a full
teakettle.