[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
xAP Extended UID (from Some xAP Question)
- Subject: xAP Extended UID (from Some xAP Question)
- From: "g8kmh" <g8kmh@xxxxxxxxxxx>
- Date: Tue, 21 Feb 2006 11:49:15 -0000
<snip>
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
<snip>
Clearly extending the UID is required but I'd suggest that it is a
fixed length and without delimeters. So FFA5000000000001 would be OK.
Otherwise the effort to parse a UID is going to be pretty close to
that for a normal V.D.I:SS address format, then one questions why
have a UID?
I'm perhaps being paroichial but in my PIC implementations I'd be
interested in the UID as a number not as a string.
Lehane
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|