introduction	approach	future	achievements	information
Toolkit
We have developed our toolkit, the Real World Interface Library (RWIL) over a period of approximately six months. As we have added functionality to the toolkit we have allowed for access through multiple languages with different styles of coding in order to determine which paradigm adapts itself to the concept of X10 devices. Our toolkit has been developed for use in C, C++, and in conjunction with a graphical user interface toolkit known as Amulet. Additional languages that we have explored and developed sample API’s for are Perl and Tcl. For each of these various systems we have attempted to model the interface to the toolkit on paradigms used heavily when programming in that language or toolkit. For instance, our C interface exposes what appears to be a procedural interface and the use of an opaque handle to maintain state. The C++ interface, on top of which all of the other interfaces are built, is based on the concept of passing message objects to virtual device objects that implement the X10 commands. The Amulet style interface is an Amulet object, which responds to constraints, and command objects like all widgets in the Amulet system. The proposed Perl interface is designed to expose objects that directly represent such devices as lamps for direct control. Finally, the proposed interface for Tcl is designed to expose X10 devices in the same manner as Tk widgets.
Problems with using X10 as an Interface
The X10 protocol has a number of issues that make using X10 devices difficult. For one, control is extremely slow. The X10 protocol allows for a transfer rate of 30 bits per second over the power line to the device. Additionally, there is a lack of error handling, detection, and control in the protocol. Essentially, the protocol is not reliable. When this protocol was designed, this was not a problem as humans pressing buttons designed it for interactive use. However, when a computer is controlling the system it cannot discover if a command was successful or not. Our solution was to employ some of the more recently designed X10 devices which allow for the device to inform another device on the X10 system of its status. We have employed this capability to check to verify that a command has successfully executed and retry as needed. This series of required steps has a side effect. The problem is that commands to control devices take a long time to execute, with the time to execute varying between 4 and 16 seconds each time. This is one of the issues that has made integrating X10 devices into a user interface framework rather difficult, as user interface frameworks expect action to occur immediately. This is a side effect of user interface frameworks being designed for display only to a monitor as opposed to several different devices of varying capability
Our Solutions to these Problems
Our solution for these problems is to make it so that commands to control X10 devices such as lamps and fans execute in parallel with other application code. This is the basis of our C++ message passing architecture which passes messages to a separate thread which actually executes them. This solution performs admirably well; however, it has proved extremely awkward to use because it exposes a great deal of the mechanics of the system, and it is often unclear what messages should be passed where. To solve this problem, the other API’s have been developed as layers on top of this system. The layers have served to hide the messages passing and separate thread of thread of execution in several ways. The method we used for the Amulet system exposes to the application an interface that appeared to update immediately, and pretends that the actual X10 devices reacted instantaneously to control from the application. This required some clever coding, but was ultimately easy to use. Unfortunately, this system provided for no way for the application to determine the real state of the device, and should the device fail or have some other error there would be no indication. Next attention was turned to the C interface, which exposes a procedural interface with callbacks tied to the actual success or failure of commands. This interface has proved both easier to use than the C++ interface due to its concise easy to describe nature, and also more powerful than the Amulet interface as it exposes the notion that X10 commands take an extremely long time to execute in comparison to normal actions in a computer. By implementing the interface in plain C rather than with an established toolkit such as Amulet, some features are lost that were available immediately in the Amulet toolkit. The prime examples are the lack of integration with a GUI, which requires the user to manually integrate X10 into their devices, and the lack of extra “free” features such as animation which the Amulet toolkit provides.
Send comments and suggestions to: rwi@listserv.vt.edu Last updated: 20 January, 2002