Re: UID (was Re: Re: Message Etiquette_

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Jon Payne wrote:
> Hi all,
>
> I've never really understood the point of the UID. I'd be interested
in knowing if anyone actually uses it?
>
Yes - I do fairly extensively, mainly to uniquely recognise xAP devices
without having to store their much longer source addresses. Based on the
current UID format all devices and every endpoint within that device
(sub addresses)  can be uniquely identified using just 3 bytes which is
very efficient :-)  Controllers use the UID for the same reasons - it is
much faster and easier than matching against source address and also the
various device mappers use it.  Additionally the very popular xAP BSC
schema uses the sub addressing aspect of the UID to provide coincident
(multi block) addressing of devices by placing an ID= parameter within
each block.   I use BSC extensively.  It's the xAP equivalent of 'plug
and play'.
> For me it's just a pain, I have to create a 16bit number that is
unique to the device, somehow... At the moment this just causes me extra
CPU time - Adding an extra unnesessary field (to me!) to the message, which
takes time (on a resource contrained device, in this case a TINI), and to
hopefully make it unique by hashing the actual 'source' field text.
>
You don't have to 'compute' this onboard at all so that part shouldn't
be resource intensive  - just ensure it's unique on your network,  and
the network designer is fully in control of that aspect . You could
hardcode it even or have it just configurable . Using a hash is a good
mechanism however and we intend to recommend a formal hash algorithm for
the later UID's , it may not be guaranteed unique but its pretty close.
.I agree it adds a few extra bytes to each message which takes longer to
send on a serial type network but in return you get significant
codespace savings both in the algorithms needed to parse and identify
incoming addresses and the storage requirements for same. That aspect
has always been where my embedded devices have greatly benefited. We
also talked about providing a small PC application that you 'target' and
it responds immediately with an already hashed UID of your address and
will warn you should it not be unique due to a similar hash. .  If you
have no use for incoming UID's then of course just ignore them, but it
is strongly recommended you have an algorithm that handles the new UID
format as otherwise new format messages might break you.  For others
reading this -  just to clarify one aspect -  you can't target a xAP
device by using it's UID (as that defeats wildcarding), you must use the
complete address. You can also choose to implement a xAP network with
very short addresses should you wish to.
> In that respect I prefer xPL. But I'm probably not allowed to say that
here am I? ;-)
>
I am not a great fan of the xAP/xPL divisions/derisions so I don't see
why not if it's a constructive comment . The reverse issue though is
that xPL can't identify devices uniquely in 3 bytes can it  ?  That must
be a very valuable feature in a small space device like a Tini isn't it
?  Neither xAP nor xPL offer the smallest possible (ie highly compacted)
serial protocols. Other bitmapped protocols like like SNAP are in this
area  - but obviously anything that is humanly readable can't be , you
trade one for another. Where xAP messages score is that they are nicely
efficient,  easy to understand and code and offer great expansion
possibilities compared with almost all alternatives.

Also the xAP UID format coupled with the sub addressing aspect of the
xAP source address very neatly groups a parent device and it's multiple
endpoints. Also should you wish you can further group endpoints by the
naming hierarchy - as the xAP Netiom does for example using its default
names.  Again (as far as I understand it) xPL doesn't cater for this and
doesn't easily allow groups of endpoints or the 'whole'
device/application to be addressed within the base protocol  . xPL does
however  have a number of higher level schema covering some categories
(eg lighting) that you can recursively drill down asking for more detail
as they approach endpoints, which is a more complex mechanism with more
two way interactions.

source=Phaedrus.Netiom.control:input.1        UID=FF111101
source=Phaedrus.Netiom.control:input.2        UID=FF111102

source=Phaedrus.Netiom.control:output.1       UID=FF111109
source=Phaedrus.Netiom.control:output.2       UID=FF11110A

etc


> Personally I'm protocol agnostic and use whichever gives the most
benefit but the killer apps for me are Switchboard, Floorplan and Speedfan,
so I use xAP and work around the additional complexity it has over xPL.
>
James will be pleased .. 2 out of 3  :-)  Actually that's exactly as it
should be - pick and choose and adopt what you want - that's exactly
what xAP is there to facilitate.

All of the extra features of xAP over xPL in the base protocol offer
extra features that are useful to some , but not all people. We tried to
design xAP so that it could offer a range of features that appealed from
hobbyist upwards into commercial applications. The base xPL protocol can
be totally encapsulated within a xAP message as it is effectively a
subset in its basic structure, and it was designed exactly for that
purpose - to be simpler for HA enthusiasts to achieve what they needed.
You don't have to use these extra xAP features should you not wish
although obviously you must adhere to the minimal xAP message
specification. Wildcarding is a good example - if it's something you
wont be using then you needn't code support for it.   There are other
higher layered protocols on top of both xAP and xPL that do further
differentiate them and certainly in this area xPL should not be regarded
as lighter than xAP - inevitably the more features you offer the more
complicated it becomes. In this higher layer each protocol has
advantages and disadvantages, most of which are based on offering
features the other has not yet released or completed.

xAP and xPL are user supported , evolving efforts and resource at the
moment is the biggest restriction. Time and effort. We both need users
asking questions and making suggestions and in particular contributing
examples, code , documentation,  schema and protocol ideas and most
importantly  'how to docs'  for novices. There's an area here everyone
who uses xAP/xPL can help in.

Kevin

>