Hardware Reference
In-Depth Information
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:
u
Always acknowledge commands and requests
u
Always reply using the same medium
u
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.
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:
u
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.
u
The argument covers the specific device or unit involved.
u
The description contains a device-specific error, which should not repeat any information
pertaining to the error number or the device name (as they're already present).
Because 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.
Search WWH ::
Custom Search