The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: UID (was Re: Re: Message Etiquette_



------=_Part_58771_16723242.1176820334476
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

The UID was designed for devices just like the tini - it's an abbreviation
address which allows you to quickly identify if a message is "for
you". I've
used it on the PIC. It can also be useful as a tool for originating the
sender in what is otherwise an anonymous medium.

If there was a strong consensus, we could look at deprecating it?

Patrick

On 4/17/07, Jon Payne <jgpayne@xxxxxxx> wrote:
>
> Hi all,
>
> I've never really understood the point of the UID. I'd be interested
in
> knowing if anyone actually uses it?
>
> 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.
>
> In that respect I prefer xPL. But I'm probably not allowed to say that
> here am I? ;-)
>
> 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.
>
> Cheers,
> Jon
>
> ----- Original Message ----
> From: Kevin Hawkins <lists@xxxxxxx>
> To: xAP_developer@xxxxxxx
> Sent: Tuesday, 17 April, 2007 10:39:44 AM
> Subject: Re: [xAP_developer] Re: Message Etiquette
>
>
> Gregg Liming wrote:
> > Hi Darren,
> >
> > Quoting darrenp_lock (4/16/07 3:56 PM):
> >
> >
> >> As a side note: are there any plans to introduce schema
versions to
> >> allow schemas to evolve over time?
> >>
> >
> > I'll defer to others "in the know".  It would seem more
useful if this
> > were the case.  In practice, I see more "embellishment"
(i.e., additions
> > or refinements to interpretation) than strict schema control. 
There are
> > certain occasions/situations where this leads to considerable
problems.
> >
> xAP has thus far taken the approach that people can augment existing
> schema with their own additional parameters should they wish. Having a
> more formal schema 'evolvement/versioning' system is probably
desirable
> - possibly based around aspects of inheritance  from the existing ones
> using the hierarchical Class= naming structure.
>
> I'm interested Gregg in where you have found considerable problems
being
> introduced by these additional parameters as I haven't heard that
> mentioned before at all and I haven't ever experienced it  ??
> >
> >> :-/As I understand it, I am limited to 254 subaddress IDs,
> Yes - currently - however we have widely publicised that we will be
> implementing a new expanded UID format in an imminent  minor xAP
> revision . The aspect holding this back currently is that users will
> obviously require a xAP hub (and Viewer) that will support the new UID
> format and those applications are being revised accordingly alongside
> updating xFX to .Net 1.2 .  Hub and Viewer are in beta currently and
> should again appear 'any day now'.
>
> FYI the new UID format is
>
> UID=NN.AAAA:SS
>
> NN=network number
> AA=Application/Device address
> SS= Sub address ie endpoints within the device
>
> The above representation obviously reflects the current UID format
with
> the usage of a '.' and ':' to delimit the various portions of the
value
> similarly to the source address formatting. The good news is that we
are
> not restricting the length of any of these fields so NN AA and SS can
be
> any (even) number of uppercase hex digits.  We will recommend some
> formats however. The sub address field is where we are seeing
> restrictions currently and I therefore expect people will adopt 4 or
> maybe 6 digits here. Some people may choose to use natural unique
device
> ID's like 1-wire addresses too. As previously values of all 0's and
all
> F's will be reserved in all fields.  We also intend to allow vendors
to
> reserve their own unique addresses in the 'AA' address field, rather
> like MAC addresses and so I recommend that you not use any values here
> that start with F0-FF.  Some likely recommendations are ...
>
> FF remains at two digits
> AA contains 4 or 6 (8 digits will likely be used for vendor assigned
> addresses in the F0000000 to FFFFFFFE range).
> SS contains 2, 4, 6, or possibly 8 digits
>
> The three most common adoptions I expect will all be based around sub
> address expansion with the second option being prevalent (SSSS)
>
> UID=NN:AAAA:SS  (as currently used - 254 sub addresses)
> UID=NN:AAAA:SSSS   (64K sub addresses)
> UID=NN:AAAA:SSSSSS   (possibly - 16M sub addresses)
>
>
>
**************************************************************************************
> * Everyone should code their current applications to be compatible
with
> this new UID format (as well as the old) *
>
>
**************************************************************************************
>
>
> It is rare for device connector type applications to make use of the
UID
> on receipt so we do not expect this to cause significant issues with
> current applications. The applications most likely to need updating
are
> 'protocol enforcing' hubs and bridges, some diagnostic tools like
Viewer
> etc and in particular controllers / scripting engines.   Also
> historically the 'AA' address portion of the address has been abused
to
> accommodate the lack of sub address space by creating 'virtual'
> applications each with their own 254 sub addresses . This will not be
> necessary and will be strongly discouraged once the new UID is
available.
>
>   K
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

