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: Subgroup UIDs



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:

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.

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.

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.

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.

Gregg




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.