Re: Device discovery for control/sensor schemas

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

John B wrote:

>Hi all,
>
>Many of the recent xPL apps are making use of the sensor/control
schemas, as these make it much easier for devices to interoperate.
>
>However, there is no way of finding out a list of valid devices that a
particular xPL connector supports.
>
>
>
Within xPL and xAP we have each addressed some areas that the other
protocol  has not so bear with me if I draw a little bit on xAP here as
to where we went and also raise an issue at the end that exists in both
xAP and xPL that is still a discussion topic but related here. I'm doing
this because where possible I feel we should retain as much
compatability between the two protocols as  makes practical sense for
everyone. Obviously where there are large differences in view or
methodologies then the specs will diverge, but there's no sense in being
different for differents sake. If the xPL powers that be feel this is
'out of line' then drop me a line on or offlist and I'll put a sock in
it !  I'll probably get lambasted by both camps ;-)

xAP uses the concept of two part addressing  , one for the main
device (application or controller) and one for each endpoint that the
application/device handles, these are called sub addresses.
Source=<address>:<subaddress>    So in an example like DMX you
would
have a device called ACME.DMX.controller and it would have 256 endpoints
that would each have a name stored within the ACME.DMX controller. These
might be default names eg Channel01  or be programable if the device
could offer that feature.  Thus a xAP address might be
Source=ACME.DMX.controller:LoungeLight.  Thus we have a device 'as a
whole' we can talk to ask about its capabilities and also individual
endpoints.   Now xPL doesn't use this form of sub addressing but SteveC
suggested a 'master' device that would respond 'as a whole' on behalf of
all the endpoints - which is much the same sort of concept. I think
that's a good approach and provides some form of commonality between the
two approaches. We have found this to be a very approriate treatment in
xAP. It has worked really well for say for my implemenation of C-Bus.
If you do choose a different route then all well and good but feel free
to learn and borrow from us in the xAP world - as I would hope you would
offer the other way around. I know there were some suggestions to look
at the xPL config protocols and see if there was a similar approach we
could use in xAP.

As to the issue of names being retained centrally or by the device
we advocate the 'in the device' approach as Lehane also appears to.
Again if the device is not capable then we use default names eg Temp01
Temp02 .  However xAP is not currently so paired with a central
configuration engine like xPLHAL and we  wanted to be totally decoupled
so that was a choice made for perhpas different reasons.  We have also
looked at 'aliasing' names as an option.

I wanted also to mention xAP BSC - 'Basic Status and Control' - it
is a xAP low level schema that allows all our BINARY LEVEL or TEXT
devices to interoperate in a plug and play fashion, that is how we can
just drop into say HomeSeer. It also provides device discovery.  I see
that the xPL sensor/control.basic schema is veering this way too.  - I
wonder if there is some commonality again that we can bring in here such
that we can leverage each others BSC Sensor/Control devices in a hybrid
environment. Again I am looking to retain as much compatability before
divergence causes issues. We are after all both relatively small
communities with a few commited developers in each camp - duplication of
effort seems wasteful.

Lastly let me bring up something that bothers me in both the xPL and
xAP worlds and that is the mixing of context data with value data within
a block. Let me take for example an X10 block

{
device=A10
state=ON
)

The context is carried in the device= and a value in state=  but it's
only because of human interpretation that you can deduce this. Just
examining the message does not convey this.  Should you move to having a
computer track state of a device (eg a cache) then it becomes very awkward.


Now take this from an unkown schema

block.data
{
items=2
colour=red
value=5
state=ON
name=Lounge
}


How are these values related ?? For example is item 2 called Lounge ??
Or are there 2  items in Lounge and in the next xPL message there could
be 3 items in Lounge ? Likewise is the ON related to colour as in say a
traffic light such that when it was OFF then colour=none might be
displayed. Or are there 2 items that are 'ON' ?

It is this 'context' aspect that is awkard to convey in a message (if
you dont know the schema)  - I believe that we need a way of identifying
the context values separately from the value parameters - of course if
you always have access to the schema definitions (electronically) then
this is much less an issue. As you consider placing endpoint addressing
within a body you are effectivley hitting this issue head on.

Just some thoughts, I run a xAP / xPL hybrid environment so it makes
sense to me  - if all they do is steer xPL towards a different solution
totally then at least they were aired.

Kevin

PS Hope this was OK List Moderators ??  < /me opens mouth to receive
either an xPL or xAP sock -or both>  ??