RE: New User questions re Hardware interface and what protocol.

["Ian Lowe" <ian@xxxxxxxxxxxxxxxxxx>]

Hi Neil - I see that frank has already welcomed you to the group, let me
repeat that, and hopefully answer some of the questions you have. (deep
breath, this is a biiiiig mail ;) )

>I'm also going to build the following
>	- 1Wire Interface. This does all of the polling not MH.
>	- Standalone LCD display with a 4*4 keyboard
>	- User Interface Terminal, with LCD display and the following
options
>		4*4 keyboard
>		Sound (Be able to play Ring Tones from Mobile phones)
>		IR Transmission
>		IR Receiving
>		I/O for interfacing to PIR movement sensors and direct
control of lights.
>		RS485 Interface
>I was thinking of having one of these per room. Or at least a cut down
version for
>places like the garage etc.

That's a helluva list, and fits right where we want to be in terms of
new development :)

> Hence the question. What is a better Interface to support xPL or xAP
or ???
> I guess you would say XPL, but why?

Indeed we would. There are a couple of xap developers on the list, so
I'll pre-empt what comes next with the usual disclaimer - this is from
the xPL point of view, and not an attempt to be balanced.

Firt though, this question is easy:

>Could you point me in the relevant area for things like RS485 comms
etc.

There isn't anything yet - it's an area where we don't have a lot of
expertise, some of us (myself included) have dabbled with PIC/RS485
solutions, but are lacking a good solid platform. If you are in the
position to help define and tighten up xPL behaviour over xPL, we'd
greatly appreciate it.

Now for the quick rundown of why to use xPL, rather than xAP. (this is
basically a rehash of a post I made to the MH mailing list a while back
:) )

Both xAP and xPL have been developed in the main by members of the UKHA
community, and there"s still enough general bad feeling about the fork
(and the
arguments that lead up to it) that serious discussions about the
technical reasons for the split tend to disintegrate.

In order to maintain good spirit in the community, we (both sides) have
had to essentially bite our tongues. It"s not necessarily a bad thing,
as it has forced us to become more "results oriented".

That being said, I"ll summarise the xPL position here -

xAP went through a few revisions as the concept was originally thrashed
out - the key version of the protocol specification being the v0.9
document. Development from this point resulted in the v1.2 protocol
document - which was largely unacceptable to those of us who went on to
become the xPL team.

xAP (and xPL) have similar semantics - messages are in human readable
ASCII text, and the messages are enclosed in { } braces. The key
differences are -

1) Distinct message types - to xAP, all messages are created equal - a
message"s intent can only be determined by fully parsing it. Within
xPL,
three specific message types exist xpl_cmnd, xpl_trig and xpl_stat. A
message can be a command to a device (or group of devices), a trigger
indicating a state change, or a status update (with info such as
temperature etc). A single byte test (byte 5 of the xPL message = c, s
or t) can determine the message intent.

2) Strict Header - The elements within an xPL message header are fixed
order, and only these elements (hopcount, source device, target device)
can be present. In contrast, xAP allows developer added fields to be
placed in the header. xPLs view the header as an addressing block, xAP
views it as "frequently used info"

3) Size limits - structural elements are tightly size limited in xPL -
to keep message size down, and also to assist Microcontrollers in
parsing the protocol. In "item=value" tags, the "item"
name cannot be
longer than 16 bytes. xAP places no restriction on this length,
essentially making every element delimited.

4) Character Set - only lower case Alphanumeric characters are
permissible as structural elements in an xPL message. xAP used to allow
pretty much any character, apart from the actual delimiters, making for
some pretty awkward device names. (note: this was the case until about 8
months ago, it appears to have been changed, but the xAP protocol
document remains at v1.2)

5) Message Body - xPL messages have two sections - header, and data,
also viewable as address and payload. xAP supports multiple message
bodies, that may, or may not, contain the same sort of information, or
be "intended" for the same device.

6) "Pure Broadcast" vs "Targetting" - which brings us
nicely to one of
the key issues to cause the split between xAP and xPL. The fact that
both protocols use UDP datagrams on Ethernet (inherently a broadcast
environment) has lead to the statement by xAP developers that
"it"s all
broadcast anyway".

Whereas a xAP message is supposedly sent with no intent and simply
broadcast into the ether for whoever wants it (in theory, all xAP
messages are simply status messages, and nodes are pre-programmed to
react to given messages/message types/source addresses etc), xPL makes a
distinction between status, triggers and commands.

