Re: Subgroup UIDs

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Gregg Liming wrote:

>Kevin/Stuart,
>
>	Thanks for the replies.  My comments embedded below.
>
>Kevin Hawkins wrote:
>
>
>>Gregg Liming wrote:
>>
>>
>>
>>
>>>I guess what I'm asking is whether the
>>>concept of source/target subaddressing mapping to subUID is
conceptually
>>>similar to DNS in which the relationship can be dynamic and
there is
>>>some time-to-live to which the relationship is considered
accurate
>>>(although--that's still questionable). In my case, though, it's
the
>>>sub-source/target that remains relatively static and the subUID
that is
>>>dynamic. How should this be resolved?
>>>
>>>
>>>
>>>
>>    I think it is very important to try and maintain the UID
assignments
>>you have previously advertised or used. Take for example a light
that
>>might monitor FF134507 knowing that it is a switch - should that
UID
>>change then it breaks, indeed another switch might now control the
light
>>or the original switch might switch on the TV or something.   How
you do
>>this is very much specific to the the application and how it
maintains
>>devices.  HomeSeer for example has a range of devices named A1-A99
>>B1-B99 even things like [1 to [99  .  What James has done is use
the
>>first character to create the major part of the address (and hence
>>middle four hex digits of the UID) and the numerical part to create
the
>>sub address.  HomeSeer devices are static once created, however old
>>vacated slots can be refilled when new devices are added. UID's
>>therefore only ever change based on a user deleting then adding new
>>devices.
>>
>>    I am not familiar with the way Misterhouse works but I think if
at
>>all possible then devices should be categorised and mapped in a
>>persistent way to a UID - it's not the end of the world if they
aren't
>>but any device detecting its sources via UID would not work
correctly
>>with MH over restarts.  It is probable that in the future this will
>>cause MH to not be able to allocate devices that participate in
groups.
>>As yet my C-Bus controller is the only embedded device I know that
does
>>this (by UID) and it only uses this for BSC devices (switches).  It
is
>>my unofficial implementation of 'groups' and I don't have the space
to
>>store the full source addresses.   I also need to check but BSC
Mapper I
>>think may have issues too. ISTR it manages its sources via UID but
I'll
>>peruse the code and check, unless Mark/Mary can clarify ?. This
would
>>mean that MH could cause BSC Mapper to action unintended
associations,
>>obviously a major problem.
>>
>>    It seems therefore that a persistent lookup table or a device
>>property (? is this poss) is required if MH devices are referenced
by a
>>long name ....
>>
>>although..
>>
>>Gregg Limiming said...
>>
>>
>>
>>>unless some
>>>persistence of the mapping were maintained (which would be
impractical
>>>in my case)
>>>
>>>
>
>Ok--I will have to make the assignments persist.  What I now understand
>is that I will likely cause breakage or create confusion is the
>assignments do not persist.  However, this leads to a new set of
questions:
>
>
Well I think it's best practice to do this, that way it will work later.

>1) Must the assignments be immutable?  If so, then this implies that
>once a subaddress UID is assigned it could never be "reused"
if the
>corresponding "device" goes away.  With the 254 subaddress
limitation, I
>would very much like to "reuse" absent devices' subaddress
UIDs.
>
>
I dont think that's a problem, if a user alters the device by say
deleting and recreating it or another device then they are in control
and should manage this. Rather like chnaging the dials on an X10
device.  HomeSeer actually works just like this , it reuses old UID's

>2) Must the assignments really be deterministic based on device type
>and/or name?  My preferred approach is to assign UIDs sequentially as a
>new device is "registered" for xAP in mh.  That means not
adopting the
>same strategy that HomeSeer uses as mentioned above.
>
>
Actually HS does this too - although A8 B9 etc are likley to be X10
something like [56 could be any device at all -if you can cause some
grouping by type of device it's 'neater' but by no means essential.

>3) Assuming a strategy of assigning and persisting a subaddress UID
>whose assignment is mapped based on subaddress name and that subaddress
>UIDs can be reused if the subaddress name "disappears", then
the
>subaddress UID for a given device would change if the name changed.
>Further, it could "revert" back to a previously assigned
subaddress UID
>on name change.  From a practical matter, changing a device name is
then
>the equivalent of removing the device and adding an entirely new one.
>
>
I think once a device is 'deleted' from MH then you dont need to persist
necessarily. My concern was things jumping about after every restart -
particularly one device moving down say a UID because an earlier device
was deleted.  .  It would be nice to be able to manually configure a UID
I guess such that you could revert to a previous assignment if desired.

>4) I'm fully expecting the requirement to sequence new base (4 digit)
>UIDs as the mapping table "rolls over" 254.  What is unclear
to me is
>whether I must also have a unique source name for each new base UID.
>I'm very much hoping not as it would be arbitrary and only exist due to
>the 254 limit on subaddresses.
>
>
This is a current restriction based on only supporting 254 sub addresses
- it will go away with a longer UID field. FTTB you will need a new
source name for each group of 254 sub addresses but it could be
mhouse.app.2  /  mhouse.app.1 or mhouse.app.machine.one  /
mhouse.app.machine.two or something allowing for still addressing the
whole application as mhouse.app.*  or mhouse.app.machine.*
mhouse.app.>  or something.

Also you don't need to use all the 254 addresses sequentially if you
dont wish to - for example Netiom groups them so the device types start
on a x0 boundary so output 4 from a particular group would be on
FF1111x4   . Homeseer only uses 1-100 I think

Kevin