Jump to content


- - - - -

An introduction to xAP, part II


So, How is xAP Used

Let us now go back to the opening scenario where X10 is used to control a light based upon the commands provided by a motion sensor. It does not make sense to turn a light on during the day just because there is motion. One solution is to configure the motion sensor to only provide the command when it is dark. This works for the light, but the indication of motion is still desired at all times of the day by the computer so it can do other things that are dependent upon motion in that area. The typical solution is to allow the motion sensor to transmit motion indication at all times, but to transmit it to the computer rather than to the light switch. The computer will first determine if it is dark and if so then it will send the command to the light switch.


What if we had a slightly smarter light switch that was network-connected and understood the lightweight xAP protocol? We also have a dusk/dawn sensor with the same connectivity, or a synthesized one based upon sunrise/sunset from a time-base that is network-connnected. The light switch will understand a message from a dusk/dawn sensor. It will understand the motion sensor that identifies that darkness exists in the same area that is controlled by the light. It will also understand a moding message that comes from something like a PC that enables its class of behavior.

In this scenario the light switch receives the motion sensor message. It had previously received dusk/dawn or sunrise/sunset information as well as moding information. It will now immediately turn on the light and provide status via a xAP message that the light is now ON. The PC(s) will now know the light is ON because it receives the status event message from the light switch.

All this is involved at the instant that the light needs to be turned on is the motion sensor and the light switch. There will be no impact or delay due to the PC should it be sleeping, undergoing maintenance, or just busy on another responsibility. When the PC does wake up it will send out queries to learn the state of the environment. One of the responses will be the light switch reporting that the light is ON.

While electronics is moving in the direction of IP connectivity, there are still many items that are most cost-effectively interfaced with other means. In this example the cheap motion sensors use RF and an RF receiver is needed to understand them. We do not want to put an RF receiver in every piece of equipment that could benefit from motion sensor information. What we can do, however, is use a single RF receiver that has an IP interface. Of course the desired RF receiver is interfaced today via RS232 rather than IP. The solution then becomes what is called a “connector”. The RF receiver is connected to a processor that has both a serial port and an IP. This allows RF receptions to be made available simultaneously to all nodes on the LAN. This processor can be a little controller such as a Rabbit or it can be a process running on one of the computers on the LAN.

A single PC could support multiple different connectors if desired. The actual location of the connector could move around anywhere on the LAN and it would be transparent to all other nodes that use information from the connector.

xAP is actually a protocol above the physical layer which means that the xAP messages could be implemented via RS232 rather than Ethernet. This however, becomes a tangent to the purpose of this discussion. What is nice about xAP is its flexibility. It is designed to support the trend for IP connected devices and devices that are very resource-limited. It looses nothing when it is applied to resource-heavy PC and any variant.

What one tends to realize is that the actual control of the Home is really a distributed activity and a centralized architecture is actually counter to the natural scheme of things. There is a need for a central location for a human information interface, but this is the extent of the centralization. While the central brain can be used to control everything, it is really only needed to support our needs to see what is going on and our needs to provide some coordinated input and these activities are typically not time-critical and usually very low duty cycle. This is in contrast with the control needs that are usually time-sensitive.

Traditional Alternatives

Over the years many special-purpose applications have been developed to allow point B to be controlled from point A on the LAN. Some of these have a singular purpose and others have gained some acceptance and grown to satisfy the needs of a larger audience. Girder is a well-known example of one that has gained grass-roots support.

Since these are all software implementations to satisfy a need they can continue to grow and extend the basic capabilities from which they were born. In all cases they exist with an expected use of the control/data that they are transporting. In the xAP case the protocol provides a conduit by which information is available and it can be grabbed and used by any listener for whatever purpose suits this listener. The design focus goes from master-slave in special-purpose implementations to a peer-peer in xAP architectures.

xAP provides an elegant growth path while special-purpose node-to-node applications tend to impose restrictions where the solution is some form of workaround.
xAP Resources

xAP and xPL are user-supported efforts that are rooted in the UK. There exists no corporate sponsorship, nor are there families of commercially-available xAP-compatible devices. To my knowledge there are two commercial hardware products with native xAP or xPL support. One is IP-based audio player SlimP3 from Slim Devices. The other is an IP-based general purpose IO called NetioM from Phaedrus Limited.

Home-brew hardware products have been developed using PIC and Rabbit processors and the source code to support xAP with these processors is available. One PIC application provides a xAP RS485 interface. A native C-Bus interface under xAP control is available for purchase. It uses the Rabbit processor. An 8 channel relay should be available from Mollyology.com. It is powered with Atmel AVR series processor.

There are a large number of connectors that bring legacy equipment onto an IP / xAP LAN or transforms information so it becomes generally available for Home Automation.. They are hosted on both Unix and Windows platforms. IR, X10, CID, SMS, RSS, Weather are typical examples. A more complete list can be seen by navigating the xAP and xPL sites starting at:

xAP - http://www.xapautomation.org
xPL - http://www.xplproject.org.uk/

For those wanting to roll their own then advantage can be taken of existing development resources. xAP and xPL development resources are generally available at no cost under the General Use License which essentially means to use for ones own pleasure, but not for their profit. These resources are available for Windows and Unix platforms. In the Windows case they include .NET, C and VB and a few others. Source code is usually available.

For those starting with VB then the xapax.ocx from Patrick Lidstone’s site http://patrick.lidstone.net/ha encapsulates the xAP message protocol.

For those starting with .NET then the xAPFramework from Stuart Booth’s site http://www.xapframework.net/ contains the C# source and a plugin-oriented architecture

In either case Stuart’s site is a good resource for a Viewer from which xAP message traffic on the LAN can be viewed.


About Michael McSharry

I started tinkering with Home Automation in 2001 shortly after building my house. I wanted to do something with motion-activated cameras to provide some security at my new location in the mountains. The cameras never arrived, but the door was opened to explore all sorts of tangents under the umbrella of computer-based control. This has been a life-long interest. I’ve been fortunate to be paid for this interest since the 1970 in the process of designing the vehicle control systems for spacecraft and military aircraft.

Forum Thread




0 Comments