xPL uses the contents of the header target address to determine how to
handle a given message - "if a message is targeted at me, I must act
on
it, if it is broadcast, I may act on it, if it is targeted at someone
else, I must not act on it".

I say "supposedly" because it"s pretty clear that you quite
often
*want* to send a message to a specific device, and that some messages
are
placed on the wire with the specific intention of being acted on by a
given device.

The "Target=" element within a xAP message is optional (and
tellingly,
most of the examples within the xAP protocol document do not have it
included). The xPL developers felt that a non mandatory "target"
field
(developers do not have to even implement it) weakened the protocol
immensely.

7) End node intelligence, vs Central Network intelligence - a further
issue was the overall design philosophy - xPL unashamedly states that a
centralised intelligence on the network is needed for anything but the
simplest of tasks - xplHal performs this function, although other
systems (such as MH) could easily do so. xPL end nodes send status
messages and triggers, and act on commands - an intelligence on the
network acts on the status/triggers and issues commands.

xAP adopts a distributed intelligence model - end nodes are responsible
for all processing decisions.

Take the example of a display oriented environment - you have several
LCD displays around the house, an OSD for your video feed, a popup
application on your PC desktop - you wish to add a new information
source to this environment.

In xPL, you install your new info source, then configure xPLHal to send
the information received to each of the display devices using a script.
If you wish to add additional factors, such as time of day or
occupancy, you simply script these in. Also, if you wish to reformat the
data, it"s
trivial to do so, and send different versions of the data to different
devices.

In xAP, if you wish every device to display the information exactly as
it comes from the new device, you do nothing - it will appear everywhere
at once. If you prefer a more intelligent behaviour, then each end node
must be configured individually to react to only certain messages. If
you want the end nodes to react to certain messages at certain times
(ie, daytime/nightime), then each end node must support the
functionality you wish to use as a criterion. In practice it"s very
difficult to get a xAP node to react one way to given message at a given
time, and another way at others. Similarly, sending differently
formatted data to each device requires the end node to be configured
each time.

This list isn"t exhaustive, but it"s a good starting position. On
the
issue of suitability, you must remember that I"m partisan, and
therefore
biased. That being said, I think Occam"s Razor applies -  "Of two
equivalent theories or explanations, all other things being equal, the
simpler one is to be preferred."

We have found nothing within the HA environment that can be done with
xAP, that cannot be done equally as well (and usually better) by xPL,
with the benefits of more compact and strict messages.


Since I wrote the above, there have been some changes in the xAP
environment, most notably the emergence of the xAP desktop a (very sexy
;)) display  allowing information to be aggregated onto the windows
desktop and the BCS (basic control schema?).

BCS is probably the most significant in terms of network usage - as it's
a direct attempt to fix one of xap's biggest problems. Packet structure
is so freeform that essentialy two applications can conform exactly to
the protocol standard, yet be utterly incomprehensible to each other.
The xap developer has a dazzling array of addressing mechanisms and ways
of formatting data within the packet, therefore interoperability is
dependant on the developers of two apps knowing each other and working
closely on the code. BCS attempts to resolve this be defining a message
schema for basic control tasks. (somewhat similar to the control.basic
and sensor.basic xpl schemas)

One of the features provided by the xAP desktop in addition to
information aggregation is to act as a pinboard allowing BCS aware xAP
apps to talk to be mapped together. This is (in our opinion) clear
vindication of the xPL position that a centralised controller is
required for all but the most simple of tasks.

xPL doesn't have the same issue - our message schemas have a defined
inheritance mechanism, allowing a vendor's implementation of the OSD
Schema (for instance) to implement extra features, but ensuring that the
OSD.BASIC elements are always present in the packet in the correct place
- we also require that developers provide a series of XML fragments to
describe the services and information provided by their applications,
allowing for intelligent configuration straight out of the box.

Ian.

PS> Misterhouse is actually something of a rogue application in that it
doesn't implement the hub protocol properly, and has no defined XML
Fragment. We would really like to get MH compliant - not to mention that
the Determinator architecture we have developed should be portable to
any platform, and allow complete interoperability between xPLHal on
windows and Misterhouse on Linux. If you can help in this regard, we
would be very grateful!




xPL Links: http://www.xplproject.org.uk http://www.xplhal.com http://www.xpl.myby.co.uk
To Post a Message: ukha_xpl@xxxxxxx
To Subscribe:  ukha_xpl-subscribe@xxxxxxx
To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx