Re: Device discovery for control/sensor schemas

["Frank Mc Alinden" <fmcalind@xxxxxxxxxxxxxx>]

Hi Kevin

>     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.

Thats sounds interesting, are you saying that xAP BSC allows ,Misterhouse
,Homeseer to become xAP enabled easily  ????

>It also provides device discovery

Do you mean ,when a new device sends out config hbeats ????

Frank


----- Original Message -----
From: "Kevin Hawkins" <lists@xxxxxxx>
To: <ukha_xpl@xxxxxxx>
Sent: Thursday, November 25, 2004 10:45 AM
Subject: Re: [ukha_xpl] Device discovery for control/sensor schemas


>
> 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>  ??
>
>
>
>
>
>
>
> 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
> Yahoo! Groups Links
>
>
>
>
>
>
>
>