Re: Discovery question

["Kevin Hawkins" <yahoogroupskh@xxxxxxxxxxxxxx>]

--- In xAP_developer@xxxxxxx, "neil.wrightson"
<neilw@...> wrote:

> 1.	Using your example, a new piece of hardware has been purchased and
plugged into the network, i.e. NWS.IOController. What typically sets the
UID field i.e. UID=1234. Who defines / sets this? Would this for example be
a serial number that is set at the factory? Or perhaps a Dip Switch on the
controller board?

It is up to the device vendor or the installer to ensure that UID's are
unique on the network. Some (most) devices have end user configurable UID's
and some derive a UID from internal information like MAC/IP address or as
you say DIP switches - or a number held in firmware/NVRam.

As UID's are longer now there is much less risk of duplication and we have
talked about being able to allocate unique ranges to a vendor if that seems
appropriate (similar to MAC addresses).

>
> 2.	The name NWS.IOController would I presume be hardcoded into the
firmware of this device?

Yes

>
> 3.	How is the "instance" part of the name assigned to the
device? Given that the device is a UDP device with 8 inputs & 8
outputs. Is there a facility/application/protocol in xAP to edit the
"instance" and Endpoint names?

Again you can offer this how you wish - either with a config utility or via
a web interface - or even perhaps using a schema like BSC to name
endpoints.  There is no specific schema as such but a BSC text enpoint with
NVRam storage would be very suitable.

>
> 4.	From the PC perspective, how do you know what the capabilities of
the new xAP device are? I.e. when the query is sent should all of the 8
inputs and 8 outputs of the device respond even if they don't have ASCII
names?

If you are using BSC then the I/O is broken into the three types of
binary/level/text which covers most 'simple' and additionally input or
output.  Within a level device the granularity and range is also defined.
For a more complex device the TSC (Telemetry) schema may be more
appropriate.

All enabled BSC I/O must be ASCII named and unique.   The named I/O that
matches the target should respond. Given the target may be wildcarded eg
the following might just ask for the inputs. Unused (unnamed) I/O should
not respond.

target=NWS.IOController.Master:input.>

>
> 5.	In your reply you refer to the UID as having a ":"
between the address and the subaddress i.e. uid=FF1234:00 but in the schema
specification http://www.xapautomation.org/images/a/a2/BSCv13.pdf
it does not have a ":" i.e. uid=FF123400. Which is correct?

There is a revision of the xAP spec from xAP v1.2 to xAP v1.3 (not to be
confused with BSC v1.3).  The primary change in xAP v1.3 is that the UID
field is changed to the format I described.  ie 3 segments separated by a
'.' and then a ':' The network N, Application A and Subaddress S

uid=<NN>.<AAAA>:<SSSSSS>
eg uid=FF.123456:789A

The xAP v1.2 uid=FF654307 is directly equivalent to a xAP v1.3
uid=FF.6543:07

The segments can be any desired even number of digits length although there
are recommended formats.

FF 2 uppercase hex digits
AA 4 or 6 digits
SS 2,4,6 or 8 digits

> Actually, with further searching, I cannot find any reference on the
xAP site where the ":" is used in the UID field?

The website only holds the official xAP v1.2 spec and the xAP v1.3 spec is
not formally published - it's a real embarrassment !! and it is imminent
but the information on the changes are widely discussed on this list.  Many
xAP v1.3 applications do already exist.

>
> 6.	You seem to infer (and so does the general xAP spec) that an
application on the PC basically ignores the instance and Endpoint ASCII
names, instead it uses the UID. Is this correct?

No.. The ASCII names allow for naming of the device using human readable
text, and importantly allow the use of wildcarding to address subsets of
devices or endpoints. This is the main way devices interact.  It is only
possible to target a device by its source name (not by the UID).

The UID was created and is used by some embedded devices (for example my
gateway) to allow devices to be identified with minimal storage
requirements and speedy matching. Storing all the long source names of
devices eats memory in small memory devices eg a PIC processor. A UID can
typically be stored in 4-8 bytes. However to originate a message to a
specific device requires you to use the long form ASCII address.

Again there are ways to optimise this for example by a lookup table that
reconstructs a stored UID back into a source address where the application
<AAAA> part of the address is stored separately from the endpoints
<SS> and then paired . This is the approach my gateway takes and in
fact I can rebuild any BSC full source address from a stored UID within 60
secs of startup.

Keep asking if you've got more questions ....

Cheers K


>
>
> Thanks,
>
> Neil.
>




------------------------------------