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

Apress - Smart Home Automation with Linux (2010)- P56: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
Nội dung trích xuất từ tài liệu:
Apress - Smart Home Automation with Linux (2010)- P56 CHAPTER 7 ■ CONTROL HUBS You can use the same mechanism to invoke software-only devices, such as media players and Festival, allowing music to be streamed into locations where physical speaker cabling is not possible. The system is bidirectional, so you can also get a remote machine to send any commands it gets to the main server for processing. Marple was introduced in version 2.2.0 of Minerva and is now supported by all the current Bearskin commands and used transparently to the user. The Workings There are two files necessary to enable Marple’s full range of functionality, both are called devlist and exist for each of the Bearskin commands that have been enabled. They are formatted thusly: localhost dev /dev/dsp - - default dev /dev/dsp - - bedroom soap 192.168.1.123 19781 localhost The columns are as follows, in order: The device name: This is always the first argument to any of the Bearskin commands, such as the bedroom in cdplayer bedroom play 1. Protocol type: This currently may be dev or soap. If the protocol is dev, then the protocol device represents a Linux-style device on the local machine. If it’s soap, then the device specifies the IP address of the machine to talk to. Protocol device: This indicates which address is to be used for the device. It’s usually a device or IP address (see the previous item). Protocol parameter: This is used in conjuncture with the protocol device. This is mostly unused, but in the example earlier it represents the port number associated with the IP address. The remote device name: When the command is being executed on the remote device, this name is used instead of the original one given. This parameter is unused for dev protocols. Handling Protocols When the user invokes the cdplayer command for example (from either the Web, command line, or Cosmic), the script will examine the local devlist file located at $MINBASE/etc/devices/cdplayer/devlist for a matching device name in the first column. If no matching device name can be found, it then reads the global devlist file (in the same format but located at $MINBASE/house/marple/cdplayer/devlist) and tries again. If a match still can’t be found, then the original device name is used by cdplayer in the hope that it is application-specific and the cdplayer application can understand it. Once a matching device name is found (regardless of which file contained it), the device is evaluated. In the case of dev protocols, the protocol parameter (such as /dev/dsp) is passed back to the application for immediate use.258 CHAPTER 7 ■ CONTROL HUBS All other protocols, such as soap, are handled by external commands located in$MINBASE/bin/xmit/[protocol_name]/cmd. This combines the new protocol information (IP address andport) with all the parameters from the original command, with the remote device name (column 4) inplace of the original one, and passes it to the appropriate cmd script. Here it is in geek parlance:$MARPLEPROTOCOL/cmd ${DEVARRAY[2]} ${DEVARRAY[3]} $COMMAND ${DEVARRAY[4]} $ALLARGS This command can then issue an appropriate network packet to the server listed. In the case ofSOAP, a call is made to minerva/marple/cmd.php where the arguments are extracted, and a brand newBearskin command is formulated like this: Note that the only commands available are under the /usr/local/minerva hierarchy, with allinstances of .. pruned out to stop malicious code from being run. 259 CHAPTER 7 ■ CONTROL HUBS ■ Note If you add your own protocols but they’re not addressed by an IP/port pair, then you can reappropriate the two columns to your desires, provided your $MARPLEPROTOCOL/cmd script can understand them. Using the cdplayer example again, the remote machine processes a command that now looks like this, if it were to be processed locally: cdplayer localhost play 1 Bearskin Compatibility To make your own commands compatible with Marple, you need to begin your scripts with a few extra lines of code. Here’s an example: DEVICE=`$MINBIN/finddev mixer $*` if [ $? == 0 ]; then echo $DEVICE exit 0; fi This rather strange-looking piece of code makes use of both the finddev output and its exit code. It returns a 0 in those cases where the device name was found but wasn’t intended for this machine. In other words, it has dispatched a SOAP request or similar and 1 when a genuine device was found. The latter is more usual and ends up being /dev/dsp or similar. As far as the command scripts go, this is all that’s necessary. The extra work comes from creating a local devlist. But each is generally a carbon copy of the others. Namely, a file called $MINBASE/etc/devices/new_app_name/devlist should be created and appear like this, replacing /dev/dvd with a suitable device for your app: localhost dev /dev/dvd - - default dev /dev/dvd - - Note that the local devlist file should always include a default and localhost reference. This ensures that every query can terminate and stops recursive loops from happening. ■ Note Some low-level ...