CHAPTER 7 ■ CONTROL HUBS 218 This allows me to add other kettles as needs require, which makes the configuration script look like this: DEVICE=$1 x10control default on `kettle.conf $DEVICE device` sleep `kettle.conf $DEVICE time` x10control default off kettle.conf $DEVICE device` Note the abstracted script x10control, instead of heyu, which I’ll discuss later. There is then one detail to add—once the teakettle has switched itself off, you use the Festival speech synthesis module to announce the fact. You could alternatively issue a pop-up window on your terminal, like this: kdialog msgbox "The kettle has boiled!" Providing a fresh boil when you return from work is a similar combination of simple scripts. In this case, you need to know the time the teakettle takes to boil (as shown earlier) and the travel time from work to home. You then perform a basic subtraction and issue a sleep before the kettle script is called. What calls the script is then a matter of taste (no pun intended). If you’re used to working on the command line, then a simple script could initiate a sequence to awaken the teakettle, switch on lights, and so on. Naturally, this same code could be run from a web page or triggered upon receipt of an e-mail. This works in the specific case where the journey duration is consistent, as it is for walkers, cyclists, and anyone not reliant on public transport or at the mercy of traffic. More complex solutions are also possible by looking at the live train departure boards, for example, and letting the computer work out which train you are most likely to have caught and check for its arrival time before beginning the boil. This is left as an exercise for you! Naturally, if you have a fast-boiling teakettle, there might be enough time to trigger the script from a pressure mat sensor under the front door mat or when the Bluetooth dongle detects your phone coming into range for the first time that day. In that case, by the time you’ve approached the house, opened the door, and taken off your shoes and coat, the teakettle is ready. Minerva Minerva is a complete, easy-to-use home automation suite. Using Minerva you can make your home easier and cheaper to run and can make it more secure. With Minerva you can switch on your lights from anywhere using a mobile phone or PC, e-mail your video, check your security CCTV footage, control your central heating, and do much more. It is the epitome of the modular design goals outlined in the introduction, and it’s an example of how you can bring all the technologies you’ve learned so far into a single unified whole. Minerva runs on GNU/Linux but exists in its own mini-ecosystem, with its own list of users, set of scripts, and functionality. It relies on native command-line tools to perform its many tasks and can therefore be run from virtually any platform (smartphone, PDA, laptop, or remote PC) with identical functionality. It also relies on the security model outlined earlier, where only a few users have access to the machine directly, expecting them to go through alternate interfaces so that their user credentials can be controlled on a case-by-case basis. CHAPTER 7 ■ CONTROL HUBS 219 Overview The Minerva system isn’t really a collection of software. It’s more akin to a bundle of protocols, each giving a unified interface to other programs and scripts in the system. This allows each script to abstract the tools underneath it so that if, for example, heyu becomes unable to support the necessary features or needs to be replaced, then only the X10 control script needs to be replaced—and none of the code that uses it. There are abstractions and interfaces for each part of the system. Minerva’s visionary grand design is to provide a means whereby every piece of home technology can be interfaced together through a common technology. This architecture consists of three parts: input, process, and output. Each part is completely distinct, meaning you can control any of the house processes from any supported input conduit such as the web browser, remote control, or SMS text message. Similarly, any reports or notifications can be sent to any of the available output conduits, which may (or may not) be the same as the input. One common example is to trigger a process (such as switching the teakettle on) using an IR input conduit but receive confirmation through the voice output conduit where the computer speaks to you. From this you can see that the web page input conduit is built on top the existing command abstractions. Furthermore, the web page has its own abstractions (called Zinc) so that if you want to build a smaller slimmed-down web page (which doesn’t have the dependencies on the WARP system), you can do so without replacing any of that code. Like the best Linux software, Minerva adopts many open standards and has code released through the GPL, which provides a platform that can encompass every user and system without vendor lock-in. You can reach its home and download page from http://www.MinervaHome.net. ■ Note Most examples here use the variable $MINBASE that is set to the install directory of Minerva, which by default is /usr/local/minerva. It is omitted for the sake of brevity. Underneath $MINBASE is a directory structure that is not unlike that used by most Linux Filesystem Hierarchy Standard–compliant distributions. It has the following: bin: The scripts that send and receive messages between conduits and the abstractions for the devices themselves. conf: Personal configuration data, such as external accounts and address book contacts. This has been separated from the traditional etc directory to allow sharing and updates to happen without accidentally exposing this private information. etc: Configuration data regarding the Minerva system itself, its users, and its appliances, such as the teakettle boil time. house: Global configuration concerning devices for this and other machines in the house. It dictates which specific devices (such as /dev/dsp or /dev/dvd) should be used with each particular command. This is also used with Marple (covered later), which allows other devices in the house to be controlled from a single location. CHAPTER 7 ■ CONTROL HUBS 220 media: Any sound, image, or text file used by the base-level system, such as chimes to begin a vocal announcement or recorded speech used in an alarm clock. var: All data generated by the user, as a consequence of using Minerva, is stored here. This includes the sampled messages generated by projects such as the Arduino dictation unit, presented in Chapter 2. For Linux compliance, it stores log information from the commands themselves in /var/log/minerva so that tools such as logrotate can be used normally. Installing Minerva requires an invocation of the basic install.sh script. This copies the files to the appropriate directories, changes the file permissions, and generates the default users for the system. It is also capable of downloading the current day’s weather reports and TV schedules. The script is fairly all- inclusive, so you can access the web-based applet for the CD player without explicitly granting read/write permissions to /dev/dsp to the web server. The downside of this permissive process is that potential vulnerabilities are opened up. Furthermore, anyone outside the U.K. area will need to rerun the update scripts describing their locale for Minerva to report accurate weather forecasts and TV schedules. Linux Users Are Not HA Users The desire of Minerva to have its own ecosystem, with distinct usernames and passwords, is not egomaniacal for the sake of it; it’s merely a case of practicality since not everyone using the system will have (or should be able to get) a Linux-based account. After all, you eliminate Linux accounts for most users, since you want users to control the system through means that can be more easily authenticated on a fine-grained level. This gives you a multistage approach: • Everyone living in the house or a family relative has a Minerva account. This gives you the option of allowing them to view family photos, see what you’re listening to, and so on. It also means they can use your services to retrieve shows from the TV guide or view the weather report. • Everyone living in the house will generally also have a web username, which should match their Minerva user, to provide them access to this input conduit. They will be a subset of total Minerva users. This allows them to control their music selection and review certain house stats. Each web user has controllable read and write authentication to the various facilities. • Most people living in the house will have access to the other input conduits, such as SMS or e-mail. • Few users, usually just one, will have a Linux account allowing them to directly control the filesystem and users. A guest account will usually exist to allow read- only access to the Samba file servers so that music can be played locally. Other users will be created for the purpose of e-mailing light switches, for example, but will be made inaccessible to other dwellers by setting the shell to /bin/false. Therefore, you will introduce your own read-only hierarchy within the Minerva filesystem (all relative to $MINBASE) covering each user, the applications, and their appropriate rights. The passwords for each input conduit will not be included here since the files must be publicly readable for the various commands to work. Instead, you rely on the input conduit (such as the web browser) to store its own CHAPTER 7 ■ CONTROL HUBS 221 passwords and validate the user. After all, you’re more likely to trust the experience of Apache in providing robust username security than yourself. First you can add users to the system with a line such as this: addminervauser steev "Steven Goodwin" This will create a directory for them, beginning here: $MINBASE/etc/users/steev to hold all the user-specific settings and data, including the following: • Full name • Personal address book • Default Minerva preferences (such as preferred Festival voice) • Access rights to various devices • TV search terms • External account references (such as links to their Google calendar) Each application in the system has a specific code (x10control, cdplayer, and so on) and an associated directory that holds files for determining the access rights such as r (for read-access) or rw (for read-write). I use r and rw as standard terms, even though their meaning isn’t directly analogous since in the case of the CD player read access means “can you look at the current track playing,” whereas read- write means “can change the current track.” You have a simple command to query this status, which returns a true or false response by setting 1 or 0 as an exit code, retrievable with $? if the specified user can query the state of the CD player: minuser auth steev cdplayer get r The currently supported codes are as follows: • cdplayer • Bluetooth • system • mixer • mp3jukebox • photos • videostream • vlc • x10 • sms CHAPTER 7 ■ CONTROL HUBS 222 These can be added to as necessary, without configuration, since the lack of an access file is considered as “no access allowed.” The Minerva User In the same way that Linux has an all-powered root user, so do you in the realm of Minerva. And that user is called, er, Minerva! Although it doesn’t have the same level of OS control that root does, it does have the responsibility of dealing with any housewide (that is, user-agnostic) data collection and processing. This includes the nightly collection of weather reports and the searching of the TV guide, which are processed by the scripts inside its update directory. The Public User You also have a public user that is used for storing housewide information such as the family address book. Since you can’t communicate with Minerva except through a conduit—and each conduit authenticates you as a user—this is used primarily to store default data. Device Abstractions In the code samples throughout this book I have used standard Linux tools such as heyu and cdcd. However, as I’ve outlined previously, these tools might (and probably will) be superseded by others in the future, and you don’t want to be tasked with rewriting every script and program to fit. Therefore, you should pledge to use only abstractions for these commands. Bearskin is a series of command wrappers that creates a common interface for controlling all the devices under Minerva’s control. It also maintains the state of that device in those cases where the underlying software does not support it. The format chosen is simply as follows: bearskin_command <device> <command> [command arguments] The concept of a device relates to the protocol in question and allows you to pass the command to an alternate machine for processing. This is useful in cases where the server cannot be physically located in the best position, which includes the example given in Chapter 4 where the Computer-to-X10 gateway (such as a CM11) is unable to communicate with the rest of the appliances because of other electrics suppressing the signal. It can also include cases where you want to play the music from a machine that isn’t the local /dev/dsp device or to control the CD player in a different machine. It is part of Marple. Consequently, most commands begin with the following: DEVICE=`$MINBIN/finddev x10 $*` if [ $? == 0 ]; then echo $DEVICE exit 0; fi Under the hood, the finddev script looks through the $MINBASE/house/marple/x10/devlist file to discover how to address the X10 module on the current machine, that is, localhost. The devlist file might appear as follows, indicating that the module is attached to /dev/ttyS0: . Minerva Minerva is a complete, easy-to-use home automation suite. Using Minerva you can make your home easier and cheaper to run and can make it more secure. With Minerva you can switch on your. whole. Minerva runs on GNU /Linux but exists in its own mini-ecosystem, with its own list of users, set of scripts, and functionality. It relies on native command-line tools to perform its many. a platform that can encompass every user and system without vendor lock-in. You can reach its home and download page from http://www.MinervaHome.net. ■ Note Most examples here use the variable