Re: Re: Addressing vs sub-adressing

[Kevin Hawkins <yahoogroupskh@xxxxxxxxxxxxxx>]

Patrick Giasson wrote:
>> Well yes but you have three xAP applications (devices) now and
each
>> will have the responsibilities and overhead outlined above which
>> wastes codespace and time. Maybe I'm missing something but I don't
>>
> see
>
>> any advantage , and see disadvantages, compared with
>>
>> elperepat.node.master:blind.southeastwindow
>> elperepat.node.master:display.bedroom
>> elperepat.node.master:sensor.outdoor:temperature
>>
>> elperepat.node.master:sensor.indoor:temperature
>> elperepat.node.master:serial.connection.callerID
>>
>> now only one xAP device
>> elperepat.node.master
>>
>>
>
>
> Ok, thanks! I didn't looked at the implication of that scheme on the
> overhead (protocol).
> I can also see the limitation of having only 255 subaddresses. Any
> clue on the official release of the new protocol definition? I'll
> certainly benefit the new 65535 limit!
>
> Thanks
>
> Patrick
>
TBH Patrick it's an embarrasment that the spec hasn't been formally
published. It's only a minor update, primarily to address that UID
restriction,  and most aspects of it  are totally agreed but a couple of
issues still need finalising and when you have a open group trying to
agree , it can take time.    I have circulated a document to people last
week and I hope it will be published within the next couple of weeks.
Some aspects we have already deferred to xAP v1.4 to speed things up but
all these layer on top of the existing protocol - however the xAPv1.3
UID change may require updates.  So you can start to code for xAP v1.3 now.

You should take it that the v1.3  UID format is

UID=NN:AAAA:SS

where each segment is not formally limited in size but we recommend that
NN is 2 digits
AA is 4 or 6 digits but 8 digits will be in use,  allocated on a vendor
basis as reserved address space
SS can be 2 ,4 or 6 digits maybe 8.

all zeroes and FF's are reserved in all segments

The new version number is 13 ie
v=13

There are carry over ramifications to the TSC and BSC schema in that
ID=xx  can now be longer ie 6 uppercase hex digits (maybe 8)

You can also take it that heartbeat messages can now include a body part
now , and as a gernal principle you should handle unexpected parameters
in headers or bodies gracefully ie just ignore them.

I should also mention that the TSC schema you are using is new and may
be revised - your input on this schema will be much appreciated, it is
pretty capable and will become a 'core' schema.    xAPBSC which is a
simpler schema is very well supported and already useful as a 'core'
schema.  It would be advantageous for you to use BSC where the
capabilities are appropriate eg binary I/O as this will give you
maiximum interoperability with other BSC applications and devices.

There are already several xAP v1.3 applications out there, (HomeSeer
plugin, HouseBot plugin, C-Bus gateway, HomeVision gateway, the opnmax
embedded xAP controller ). We have been touting these changes for a
while now and most applications/devices are now either indifferent to
the changes or support them.  The xFX .Net development framework, tools
, hubs and Viewer have all been updated to support xAP v1.3 already

Just as an example here's a xAPBSC message from the HomeVision gateway

xap-header
{
v=13
hop=1
uid=FF.6DFF:0103
class=xAPBSC.info
source=UKUSA.gateway.HomeVision:X10.Courtyard.Floods
}
output.state
{
state=On
level=32/32
}


Kevin