------=_Part_58771_16723242.1176820334476
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html><body>


The UID was designed for devices just like the tini - it&#39;s an
abbreviation address which allows you to quickly identify if a message is
&quot;for you&quot;. I&#39;ve used it on the PIC. It can also
be useful as a tool for originating the sender in what is otherwise an
anonymous medium.
<br><br>If there was a strong consensus, we could look at
deprecating
it?<br><br>Patrick<br><br><div><span
class="gmail_quote">On 4/17/07, <b
class="gmail_sendername">Jon Payne</b> &lt;<a
href="mailto:jgpayne@xxxxxxx";>
jgpayne@xxxxxxx</a>&gt; wrote:</span><blockquote
class="gmail_quote" style="border-left: 1px solid rgb(204,
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi
all,<br><br>I&#39;ve never really understood the point of
the UID. I&#39;d be interested in knowing if anyone actually uses it?
<br><br>For me it&#39;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
&#39;source&#39; field text.
<br><br>In that respect I prefer xPL. But I&#39;m probably
not allowed to say that here am I? ;-)<br><br>Personally
I&#39;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.
<br><br>Cheers,<br>Jon<br><br>----- Original
Message ----<br>From: Kevin Hawkins &lt;<a href="mailto:lists@xxxxxxx";>lists@xxxxxxx</a>&gt;<br>To:
<a href="mailto:xAP_developer@xxxxxxx";>xAP_developer@xxxxxxx
</a><br>Sent: Tuesday, 17 April, 2007 10:39:44
AM<br>Subject: Re: [xAP_developer] Re: Message
Etiquette<br><br><br>Gregg Liming
wrote:<br>&gt; Hi Darren,<br>&gt;<br>&gt;
Quoting darrenp_lock (4/16/07 3:56 PM):<br>&gt;<br>
&gt;<br>&gt;&gt; As a side note: are there any plans to
introduce schema versions to<br>&gt;&gt; allow schemas to
evolve over
time?<br>&gt;&gt;<br>&gt;<br>&gt;
I&#39;ll defer to others &quot;in the
know&quot;.&nbsp;&nbsp;It would seem more useful if this
<br>&gt; were the case.&nbsp;&nbsp;In practice, I see
more &quot;embellishment&quot; (i.e., additions<br>&gt;
or refinements to interpretation) than strict schema
control.&nbsp;&nbsp;There are<br>&gt; certain
occasions/situations where this leads to considerable problems.
<br>&gt;<br>xAP has thus far taken the approach that people
can augment existing<br>schema with their own additional parameters
should they wish. Having a<br>more formal schema
&#39;evolvement/versioning&#39; system is probably desirable
<br>- possibly based around aspects of
inheritance&nbsp;&nbsp;from the existing ones<br>using the
hierarchical Class= naming structure.<br><br>I&#39;m
interested Gregg in where you have found considerable problems
being<br>introduced by these additional parameters as I
haven&#39;t heard that
<br>mentioned before at all and I haven&#39;t ever experienced
it&nbsp;&nbsp;??<br>&gt;<br>&gt;&gt; :-/As
I understand it, I am limited to 254 subaddress IDs,<br>Yes -
currently - however we have widely publicised that we will be<br>
implementing a new expanded UID format in an
imminent&nbsp;&nbsp;minor xAP<br>revision . The aspect
holding this back currently is that users will<br>obviously require a
xAP hub (and Viewer) that will support the new UID<br>format and
those applications are being revised accordingly alongside
<br>updating xFX to .Net 1.2 .&nbsp;&nbsp;Hub and Viewer are
in beta currently and<br>should again appear &#39;any day
now&#39;.<br><br>FYI the new UID format
is<br><br>UID=NN.AAAA:SS<br><br>NN=network
number<br>AA=Application/Device address
<br>SS= Sub address ie endpoints within the
device<br><br>The above representation obviously reflects the
current UID format with<br>the usage of a &#39;.&#39; and
&#39;:&#39; to delimit the various portions of the value<br>
similarly to the source address formatting. The good news is that we
are<br>not restricting the length of any of these fields so NN AA and
SS can be<br>any (even) number of uppercase hex
digits.&nbsp;&nbsp;We will recommend some<br>
formats however. The sub address field is where we are
seeing<br>restrictions currently and I therefore expect people will
adopt 4 or<br>maybe 6 digits here. Some people may choose to use
natural unique device<br>ID&#39;s like 1-wire addresses too. As
previously values of all 0&#39;s and all
<br>F&#39;s will be reserved in all fields.&nbsp;&nbsp;We
also intend to allow vendors to<br>reserve their own unique addresses
in the &#39;AA&#39; address field, rather<br>like MAC
addresses and so I recommend that you not use any values here
<br>that start with F0-FF.&nbsp;&nbsp;Some likely
recommendations are ...<br><br>FF remains at two
digits<br>AA contains 4 or 6 (8 digits will likely be used for vendor
assigned<br>addresses in the F0000000 to FFFFFFFE range).<br>SS
contains 2, 4, 6, or possibly 8 digits
<br><br>The three most common adoptions I expect will all be
based around sub<br>address expansion with the second option being
prevalent (SSSS)<br><br>UID=NN:AAAA:SS&nbsp;&nbsp;(as
currently used - 254 sub
addresses)<br>UID=NN:AAAA:SSSS&nbsp;&nbsp; (64K sub
addresses)
<br>UID=NN:AAAA:SSSSSS&nbsp;&nbsp; (possibly - 16M sub
addresses)<br><br>**************************************************************************************<br>*
Everyone should code their current applications to be compatible with
<br>this new UID format (as well as the old)
*<br>**************************************************************************************<br><br><br>It
is rare for device connector type applications to make use of the
UID<br>
on receipt so we do not expect this to cause significant issues
with<br>current applications. The applications most likely to need
updating are<br>&#39;protocol enforcing&#39; hubs and
bridges, some diagnostic tools like Viewer
<br>etc and in particular controllers / scripting
engines.&nbsp;&nbsp; Also<br>historically the
&#39;AA&#39; address portion of the address has been abused
to<br>accommodate the lack of sub address space by creating
&#39;virtual&#39;
<br>applications each with their own 254 sub addresses . This will
not be<br>necessary and will be strongly discouraged once the new UID
is
available.<br><br>&nbsp;&nbsp;K<br><br><br><br><br><br>Yahoo!
Groups Links<br><br><br><br><br>
<br><br>Yahoo! Groups
Links<br><br>&lt;*&gt; To visit your group on the web,
go to:<br>&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://groups.yahoo.com/group/xAP_developer/";>http://groups.yahoo.com/group/xAP_developer/</a><br><br>&lt;*&gt;
Your email settings:
<br>&nbsp;&nbsp;&nbsp;&nbsp;Individual Email 
Traditional<br><br>&lt;*&gt; To change settings online
go to:<br>&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://groups.yahoo.com/group/xAP_developer/join";>http://groups.yahoo.com/group/xAP_developer/join</a><br>&nbsp;&nbsp;&nbsp;&nbsp;(Yahoo!
ID required)
<br><br>&lt;*&gt; To change settings via
email:<br>&nbsp;&nbsp;&nbsp;&nbsp;mailto:<a
href="mailto:xAP_developer-digest@xxxxxxx";>xAP_developer-digest@xxxxxxx</a><br>&nbsp;&nbsp;&nbsp;&nbsp;mailto:<a
href="mailto:xAP_developer-fullfeatured@xxxxxxx";>
xAP_developer-fullfeatured@xxxxxxx</a><br><br>&lt;*&gt;
To unsubscribe from this group, send an email
to:<br>&nbsp;&nbsp;&nbsp;&nbsp;<a href="mailto:xAP_developer-unsubscribe@xxxxxxx";>xAP_developer-unsubscribe@xxxxxxx
</a><br><br>&lt;*&gt; Your use of Yahoo! Groups
is subject to:<br>&nbsp;&nbsp;&nbsp;&nbsp;<a
href="http://docs.yahoo.com/info/terms/";>http://docs.yahoo.com/info/terms/</a><br><br></blockquote></div><br>

