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; . 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. $appman->init(); $appman->AddApplet(new Warp_Main_Applet()); $appman->AddApplet(new Warp_TVGuide_Applet()); $appman->AddApplet(new Warp_PhotoFrame_Applet()); $appman->AddApplet(new. 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