RE: UIDs

[Kevin Hawkins]

> -----Original Message-----
> From: Stuart Booth [mailto:<a
href="/group/xAP_developer/post?postID=SBVFJW-LTdLVJUiOyNcM-1qXqHaEJ0CRG6PUS4jCXWvHqPS1T_DfExhkcUV-w71i3JSg3pZ7-Mmg5I3H5TA">lists@x...</a>]
> Sent: 11 June 2003 13:12
> So your UIDs look like "FFFFxx00" ???

Originally yes - actually I used FE as my first two digits - I am not sure
(specwise) that I could be using FF there - however I think it is FFFF that
is reserved and not FFxx so it should have been ok but FE was safer.
Thinking back on policy - if we allocated the addresses starting FE etc for
this purpose we would end up with very likely collisions in UID's say
between C-Bus and your container app as an example so this isn't the right
approach...

So originally I used

FFFExx01 to FFFExxFE for say the C-Bus Lighting application where xx is the
unit number of a C-Bus device and the last two digits are the hardware
terminal involved. FFFDxxyy for the security application etc - there are
about a dozen or so C-Bus applications.

HOWEVER I'm going to change it to just using groups as the hardware sub.
The
way C-Bus works an input is linked via a 'group' to an output ie the output
and the input are configured to be in the same group and all that actually
happens is that the input changes the group level and the output follows.
This solves (and creates) a number of issues...

Originally when a switch that activated 10 lights changed state I got 11
xAP
messages - 1 for the switch and 10 (1 for each) light. Quite wasteful. Plus
on C-Bus there is no info actually provided out the serial port that tells
you which particular switch was involved - just on which switchplate it is
situated - as most switches on one switchplate control different groups
this
is not a big issue. So...

Then I settled on FF38xxyy as a message from C-Bus saying that group yy has
changed state (38 is actually the ID that C-Bus uses to identify the
lighting app) and xx is the unit ID that originated the change - as you can
see from that I then had the double hierarchy issue - same as you - I am
now
thinking I will drop the xx bit and include the originators unit number in
the body. Occupying a block of UID's like this is not going to help the
configuration issues with conflicting UID's, unless of course we allowed
reservation of ranges. I am convinced having the last two (sub) digits as
the group number is now correct. I think this will be the 'trigger' type
status change message and I will have other mechanism to enquire what units
actually sit in a given group or to produce another status change messages
for the outputs effected. For this message I envisage either :

one message with several bodies (one per output)
one message with one body and a list of changed outputs
separate xAP messages - one per output

.....still to be decided but I favour the middle option currently.

Kevin