<span width="1" style="color:
white;"/>__._,_.___</span>


<!-- **begin egp html banner** -->

<img src="http://geo.yahoo.com/serv?s=97476590/grpId=9629476/grpspId=1705007709/msgId=1827/stime=1176820398";
width="1" height="1"> <br>

<!-- **end egp html banner** -->


<!-- **begin egp html banner** -->

<br><br>
<div style="width:500px; text-align:right; margin-bottom:1px;
color:#909090;">
<tt>SPONSORED LINKS</tt>
</div>
<table bgcolor=#e0ecee cellspacing="13"
cellpadding="0" width=500px>
<tr valign=top>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads;_ylc=X3oDMTJjY2s2cWhuBF9TAzk3NDc2NTkwBF9wAzEEZ3JwSWQDOTYyOTQ3NgRncnBzcElkAzE3MDUwMDc3MDkEc2VjA3NsbW9kBHN0aW1lAzExNzY4MjAzOTg-?t=ms&k=Filemaker+developer&w1=Filemaker+developer&w2=Sql+developer&w3=Sql+server+developer&w4=Web+developer&w5=Php+developer&c=5&s=108&g=0&.sig=aGwzOHWoMXeq_43Jix8FKQ";>Filemaker
developer</a></tt>
</td>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads;_ylc=X3oDMTJjZW01ZDY0BF9TAzk3NDc2NTkwBF9wAzIEZ3JwSWQDOTYyOTQ3NgRncnBzcElkAzE3MDUwMDc3MDkEc2VjA3NsbW9kBHN0aW1lAzExNzY4MjAzOTg-?t=ms&k=Sql+developer&w1=Filemaker+developer&w2=Sql+developer&w3=Sql+server+developer&w4=Web+developer&w5=Php+developer&c=5&s=108&g=0&.sig=KdkJ37xcz6o6aKyju4GPuQ";>Sql
developer</a></tt>
</td>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads;_ylc=X3oDMTJjczA4cm9sBF9TAzk3NDc2NTkwBF9wAzMEZ3JwSWQDOTYyOTQ3NgRncnBzcElkAzE3MDUwMDc3MDkEc2VjA3NsbW9kBHN0aW1lAzExNzY4MjAzOTg-?t=ms&k=Sql+server+developer&w1=Filemaker+developer&w2=Sql+developer&w3=Sql+server+developer&w4=Web+developer&w5=Php+developer&c=5&s=108&g=0&.sig=Y2Cl41GpJD04dk8vnjhH2A";>Sql
server developer</a></tt>
</td>
</tr>
<tr valign=top>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads;_ylc=X3oDMTJjODM4dTRtBF9TAzk3NDc2NTkwBF9wAzQEZ3JwSWQDOTYyOTQ3NgRncnBzcElkAzE3MDUwMDc3MDkEc2VjA3NsbW9kBHN0aW1lAzExNzY4MjAzOTg-?t=ms&k=Web+developer&w1=Filemaker+developer&w2=Sql+developer&w3=Sql+server+developer&w4=Web+developer&w5=Php+developer&c=5&s=108&g=0&.sig=61LAoCeyEhDkBGB767LsxQ";>Web
developer</a></tt>
</td>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads;_ylc=X3oDMTJjMGhoZXFvBF9TAzk3NDc2NTkwBF9wAzUEZ3JwSWQDOTYyOTQ3NgRncnBzcElkAzE3MDUwMDc3MDkEc2VjA3NsbW9kBHN0aW1lAzExNzY4MjAzOTg-?t=ms&k=Php+developer&w1=Filemaker+developer&w2=Sql+developer&w3=Sql+server+developer&w4=Web+developer&w5=Php+developer&c=5&s=108&g=0&.sig=8S56dAWPuzOmElm54L8LeA";>Php
developer</a></tt>
</td>
</tr>
</table>

