Apress - Smart Home Automation with Linux (2010)- P47

Chia sẻ: Cong Thanh | Ngày: | Loại File: PDF | Số trang:5

Thêm vào BST

Báo xấu

45
lượt xem 3
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Apress - Smart Home Automation with Linux (2010)- P47:Linux users can now control their homes remotely! Are you a Linux user who has ever wanted to turn on the lights in your house, or open and close the curtains, while away on holiday? Want to be able to play the same music in every room, controlled from your laptop or mobile phone? Do you want to do these things without an expensive off-the-shelf kit

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Apress - Smart Home Automation with Linux (2010)- P47

CHAPTER 6 ■ DATA SOURCES 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. 213
CHAPTER 6 ■ DATA SOURCES 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. 214
CHAPTER 7 ■■■ 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? 1 Linux provides access to every file and device 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. 215
CHAPTER 7 ■ CONTROL HUBS 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. 216
CHAPTER 7 ■ CONTROL HUBS 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 2 of each teakettle and its respective boiling time. 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. 217