The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xAP/xPL and Rabbits....



There's no Rabbit code for xPL (at the moment at any rate)

Currently all of the xPL hardware development is PIC based, just as the PC
application development is all Windows based at present. For clarification,
xPL is a fork from the original xAP Protocol, and is *not* the same thing,
and the two are not compatible (although they can happily co-exist on the
same network).

xPL takes a slightly different approach to xAP, but with pretty much the
same set of design goals: by the nature of these things, there is a fair
bit
of overlap. For anyone interested, the key differences between xAP and xPL
(from an xPL point of view, of course) are:

Broadcast Only vs Broadcast + Directed
xAP is intended as a broadcast only protocol, with obstacles against using
simple messages sent from one device to another for control purposes. the
underlying assumption is that end nodes have the intelligence to respond to
the status information contained within messages, and act accordingly. xPL
uses messages explicitly directed from one node to another where required.

Header as Frequently Used Fields vs Header as Addressing Block
Over several scenarios, it has been reinforced that xAP views the message
header as the location to store frequently used fields, whereas
"addressing"
elements may be contained within either the header, or as message body
"class.type" section titles. xPL on the other hand, views the
header (which
is fixed) as a block of addressing information, with all actual application
data being contained within the message body.

Mandatory vs Optional Heartbeats
xAP applications or devices may elect not to send a heartbeat packet.
Within
an xPL evironment, every node must generate a regular heartbeat.


Implicit vs Explicit Message Style
All xAP messages on a network begin with the identifier xap-header. In
contrast, xPL messages belong to three distinct styles, which allows for
very fast parsing of the message:

XPL-CMND - Command Messages
XPL-STAT - Status Messages (including Heartbeats)
XPL-TRIG - Trigger Event Messages

Variable vs Fixed Field Size
xAP's design goals call for human legibility within messages. As such, the
elements within a xAP message may be of considerable size. xPL trades some
of the human readability in return for easier handling of messages by small
devices.

Distributed Control vs Central Intelligence
xAP's initial design goal calls for a fully distributed control, without a
central controller. This goal has softened as the harsh realities of
implementing real world systems have arisen. Within an xPL environment, a
central intelligent controller is likely to be required, to act as a
scripting engine, to map Trigger events to command actions, and to respond
to status changes. There can easily be multiple controllers, and they would
not need to be a full blown PC: a suitably powerful microcontroller based
system should suffice.

Multiple vs Single Message Bodies
xAP supports multiple message bodies, to allow complex scenes to be
constructed with a single message. xPL on the other hand, supports a single
message body only, instead opting to send a number of simpler messages to
different systems.

Heirarchical Message Schemas
xPL mandates certain basic behaviours from each message class. Whereas the
relationship between xAP classes and types remains open to developer
interpretation, all xPL classes must define a .basic message type. The
contents and order of the elements within all types belonging to a given
class  are inherited from the basic type, allowing developers to extend the
types with confidence of compatibility.

There's more information at: http://www.xplproject.org.uk
(although, not
much more, as we are kinda busy doing documentation for the existing
applications just now!!)

Ian.



Home | Main Index | Thread Index

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.