An introduction to xAP, part I
by Michael McSharry
The Rationale
When we start out in HA we are excited to be able to control anything with some degree of automation. The simple things were exciting and made us lust for more. The typical route is the X10 ActiveHome that segways into Homeseer, MisterHome, or other PC-based automation engine. These provide more head room for growth and many possibilities that had not existed before.
The natural tendency is to pile on more and more goodies. While the incremental additions are not significant, the accumulation of these tends to slow the overall system down. Even worse the system tends to become fragile and dependability wanes. When that first goodie was added it worked great. Now with n goodies installed it takes some serious thought if adding the n+1th is worth the risk.
The desire for continued automation exists, but just as ActiveHome reached its practical limit, the central-HA-brain, also can reach its practical limit. While there may still be a Master of the household, the days of shared responsibility are upon us.
Intro to Distributed Control
Many have begun with an X10 starter kit. Perhaps this was a light switch, a transceiver and a palmpad. Press a button on the palmpad and the light turns on. The palmpad send a radio wave that is received by the transceiver. The transceiver sends a powerline transmission to the light switch. Add a second light switch and now two lights can be controlled with the only additional change is that the address of the light switch is different than that of the first light switch. Add another palmpad and now two people can control the light(s).
Add a computer with a powerline interface to the mix to automate the control of these lights. The light can be turned on manually with the palmpad or automatically with the computer. Add second computer and powerline interface and now the light can be turned on by either computer and both computers will hear the commands over the powerline and both computers will know the On/Off state of the light.
Add a motion sensor near each light switch. The light turns on when motion is detected and the computer(s) know that there is motion and know the light is ON because the command to the switch is on the powerline and the computer(s) can listen to the powerline commands.
This is so easy to achieve distributed and automated control. Just add device with X10 addresses and everything happens just as desired with control from multiple sources. The X10 powerline architecture provides an elegant, albeit limited, means to incrementally add controlled and controlling devices. The ubiquitous house wiring provides the network infrastructure. The devices can be located anywhere where the house wiring runs. Individual devices can be added or removed without any impact to the operation of the others.
House wiring was a reasonable network for Home Automation in the later half of the 20th century. It still has its place in the 21st century, but Ethernet, in wired and wireless forms is the information-age network of choice. The information routed from one Ethernet node to another is richer than a simple ON/OFF/DIM of the X10 network, but the incremental architecture that allows multiple controllers and multiple controlled devices is still a desired elegant solution.
X10 defines a communication language that includes a house and device code to identify a location and a set of 16 commands that are used to effect an action. Ethernet networking technologies also uses a communication language. This language is actually layered into tiers with the lowest being the electronics of the physical connection and higher tiers used to package and route information content. Multiple protocols can coexists at the same time just as German and Spanish can both be spoken on the same telephone network.
Distributed Home Automation Protocols
There are many protocols used on Ethernet-IP transmissions. Each tends to exists to satisfy a specific need. SMTP for email, DHCP for network identification, FTP for file transfer, and many more are under widespread use. If one could look up in the dictionary of non-proprietary protocols all those that are designed to support Home Automation the list would be reasonably short. Included in it will be xAP and xPL. Perhaps uPnP would fall under the umbrella, and there may be others as well.
uPnP relies upon several layers of supporting protocols to achieve what is roughly the equivalent of the PnP. PnP came from the cooperative efforts between hardware and Operating System makers to allow a piece of hardware to be recognized by the operating system. This is in contrast with the prior situation where the configuration and capabilities of the hardware had to be manually configured with jumpers and the OS had to be manually configured to recognize this new piece of hardware. uPnP extends this to insertion of new devices on a LAN rather than just insertion into a PC motherboard.
From an end-user point of view this is good, but there is much to Home Automation than just identification of a device and its capabilities. There is also a lot of home-brewing that demands a lot of flexibility.
The xAP protocol was developed to facilitate communication between devices typically found in a Home Automation environment and geared toward use of Ethernet as the communication medium. Conceptually it is an extension of the X10 architecture where multiple controllers and controlled devices can be incrementally added or removed and operation achieved independent of the physical location of the devices. Each device is addressed by name and it is commanded using vocabulary appropriate for the capabilities provided by the device.
xPL is a branch of xAP that has adopted some of the concepts of the uPnP autodiscovery and configuration and has descoped the message protocol to make it a little lighter and focus only on the mainstream needs of HA. The discussion below applies to both xAP and xPL even though only xAP is explicitly identified.
The Nature of xAP
In the X10-world the addresses take the form of “A1â€, “B3â€, etc. In the xAP-world the address is something like “Smith.Bedroom.Floorlampâ€, Smith.VacationHouse.Floor2.GuestBedroom.NightLightâ€, or “Smith.TV.FamilyRoom.Televisionâ€. With X10 it is possible to combine multiple addresses in a single command such as A1+2 ON to turn on devices A1 and A2 at the same time. Similar wildcarding is used with xAP, but xAP goes well beyond the singular X10 case which allows control of multiple devices on the same house code.
Now we are going onto a slight tangent with a field trip down to the local bank to provide an analogy to help understand the makeup of a xAP message. The transaction at an ATM machine is started by identification of user and this is typically done with a magnetic card reader followed by a PIN. This introductory process performs the same function as the identification of an X10 or xAP address of a Home Automation environment. The next step in the ATM experience is often the selection of the language (e.g. English, Spanish) that will be used for the remainder of the transaction. The same analogy applies in the xAP situation. The sender of a xAP message will identify the language in which the remainder of the message is represented. The language in this context is called the Schema and will be things like “Audioâ€, “IRâ€, “X10â€, or “CID†rather than English or Spanish.
xAP messages are simultaneously received by all controllers, devices, and computers (i.e. nodes) that are on the LAN. Broadcast and Multicast as applicable buzz words for the technically inclined. This the same operation as on the X10 powerline were all devices receive the same X10 message at the same time. The node will look at the address and look at the language/schema which are encoded at the start of the message and determine if it intended for itself and if it can understand the language/schema. If it does not make it through this filter then it is ignored, otherwise it continues to decode the remainder of the message content. It may be the case that this message is accepted by zero, one, or more nodes and the node will act upon the content contained in the body of the message. This content appears like the content that is received from a HTTP/Browser form submittal where there will be a set of key-value pairs. “NAME=telemarketer†would be a typical key/value pair for a message using the CID language/schema.
The extensibility of the xAP schema is very similar to the extensibility provided by XML. It is actually possible to map a xAP schema into XML. It would seem that xAP should just use XML to describe its schema if there is a one-to-one relationship between xAP schema and XML. This would work fine on a typical PC, but xAP is designed to support a mixed environment of PC and small scale devices. A PIC or other small microcontroller is a typical device that can be used for Home Automation. The PIC can handle the lightweight xAP protocol, but XML demands resources well beyond that which are available in small devices.
Typical xAP transactions can be modeled after the operation of a 2-way X10 switch. A controller sends a command to the switch to request the light be turned ON (A1 CMD ON). The switch will turn the light ON and respond with a status response (A1 STATUS ON). The switch can also be queried and it will respond with status. (A1 STATUS REQUEST) (A1 STATUS ON). Events are also communicated such as the X10 motion detector that will send (A1 CMD ON).
This transaction scenario of REQUEST, STATUS and EVENT is not hard-coded into the xAP specification, but is part of the language/schema definition. A user of xAP is free to define whatever schema he/she wishes to use. If they use published schema then interoperability with Home Automation software from various developers is possible.
by Michael McSharry
The Rationale
When we start out in HA we are excited to be able to control anything with some degree of automation. The simple things were exciting and made us lust for more. The typical route is the X10 ActiveHome that segways into Homeseer, MisterHome, or other PC-based automation engine. These provide more head room for growth and many possibilities that had not existed before.
The natural tendency is to pile on more and more goodies. While the incremental additions are not significant, the accumulation of these tends to slow the overall system down. Even worse the system tends to become fragile and dependability wanes. When that first goodie was added it worked great. Now with n goodies installed it takes some serious thought if adding the n+1th is worth the risk.
The desire for continued automation exists, but just as ActiveHome reached its practical limit, the central-HA-brain, also can reach its practical limit. While there may still be a Master of the household, the days of shared responsibility are upon us.
Intro to Distributed Control
Many have begun with an X10 starter kit. Perhaps this was a light switch, a transceiver and a palmpad. Press a button on the palmpad and the light turns on. The palmpad send a radio wave that is received by the transceiver. The transceiver sends a powerline transmission to the light switch. Add a second light switch and now two lights can be controlled with the only additional change is that the address of the light switch is different than that of the first light switch. Add another palmpad and now two people can control the light(s).
Add a computer with a powerline interface to the mix to automate the control of these lights. The light can be turned on manually with the palmpad or automatically with the computer. Add second computer and powerline interface and now the light can be turned on by either computer and both computers will hear the commands over the powerline and both computers will know the On/Off state of the light.
Add a motion sensor near each light switch. The light turns on when motion is detected and the computer(s) know that there is motion and know the light is ON because the command to the switch is on the powerline and the computer(s) can listen to the powerline commands.
This is so easy to achieve distributed and automated control. Just add device with X10 addresses and everything happens just as desired with control from multiple sources. The X10 powerline architecture provides an elegant, albeit limited, means to incrementally add controlled and controlling devices. The ubiquitous house wiring provides the network infrastructure. The devices can be located anywhere where the house wiring runs. Individual devices can be added or removed without any impact to the operation of the others.
House wiring was a reasonable network for Home Automation in the later half of the 20th century. It still has its place in the 21st century, but Ethernet, in wired and wireless forms is the information-age network of choice. The information routed from one Ethernet node to another is richer than a simple ON/OFF/DIM of the X10 network, but the incremental architecture that allows multiple controllers and multiple controlled devices is still a desired elegant solution.
X10 defines a communication language that includes a house and device code to identify a location and a set of 16 commands that are used to effect an action. Ethernet networking technologies also uses a communication language. This language is actually layered into tiers with the lowest being the electronics of the physical connection and higher tiers used to package and route information content. Multiple protocols can coexists at the same time just as German and Spanish can both be spoken on the same telephone network.
Distributed Home Automation Protocols
There are many protocols used on Ethernet-IP transmissions. Each tends to exists to satisfy a specific need. SMTP for email, DHCP for network identification, FTP for file transfer, and many more are under widespread use. If one could look up in the dictionary of non-proprietary protocols all those that are designed to support Home Automation the list would be reasonably short. Included in it will be xAP and xPL. Perhaps uPnP would fall under the umbrella, and there may be others as well.
uPnP relies upon several layers of supporting protocols to achieve what is roughly the equivalent of the PnP. PnP came from the cooperative efforts between hardware and Operating System makers to allow a piece of hardware to be recognized by the operating system. This is in contrast with the prior situation where the configuration and capabilities of the hardware had to be manually configured with jumpers and the OS had to be manually configured to recognize this new piece of hardware. uPnP extends this to insertion of new devices on a LAN rather than just insertion into a PC motherboard.
From an end-user point of view this is good, but there is much to Home Automation than just identification of a device and its capabilities. There is also a lot of home-brewing that demands a lot of flexibility.
The xAP protocol was developed to facilitate communication between devices typically found in a Home Automation environment and geared toward use of Ethernet as the communication medium. Conceptually it is an extension of the X10 architecture where multiple controllers and controlled devices can be incrementally added or removed and operation achieved independent of the physical location of the devices. Each device is addressed by name and it is commanded using vocabulary appropriate for the capabilities provided by the device.
xPL is a branch of xAP that has adopted some of the concepts of the uPnP autodiscovery and configuration and has descoped the message protocol to make it a little lighter and focus only on the mainstream needs of HA. The discussion below applies to both xAP and xPL even though only xAP is explicitly identified.
The Nature of xAP
In the X10-world the addresses take the form of “A1â€, “B3â€, etc. In the xAP-world the address is something like “Smith.Bedroom.Floorlampâ€, Smith.VacationHouse.Floor2.GuestBedroom.NightLightâ€, or “Smith.TV.FamilyRoom.Televisionâ€. With X10 it is possible to combine multiple addresses in a single command such as A1+2 ON to turn on devices A1 and A2 at the same time. Similar wildcarding is used with xAP, but xAP goes well beyond the singular X10 case which allows control of multiple devices on the same house code.
Now we are going onto a slight tangent with a field trip down to the local bank to provide an analogy to help understand the makeup of a xAP message. The transaction at an ATM machine is started by identification of user and this is typically done with a magnetic card reader followed by a PIN. This introductory process performs the same function as the identification of an X10 or xAP address of a Home Automation environment. The next step in the ATM experience is often the selection of the language (e.g. English, Spanish) that will be used for the remainder of the transaction. The same analogy applies in the xAP situation. The sender of a xAP message will identify the language in which the remainder of the message is represented. The language in this context is called the Schema and will be things like “Audioâ€, “IRâ€, “X10â€, or “CID†rather than English or Spanish.
xAP messages are simultaneously received by all controllers, devices, and computers (i.e. nodes) that are on the LAN. Broadcast and Multicast as applicable buzz words for the technically inclined. This the same operation as on the X10 powerline were all devices receive the same X10 message at the same time. The node will look at the address and look at the language/schema which are encoded at the start of the message and determine if it intended for itself and if it can understand the language/schema. If it does not make it through this filter then it is ignored, otherwise it continues to decode the remainder of the message content. It may be the case that this message is accepted by zero, one, or more nodes and the node will act upon the content contained in the body of the message. This content appears like the content that is received from a HTTP/Browser form submittal where there will be a set of key-value pairs. “NAME=telemarketer†would be a typical key/value pair for a message using the CID language/schema.
The extensibility of the xAP schema is very similar to the extensibility provided by XML. It is actually possible to map a xAP schema into XML. It would seem that xAP should just use XML to describe its schema if there is a one-to-one relationship between xAP schema and XML. This would work fine on a typical PC, but xAP is designed to support a mixed environment of PC and small scale devices. A PIC or other small microcontroller is a typical device that can be used for Home Automation. The PIC can handle the lightweight xAP protocol, but XML demands resources well beyond that which are available in small devices.
Typical xAP transactions can be modeled after the operation of a 2-way X10 switch. A controller sends a command to the switch to request the light be turned ON (A1 CMD ON). The switch will turn the light ON and respond with a status response (A1 STATUS ON). The switch can also be queried and it will respond with status. (A1 STATUS REQUEST) (A1 STATUS ON). Events are also communicated such as the X10 motion detector that will send (A1 CMD ON).
This transaction scenario of REQUEST, STATUS and EVENT is not hard-coded into the xAP specification, but is part of the language/schema definition. A user of xAP is free to define whatever schema he/she wishes to use. If they use published schema then interoperability with Home Automation software from various developers is possible.
