RE: xAP xPL EIB C-BUS X10 - choice overload!

["Kevin Hawkins" <lists@xxxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: Doogie Brodie [mailto:ukhad@xxxxxxx]
> Sent: 16 March 2004 23:20
> To: ukha_d@xxxxxxx
> Subject: Re: [ukha_d] xAP xPL EIB C-BUS X10 - choice overload!
>
> John B wrote:
> > You can use xPLHal (http://www.xplhal.com/) to bridge
> between xPL and xAP.
> > For example, a message initiated by an xPL device could
> be picked up by xPLHal, which would then send out an xAP
> message to be actioned by Kevin's C-Bus interface.
> >
> > This basically means you can mix and match between xPL
> and xAP devices as you please, however you need to
> remember that xPLHal is the single point where the two
> protocols merge, and any bridging you do must be
> configured manually - there are sufficient differences
> between the protocols to prevent any form of automatic bridging.
> >
> > Despite this, a number of people (myself included) are
> successfully using both xAP and xPL in a single, fully
> integrated environment.

I use a combination of xAP and xPL in my own setup although I am
predominantly xAP by choice. I use xPL to provide a couple of applications
that xAP does not currently have and I guess John does the same in reverse.
It's a useful 'mix and match' feature.

>
> Aha! So in theory (and practice ! ?) there'd be nothing
> stopping me from running xPL for absolutely everything,
> and having xPLHal bridge that to xAP to Kevin's xAP ->
> C-Bus gateway which would then bridge it to C-Bus ?
>
> So something would generate an xPL message that would go
>
> xPL message -> xPLHal -> xAP message -> xAP to C-Bus
> gateway -> C-Bus

YEP ! And vv

>
> Cool. Are there likely to be any appreciable delays/
> technical hitches with this compared to sending
>
> xAP message -> xAP to C-Bus gateway -> C-Bus
>

Short question - long answer... here goes ...


The 'non compatible' comment I made was that the two protocols by
themselves present information in different ways and also use different IP
ports so are 'blind' to each other. xPLHAL provides a degree of
interoperability as it has a scriptable bridge however it can not currently
represent itself as a true xAP device as it is still lacking certain bits -
for example xAP heartbeats and header parameter manipulation.

The design of xAP and xPL is such that content can not truly be represented
& translated across the protocols - for example xAP uses a 'UID' which
is
like a shortform address used for easy identification and addressing and
additional to this we use a longform text xAP address which is essentially
a
human readable string of unrestricted length and hierarchy. xPL took the
middle ground and defined a single more rigid (limited length) addressing
structure that sits somewhere between these two. This (as one example) can
lead to problems in translation between the two. You are faced with
truncation andor originating data not present in the incoming message.

Additionally the C-Bus xAP interface makes use of a feature in xAP called
hardware sub addressing where each endpoint on C-Bus represents itself as a
unique xAP hardware address which is a hierarchical subset of the main
application address - a sort of

Kevin.CBus.Controller:BedsideLights

-notice the bit after the : where BedsideLights are an endpoint (group) on
the C-Bus network.

This means that each C-Bus group reports its status and can be targeted as
an individual item for control. xPL does not support hardware endpoints
within the header addressing structure and instead adds this information
(if
needed) intermixed with the data payload in the message body. This is just
a
matter of policy and choice within the protocol spec.  Additionally the xAP
C-Bus implementation uses multiple 'bodies' within one message - for
example
a very basic and a more complex status command can be grouped together and
sent in one UDP packet. In xPL (via a bridge) these would have to be
combined into one body or sent as separate messages which disjoints the
information.

Now although the above paragraph sounds like xAP was more suitable it is
simply because I am familiar with it & it was coded this way. If I had
chosen to do an xPL implementation for C-Bus I think I could have worked it
the other way around and then translating this to xAP would appear
problematic. For me C-Bus fell naturally into the xAP model though.  Much
of
the general 'status' and 'control' information can be translated between
xAP
and xPL using xPLHAL and a clever bit of scripting could almost do anything
in terms of message content translation.

Indeed it is my intent with the design of the xAP schemas that are used
within C-Bus (for example the 'lighting' schema) to purposefully make sure
they can be translated in a meaningful manner to and from xPL. If anything
remained problematic I would be happy to supplement the information in a
way
that would aid this interoperability with xPL. I am not here to fight an
xPL
v xAP war - indeed I personally am very sorry this divided situation exists
as I feel it is detrimental to the adoption of both. The more people we can
get using xWhatever the better. I am not sure I would go so far as to code
xPL directly within my controller but if there was significant demand then
I
might be swayed.

So Doogie - yes you should be able to translate C-Bus xAP 'status' ,
'event'
and 'control' in a meaningfull way between xAP and xPL - true you double
the
network traffic in doing this and increase by 4 potentially the latency
(xPL
to xAP and back) but it will be workable and to all intents and purposes on
an Ethernet network it will be near instantaneous still. As most 'event'
critical actions will be coded natively within C-Bus this is a mute issue
anyway. Most xAP and C-Bus interactions will be simple actions like
scheduledperiodic events. The very time critical light switch > lamp ON
will most likely be a native C-Bus event.

I hope this is impartial and informative - it is certainly not in any way
meant to be a xAP vs xPL debate but to illustrate that the same things are
achieved by both protocols but in different ways.

Kevin