Re: Misterhouse vendor id and uid range

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Gregg Liming wrote:

>Kevin Hawkins wrote:
>
>
>
>>Hi,
>>    AFAIK mhouse is fine - in fact I am not sure who is
administering
>>the allocations but I'm sure they'll speak up if it's not.
>>
>>    Within the current UID sizing we do not  allocate a range of
UID's
>>to a vendor, normally the UID value (or base UID value if you use
>>several) is configurable in the application and it is left to the
>>user/installer to choose such that there are no conflicts.
>>
>>
>
>Thanks Kevin.  Currently, the UID is settable.  But, I'm pretty certain
>that a very large majority of the users won't think to look or change
it
>if it were to conflict.  So, this leads me to the following questions:
>1) Is there any recommended practice of selecting a default such that
>there is some reasonably high likelihood of it not conflicting? The
>current mh default is FF123400 which surely seem likely to be
duplicated.
>
>
Yep - a very common choice ;-)  - I would suggest using an unusual
middle 4 digits probably starting with A-F  eg FFB29500 or something.
not DEAD ;-).  The chances of a collision are minimal currently 65K to #
apps running

>2) What "breaks" if there is a conflict?
>
Well currently not as much as really should break.   UID's should be
unique though as they are effectively a compact binary representation of
the source address.  However you can't target a device by UID.    The
idea was that very compact devices could monitor a specific device by
just watching for its UID rather than the full address eg a PIC based
lamp module only has to monitor a device say FF111106  to know that it
is the switch that controls it. So 4 bytes rather than 40 for the full
source.  To a tiny device monitoring many sources thsi is important and
as we integrate groups and scenes we need a way of storing members
economically. Some hubs and routers (Viewer maybe) I believe use the UID
to work so that could be pretty fundamental and some controllers may
well monitor devices by UID rather than source address.   UID's fit
really nicely with BSC

>I know the current mh xap logic
>ignores UIDs of received messages--instead relying only on source.
>
The advantage of doing it that way is you can tell when one of your
devices is being wildcard addressed (targeted) eg if you have a device
you are monitoring called

ACME.Widget.Controller           UID  FF122100

then you can monitor either source address or UID but if you use the
source (recommended) then you know that when you see a
Target=ACME.Widget.* message that it is addressing a device you are
monitoring. You can't tell this if you only store the UID. However if
the device responds then it is much the same.  Wildcarding is the reason
you can't target UID's in xAP.

> BTW:
>I did review a number of the threads re: discovery and directories and
>therefore am aware of possible future directions; my immediate concern
>is adopting any current best practices.
>
>
Best practice - choose a number that noone else will  ;-)

>3) Should the app attempt to detect the possibility of conflicts (via
>heartbeats of others) and adjust it dynamically or simply write out
>errors or other suitable notification mechanism?
>
>
We haven't formalised a 'discovery' system for UID's currently leaving
it to the installer to manage. However a good solution might be to
listen for say 70 seconds and then choose a UID you haven't seen. This
of course delays xAP startup by a minute which may be acceptable.  All
other xAP devices should have issued a heartbeat in this time so you
would be aware of all other device UID's .  Bear in mind that 60 second
intervals for heartbeats is not a specification , it is a
recommendation. 30 mins would be permissable although not much practical
use.  I suspect shifting UID dynamically is fraught with problems as the
'conflict' has already arisen.

Kevin

>
>
>>You will
>>only need 1 UID per 254 endpoints/devices of course although you
may
>>choose to use more.  If we do move to a longer UID - as we may -
then
>>part of the reasoning is exactly for this situation such that
vendors
>>have unique pools to work from and can even issue embedded UID's
rather
>>like MAC addresses.
>>
>>
>>
>
>
>
>
>
>
>
>
>
>