CHAPTER 7 ■ CONTROL HUBS
238
SCRIPT cosmic1 on :: /usr/local/minerva/bin/mixer default dec master 10
SCRIPT cosmic1 off :: /usr/local/minerva/bin/mixer default inc master 10
SCRIPT cosmic2 on :: /usr/local/minerva/bin/mixer default toggle
SCRIPT cosmic2 off :: /usr/local/minerva/bin/pmedia default
Remember that these commands will be executed by whichever user invoked heyu engine initially.
They must therefore have appropriate access rights to the audio output and mixer devices for this to
work.
■ Note You always affect the master volume, not the individual device volumes. This is so the relative volumes of
the radio, CD, or MP3s aren’t changed, and the only inaccuracy occurs at the top and bottom of a single range—
that of the master volume.
The state-based controller is a little more involved. It consists of four predefined buttons to query
and change the state and eight that are mode-specific. This is configured as follows:
SCRIPT cosmic7 on :: /usr/local/minerva/bin/cosmic default modestatus
SCRIPT cosmic7 off :: /usr/local/minerva/bin/cosmic default nextmode
SCRIPT cosmic8 on :: /usr/local/minerva/bin/vstatus
SCRIPT cosmic8 off :: /usr/local/minerva/bin/cosmic default clear
Notice that you cycle through the modes in only one direction because this sequence is easier to
remember. Also, you have used what would have been a previous button to reset Cosmic to its initial
state. The modestatus report reminds you where you are in the cycle, lest you forget, and there’s a
general-purpose status report to even up the rows.
This assignment is specific to devices laid out in two columns like the HR10, which have the on
button on the left. This allows you to line up both status reports on the left side and separate the two sets
of global buttons into media at the top and Cosmic state at the bottom. Notice that the software within
Linux never changes, only the configuration.
To control the Cosmic system, you assign the remaining buttons to arbitrary c1, c2, and so on,
commands.
SCRIPT cosmic3 on :: /usr/local/minerva/bin/cosmic default c1
SCRIPT cosmic3 off :: /usr/local/minerva/bin/cosmic default c2
SCRIPT cosmic4 on :: /usr/local/minerva/bin/cosmic default c3
SCRIPT cosmic4 off :: /usr/local/minerva/bin/cosmic default c4
SCRIPT cosmic5 on :: /usr/local/minerva/bin/cosmic default c5
SCRIPT cosmic5 off :: /usr/local/minerva/bin/cosmic default c6
SCRIPT cosmic6 on :: /usr/local/minerva/bin/cosmic default c7
SCRIPT cosmic6 off :: /usr/local/minerva/bin/cosmic default c8
As you can see, the cosmic script is technically stateless, so you must use the /var/log/minerva/
cosmic directory to hold the current mode.
CHAPTER 7 ■ CONTROL HUBS
239
■ Note Since the heyu daemon needs to be restarted after any change to x10.conf, you can improve the
maintenance aspect of this script by redirecting all Cosmic scripts to an indirect form, through the invocation of a
script such as /usr/local/minerva/bin/cosmic default base1.
Creating Modes
You then have the fun (!?) part of designing the states and their interfaces. The Cosmic system places no
limits on the number of modes possible or how the commands inside them must function. However, it is
recommended that every button press result in some kind of feedback, either directly because
something happened as a consequence of the command (such as a light turning on or some music
playing) or indirectly with auditory feedback to indicate the command happened, although it was
invisible to you.
Each mode exists in its own directory, numbered sequentially, from $MINBASE/etc/cosmic/0. This
holds all the files necessary to control that mode. It includes the following files:
name: A text file with the mode name. This is read aloud when you cycle to the
mode.
status: A script that writes the status report for this mode to STDOUT. In the
case of a multimedia mode, it would be the currently playing song, for example.
This is read out at the end of each mode status report. If no file exists, the mode
name is simply reread.
c1, c2, c3, c4, c5, c6, c7, c8: These eight files are the scripts that are executed
when any of the eight corresponding command buttons are pressed. By
running scripts in this way, you can change the system without reprogramming
the x10.conf file or restarting the daemon.
All of the main work is done in those eight c1–c8 scripts. There are three sample subsystems in
Minerva: media control for the CD player, a set of status reports, and a set of timers. This latter mode
uses the wireless controller to begin timing a set period, such as five minutes. Once the time is up, the
voice announces its completion, with several timers able to be run concurrently.
■ Tip The output from all c1–c8 scripts should be written to STDOUT. In this way, you can debug Cosmic
configurations much more quickly (and easily) by changing the code in Cosmic to read REPORT=/bin/echo.
Web Applets
For most people, controlling the house through the web browser is the secondary goal (after voice
recognition, that is!). As I mentioned in Chapter 5, this is the ubiquitous means of communication in
20th and 21st centuries, so you are obliged to provide access to all the Bearskin commands through such
an interface, hidden behind the security that SSL and usernames and passwords provide.
CHAPTER 7 ■ CONTROL HUBS
240
At the simplest level, you can build your own site to provide a list of links that execute the Bearskin
commands on the server. But the web provides a richer canvas with which to work and can be used to
present house-friendly features that the existing commands do not provide.
In addition to controlling your home from a desktop PC or laptop, you might want to consider the
purchase of new machine(s) to be used as kiosks or house terminals. These can be in the form of a tablet
PC, mobile phone, or a home-brew machine with a touchscreen monitor and miniature form-factor PCs
(like the Fit-PC2 or Mini-ITX machines discussed in Chapter 4). This machine can be power-cycled
according to your waking hours and set up with a small and fast version of Linux, such as Webconverger
mentioned in Chapter 3. Having one in the kitchen, for example, would allow you to read recipes from
the Web, while the use of a touchscreen (as opposed to a keyboard and mouse) would make it easier to
control when your hands were covered in dough.
There are a small number of subtle, but important, differences when designing an interface for a
touchscreen. First, there is the absence of any hover control for when your point moves over (or into or
out of) the button area. So, you should avoid using tool tips to present additional information or explain
the button. Furthermore, the button areas themselves will generally need to be larger, with some
conceptual space in between them. When controlling a pad with your finger, for example, you will
generally only be accurate to within 20 pixels or so, so each button should probably be a minimum of 32
pixels in size. And finally, the use of touchscreen usually implies a lack of a keyboard. When this is the
case, your ability to type into text boxes is much reduced. There are several on-screen keyboards to solve
this problem, but they need to be large enough, for the reasons given earlier, and have a mechanism to
direct the input to more than one input control. It is also advisable to avoid screens that have to scroll in
one or more directions—ideally none at all.
Zinc: Between Web and Native
Before you get to the web pages themselves, there is one final layer to unwrap, Zinc. This is a small
library of server-side code that abstracts various types of device and allows them to be controlled
through WARP. This is also known in Minerva parlance as a web gateway conduit.
It consists of several very thin wrapper classes, which allow the PHP applet code to make system
calls in a safe and structured way. For instance, if you were to use the mp3player script, the web page
would not finish loading until the entire piece had been played. And if you start it in the background,
then any output (such as errors) would appear in your web page at some arbitrary location. This layer
protects against that. It also allows you to use alternate device names through the configuration files in
zinc/conf/mp3player.conf, for example, which let you replace either the Bearskin commands or the web
site without affecting the other. And for what it’s worth, the code necessary to correctly run mp3player
from a web page is as follows:
$cmd = MP3PlayerDevice::$binary." ".MP3PlayerDevice::$device;
$cmd.= " play $track";
$out = system("($cmd 2>&1 >/dev/null) >/dev/null 2>&1 &");
Of Web Pages and Applets
The web interface supplied with Minerva is based on WARP and as such allows you to have several
applets appearing on a single web page. Figure 7-1 shows a typical screen.
CHAPTER 7 ■ CONTROL HUBS
241
Figure 7-1. Various Minerva applets all running on a single page
Each applet is rendered as a small “panel” view (as shown by the cooking information) with the
maximized applet (the weather) being shown in a full window. All of these applets are available from a
single page, such as wnews.php, which consists of code like this:
<?
require_once 'warp/warplib/appletmanager.inc';
require_once 'warp/applets/main/main.inc';
require_once 'warp/applets/weather/weather.inc';
require_once 'warp/applets/tvguide/tvguide.inc';
require_once 'warp/applets/photoframe/photoframe.inc';
require_once 'warp/applets/cookery/cookery.inc';
require_once 'warp/applets/ldb/ldb.inc';
include_once 'system/master_standard.conf';
$appman = new Warp_Applet_Manager();
$appman->init();
$appman->AddApplet(new Warp_Main_Applet());
$appman->AddApplet(new Warp_TVGuide_Applet());
$appman->AddApplet(new Warp_PhotoFrame_Applet());
$appman->AddApplet(new Warp_Weather_Applet());
$appman->AddApplet(new Warp_Cookery_Info_Applet("Cooking Info"));
$appman->AddApplet(new Warp_LiveDepartureBoards_Applet());
echo $appman->renderPage();
?>
CHAPTER 7 ■ CONTROL HUBS
242
You can build your own pages using any combination of applets that you desire. This flexibility
allows you to ignore certain applets if they come from an IP address range outside the local network or
even build a page specifically for the machine. For example, knowing that your DHCP server always
provides your kitchen PC with an IP of 192.168.1.140, you can build a page that only includes a list of
recipes and cooking information.
■ Note If you access a web page through any form of proxy, including routers, you may not be able to get the
correct address, because the server will only see the IP of the proxy.
Instead of using a single page, you can produce several pages and use the main applet to switch
between them. This is shown in its maximized view in Figure 7-2.
Figure 7-2. The main applet
The main applet has two functions. The first is to enumerate each applet added into the applet
manager on that page, thus providing similar functionality to the minimized boxes on the right but with
larger graphics (that is, better for touchscreen users). Its second is to provide a way of moving between
separate pages. These are determined by the configuration file system/master_standard.conf, which
looks like this:
<?php
class MasterBar
{
public static $automaticInclude = false;