Smart Home Automation with Linux- P9

Smart Home Automation with Linux- P9:For every word I’ve written, five have been discarded. Such is the nature of writing. For every tenprograms I’ve downloaded, tried, and tested, nine have been discarded. Such is the nature of software.Finding a perspicuous overlap has been a long and arduous tasks, and one that I’d wish for no one tosuffer in solitude.
Nội dung trích xuất từ tài liệu:
Smart Home Automation with Linux- P9 CHAPTER 7 ■ CONTROL HUBSlocalhost dev /dev/ttyS0 - - You will see how this is able to communicate with other machines in the “Marple” section later inthis chapter. Additionally, all Bearskin commands support init as a command argument so that it can preparetemporary log files, adjust ownership permissions, and launch any daemons as necessary.Typical Application AbstractionsThe currently supported abstractions are held in $MINBASE/bin and include all the necessaryfunctionality. I’ll cover these briefly, pointing out the subtleties as necessary: x10control: This is a simple abstraction that invokes heyu to switch lamps and appliances on and off and dim lights. Because the arguments are unified between all Bearskin commands, the invocation of this looks reversed to heyu, making a typical call look like x10control default on bedroom_light. cdplayer: For those still in love with those shiny plastic discs, this controls the CD player (with cdcd) and retrieves its track listing using the cddb-tool package. Because the retrieval of this data can be quite slow, the track data is temporarily stored in /var/log/minerva so that it can be queried instantly with commands such as cdplayer default currentname. mp3player: This is a general-purpose media player that also processes the ID3 tags inside the MP3 to report the current artist and album with mp3player default artist, for example. It uses /var/log/minerva to store this information, along with the current process ID, which allows you to move through the tracks with mp3player default next. It abstracts mplayer, while making use of mp3info to parse the ID3 tags. wavplayer: This is a simpler, primarily synchronous, audio player used for general house alerts using play. mixer: This adjusts the relative volumes of each channel in the audio mixer, the names of which have also been abstracted so that user-friendly words such as master, cd, and recording can be used. It allows you to set the volumes as either a relative or absolute value between 0 and 100 percent, even when the underlying mixer application doesn’t. The current implementation uses aumix. say: This is the most interesting abstraction, despite being the simplest, because this queries the default voice (stored as a name in $MINBASE/etc/defaults/festvox, if present) and invokes festival. When called on behalf of a specific user, it uses their customized voice settings. There is also a sayfile variant for longer phrases using Festival’s more efficient --tss argument. announce: This is an important extension since its context is different. Namely, it’s used for announcements to the house that something (important) is happening. It wraps the call to say by playing a chime sound and lowers the volume of any music that might be playing, before making the announcement and returning the volume levels to normal. Because of the importance of such 223 CHAPTER 7 ■ CONTROL HUBS messages, the device should generally be different from that of mp3player to 3 prevent audio device conflicts in some systems. In the worst cases, this can require using a second sound card or making use of the sound card in an external machine that generally has no use for audio, such as a wall panel. The wavplayer is often configured to use this same device. tweet: This is a way of publishing an announcement via microblogging site Twitter. This can be used by multiple users in the house, since it queries a set of stored credentials for each user in $MINBASE/etc/users/[username]/external/twitter. irsend: This is a means to send predetermined infrared remote-control codes to the connected IR transmitter. It will then be picked up by any sensor in range. For this reason, most IR-enabled equipment is held in Node0 where a single transmitter can service them all. It takes two arguments, the name of the equipment and the message that needs to be sent, and retrieves the code from a file held in $MINBASE/etc/ir/[equipment]/codes/[command]. The format of the data in this file is governed by the name ...