XPL Protocol
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
No issues specified. Please specify issues, or remove this template. |
xPL is an open protocol intended to permit the control and monitoring of home automation devices. The primary design goal of xPL is to provide a rich set of features and functionality, whilst maintaining an elegant, uncomplicated message structure. The protocol includes complete discovery and auto-configuration capabilities which support a fully "plug-n-play" architecture - essential to ensure a good end-user experience.
xPL benefits from a strongly-specified message structure, required to ensure that xPL-enabled devices from different vendors are able to communicate without the risk of incompatibilities. [1]
Communications between xPL applications on a Local Area Network (LAN) use UDP on port 3865. [2]
xPL development has primarily occurred in the DIY community, where users have written connecting software to existing protocols and devices. Some examples include bridges to other home automation protocols like Z-Wave [3] and UPB [4]. Commercially, the Logitech SqueezeCenter software for the Squeezebox supports xPL [5].
Architecture
Components
Different devices communicate using xPL with the help of a hub.
XPL device
Applications add functionality to your home automation solution such as weather information, sun rise/set and so on. You can build you own and there are many available on the net. A device can generate and or act on received messages, it can also issue instructions to any other xPL device.
HUB
A hub is needed for all PCs that run one or more xPL devices. The main intention of the Hub is to broker the transactions when there are several devices on the once PC.
Bridge
It is assumed that your network protocol is UDP/IP but this is by no means a requirement. If you wish for your XPL message to cross from one transport medium to another (UDP/IP to RS232 for example) then you will need a Bridge.
XPLHAL
This is the brains of the XPL solution. Device configuration is performed here, meaning this is a critical component for the xPL environment. Scripted rules (called Determinators) that act on events (xPL or other) is a very handy feature delivered by XPLHAL.
Transmission media
The xPL protocol can operate over a variety of transmission media, including Ethernet, RS232 and RS485.
Ethernet
All xPL devices broadcast their messages over UDP, on IANA registered port 3865.
But, as only one application can listen at a time to a given port, the xPL protocol uses a hub to retransmit all broadcast messages to the different applications on the same machine. The applications subscribe to the hub on a free port by sending hearbeat messages which specifies the port they are listening to. In turn, the hub forwards all xPL broadcast messages it receives to every application in his list.
Protocol
Lite on the wire, by design
Example
xPL Messages are line based, with each line ending with a linefeed (ASCII: 10 decimal) character. The following is an example of a typical xPL Message:
xpl-cmnd
{
hop=1
source=xpl-xplhal.myhouse
target=acme-cm12.server
}
x10.basic
{
command=dim
device=a1
level=75
}
Message Structure
All messages are made out of:
- The message type (xpl-cmnd, xpl-stat or xpl-trig)
- The header block, inside curly braces, containing:
- hop=n, the hop count which is incremented each time the xPL message is transferred from one physical network to another
- source=vendor_id-device_id.instance_id, which serves to identify the sender of the message
- target=vendor_id-device_id.instance_id, which serves to identify the destination of the message
- The message schema, in the format class.type
- The message body, inside curly braces, containing name=value pairs [6]
In the header block, the target name is replaced by the wildcard symbol "*" for broadcast messages. This is the case for tigger and status messages.
Message Schema
xPL uses well defined message schemas to ensure that applications from different vendors can interact sensibly. Message Schemas are extensible, and define not only the elements which should be present in a message, but also the order in which they appear.
This allows simple devices and applications to parse messages more easily.
All of the existing message schemas can be found on the xPL project home page. Developers looking to create a new schema are invited to do so. [7]
References
- ^ "About the Project". The xPL Project Web Site. Retrieved 23 April 2012.
- ^ Lansell, Mal. "xPL Primer". xPL Monkey Web Site. Retrieved 23 April 2012.
- ^ Lansell, Mal. "xPLMonkey Z-wave Page". xPL Monkey Web Site. Retrieved 23 April 2012.
- ^ Duprey, Gerald R, Jr (5 July 2008). "UPB4Java V1.2c - Java API for the UPB automation protocol". xPL4Java Web Site. Retrieved 23 April 2012.
{{cite web}}: CS1 maint: multiple names: authors list (link) - ^ "SqueezeboxWiki xPL Page". SqueezeboxWiki. Retrieved 23 April 2012.
- ^ "XPL Specification Document". The xPL Project Web Site. 3 August 2011. Retrieved 23 April 2012.
- ^ "xPL Project Documentation". The xPL Project Web Site. 3 August 2011. Retrieved 23 April 2012.
External links
Official
- xPL Home Automation Project homepage
- xPL Home Automation Project WIki
- xPL Forum
- xPL Project URL links