Some xAP question

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Here are some questions that Ron from Promixis asked me  that I have
copied here (with his permission) as I think they are useful to others..

Kevin




Some questions/suggestions:

1.  How is it decided which UID a device receives anyway?


Currently it is just how the installer chooses/sets it up. When we move
to the newer UID format which BTW is likely to be

UID=  NN.AAAAAA:SSSSSS      where the N A and S fields can be of any
length, note the . and : which reflect source address structures

We will probably recommend some lengths for the A and S fields as in 8:6
6:8 or 6:6 as above for example.  This will allow us to address three
key issues

1) The A (address) part of the UID will have sufficient size to allow us
to allocate ranges to specific vendors - rather like a MAC address
2) We will probably suggest that the remaining applications calculate
the A portion of the UID using a hash/checksum of their longform source
address - and hence very likely all UID's will end up being self
generated and unique
3) The S (sub address) part of the address will no longer have a 256
(actually 254) restriction - this avoids single applications/devices
having to actually represent themselves as several devices on xAP in
order to accomodate more than 254 endpoints.  Automation controllers
inparticular suffer from this currently - as does such legacy models as X10

> 2. From my initial dealings with xAP I have noticed that when
connected
> through a hub and the sender is on the same hub you get messages
> multiple times. I could write something that suppresses the messages
> if the are identical within 10ms, however that might not be
> sufficient/stable enough if UDP messages travel bigger networks things
> might get ugly. Is there anyway to add an identifier to messages?
>
You shouldn't see any repeats of the messages - is it possible you have
several network interfaces installed in that machine ? There is a
configuration option for the hubs, in the config file which allocates a
primary network interface and can remove such echoes.   Have a rummage
on the xAp Automation groups to see if you can find a thread a while
back re this. If you struggle give me a shout and I'll try and locate
it.  I would be against any form of forceful echo suppression as it
indicates another problem and shouldn't be necessary.  <snip>
> 3. It would be great if we had discovery of device CLASSES! We will
> need that in our project. For example we want to be able to ask the
> network for any *.thermostat.> class out there and they should all
> respond.... (Yes I know a keeping a cache would work, but then you'd
> need to wait for the maximum heartbeat timeout). Any ideas?
>
There is a bit of a gap currently in device discovery and configuration
with xAP. Essentially every time we try and come up with a solution it
turns into minefield of opinions and related issues , and as xAP is an
open development project that causes us to constantly delay things.  The
wildcard system allows you to target all devices in a fairly focussed
way although the corresponding mechanism is not defined. If you take a
look at the BSC v1.3 (Basic Status and Control) schema you will note
that this does support discovery in a limited sense as  you can force
status responses using  a BSC.query class.  In practice (and if your
devices are being coded by yourself) then I would suggest moulding teh
BSC.query class to a more general device.query or something and using
that to probe for devices and state/capability.  We will probably later
recommend such a usage anyway and many devices already respond to a
.query type of schema anyway.  Do study the BSC schema - it has proved
very flexible and goes some way towards 'plug and play' for simple
devices.  Just in case its useful to you in your project I will mention
that there is also a commercial hardware I/O board called the xAP Netiom
that has lots of digital, analog and serial I/O onboard and an Ethernet
interface - all implemented using xAP and the BSC schema. Made by
Phaedrus Ltd
> 4. Why broadcast as opposed to multicast?
>
Not sure... would have to ask Patrick on this one - is there any extra
overhead in code required to implement multicast I wonder.  Maybe also
we could have a multicast PC based bridge application to bring this
feature in . Also just for info we have some TCP based xAP bridges (with
security) for internet use, and for Crestron and AMX integration I have
had to use these due to packet size/broadcast address issues with their
firmware UDP implementation.