Control Hubs: Bringing It All Together - Smart Home Automation with Linux and Raspberry Pi - page 244

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 Raspberry Pi, covered in
Chapter 8, or the Fit-PC2 and Mini-ITX machines from Chapter 4). This machine can be powercycled 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 pointer 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
direction—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. Without Zinc, the code necessary to correctly run
mp3player from a web page would be 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-2 shows a typical screen.