<!-- **end egp html banner** -->


<!-- **begin egp html banner** -->

<br>
<div style="font-family: verdana; font-size: 77%; border-top: 1px
solid #666; padding: 5px 0;" >
Your email settings: Individual EmailTraditional <br>
<a href="http://groups.yahoo.com/group/xAP_developer/join;_ylc=X3oDMTJmaG5yZTZkBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzExNzY4MjAzOTg-";>Change
settings via the Web</a> (Yahoo! ID required) <br>
Change settings via email: <a href="mailto:xAP_developer-digest@xxxxxxx?subject=Email
Delivery: Digest">Switch delivery to Daily Digest</a>  <a
href = "mailto:xAP_developer-fullfeatured@xxxxxxx?subject=Change
Delivery Format: Fully Featured">Switch to Fully Featured</a>
<br>
<a href="http://groups.yahoo.com/group/xAP_developer;_ylc=X3oDMTJkdnZlb2s1BF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMTc2ODIwMzk4";>
Visit Your Group
</a>
<a href="http://docs.yahoo.com/info/terms/";>
Yahoo! Groups Terms of Use
</a>
<a href="mailto:xAP_developer-unsubscribe@xxxxxxx?subject=Unsubscribe";>
Unsubscribe
</a>
<br>
</div>
<br>

<!-- **end egp html banner** -->


<span  style="color: white;"/>__,_._,___</span>
</body></html>

------=_Part_58771_16723242.1176820334476--

xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.