Re: Subgroup UIDs

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

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)



Kevin