Re: Device discovery for control/sensor schemas

["John B" <home-automation@xxxxxxxxxxxxxxxx>]

Hi Kevin,

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

Basically in xPL we decided to move addressing of individual endpoints from
the header into a body element.
So, the source/target addresses in the header only identify the xPL
connector on the network, and an element within the body is used to
identify a particular endpoint supported by the connector.

So, for C-Bus:

xpl-cmnd
{
hop=1
source=xpl-xplhal.server
target=johnb-cgate.server
}
control.basic
{
device=3
type=cbus
current=off
}

The above message switches off C-Bus group address 3.
The specific endpoint to be addressed by the C-Gate connector is implied by
the device= element.

What we're saying I think, is to have a special device=master, which
indicates that the message is aimed at the connector itself, rather than
specifically at an endpoint.

As you say, this has worked well in the past for the work that Steve has
done, so it seems logical to extend it's use.

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

OK, it seems most people think device names should be stored by the device,
rather than centrally,
so I think we'll go with that approach.

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

It may be that BSC can interoperate easier with xPL through sensor/control
schemas, but it's not something I've looked into.
Ideally having a more intelligent bridge between BSC and sensor/control
schemas could be possible - reducing the need for custom
scripting.

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

True. With control/sensor schemas, this is not currently an issue, as the
context is implied by the device element.
However, as you say, for an unknown schema, it is impossible to tell.

I'm not sure of the best solution though.

Regards,

John