Re: Device discovery for control/sensor schemas

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

John B wrote:

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

>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.
>
>
Yes - that's essentially just a different approach to the same thing -
xAP has all  the addressing in the header and xPL divided between header
and the block. As xPL uses single blocks this is a workable approach to
address within the block itself , xAP with multiple blocks requires the
addressing to be a level above to embrace all blocks.

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

Yep - that's what I was saying too. (I wasn't in any way implying
changing the xPL addressing constructs) - just that the 'master'
approach has worked well for us and would provide some commonality
between the two protocols.

>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.
>
>
>
>> <snip>
>>
>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.
>
>
Yep - having a fairly consistent 'basic device status / control"
mechanism in both protocols would aid the semi intelligent bridging of
the two protocols (at this schema level anyay ) and lower the 'need to
script' barrier - This would allow basic switches and I/O devices
including sensors to be compatible across the protocols. Given that
embedded hardware is costly to develop (and sparse) this would be a good
thing for both protocols. The C-Bus hardware controller for example uses
BSC  as well as a richer lighting schema. Happy to see what we can do to
improve compatability here.

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

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

Me neither - and of course within xPL where you have addressing of
endpoints carried within the schema body it is a larger issue. This is
one of the obstacles to providing any intelligent bridging. We discussed
using different key value identifier eg

{
DEVICE=A10
state=on
}

capitalisation of key values (heavilly criticised by the software guys)
or perhaps device:=     device#=     @device=    #device= or something
- we had a couple of other more technical solutions too. But it's still
pending.  Maybe an intelligent bridge or cache would always have access
to the schema detail .  It also causes an issue where you try and create
a central controller (state engine) if the schema is unknown, you have
to drop back to scripting each device and multiple (context) key value
tests to recover values.

K

[campaigning to make life easier in a mixed xPL / xAP world]

>
>Regards,
>
>John
>
>
>