Re: xAP Configuration, Serial RS485 Bridge and PIC's

["g8kmh" <g8kmh@xxxxxxxxxxx>]

> I do anticipate seeing transmit only BSC devices - perhaps I
didn't make
> that clear in the BSC docs but low cost BSC light switches for
example
> are quite likely to be send only , either targeting a BSC device
or
> sending an input event / state message. Of course tehyw ould not
then be
> capable of responding to queries so should probably up the
frequency of
> their periodic state updates.

OK, that makes sense. Maybe the BSC spec needs a section on small
devices and the opt outs.
<snip>

> "dumb light dimmer" meaning the lightbulb end - not the
switch -
you
> would need to be able to recover target / uid / class from an
incoming
> message so if you can't parse the header you're stuck aren't
you ?. In
> such a case maybe a simple xAP bridge to a protocol like SNAP
would be
> more suitable which is highly efficient on low speed links???
>
> Back with xAP basically  you have two choices.  Either the light
watches
> for certain sources (the switches) or the light responds when it
is
> targeted. This is just a choice of approaches, the switch
commanding a
> light or the light watching the switch.  The former actually
allows an
> intermediary controller of course (controller watches switch(s)
and then
> commands light(s).    Assuming the dimmer watches the switches
then you
> need it to implement a schema that 'adds a UID' to its triggers
perhaps
> a schema of class UID.add where a body parameter is the UID value
(s) to
> add.   Or... (and this is sort of a kludge) in a special
learn/program
> mode it can add the UID's of anything that directly targets it. So
you
> put it into learn mode, and send it commands from a lightswitch
which it
> then adds to its list (based on UID) and then take it out of learn
> mode..   In practicality the switch may not be able to target so
you
> might end up enlisting a sort of config app that you create that
just
> sends 'add this uid' schema to your dimmers (or if it was using
that
> learn kludge it masqueraded briefly as the switch to force the
add).  If
> you do use a 'controller' at some point then all the logic of
course
> could reside there.  (back to resilience though)
>
> >With a config schema and a broadcast UID it becomes easier. The
> >device always listens for the broadcast UID and a config message
> >(perhaps a one shot) can then send the other UID's it should
> >listen/filter for (in this simple case of course it only works
with
> >one device listening!). If this can't be done and the device has
to
> >parse the target address then UID's are mainly redundant anyway.
> >
> >
> I think I understand what you are meaning here - you want
a 'broadcast'
> message that says I am device "UID1" and I want to be
directly
linked
> with devices 'UID2' "UID7' and 'UID9'   but I don't have the
capability
> myself to maintain that link ... ?? Is that right ?    ( or are
you
> saying the centralised network config app has a defined (reserved)
UID
> it should always use ?)

Yes, there is a defined UID for the network config application.

Probably more along the lines - I am FFFFFFFF and set 'interesting'
UID1 to (say) UID8 to these values using name/value pairs. Any
device with FFFFFFFF in their current UID1 to UID8 table would then
update the table. UID1 would therefore be FFFFFFF on initialisation
and (mndatory?) get written over.

A schema UID.add would allow target devices to add to their table of
interesting sources.

As in your example, if the switch can't target then the listener
must be capable of being configured with the source. It's a question
of how intelligent that end is too - see below.

>
> This is achievable currently by a message targeted at >:> (ie
everyone)
> with a suitable config schema (if we had one)  you still don't
need a
> broadcast UID.  (although we do have reserved UID ranges  for
things
> such as this should it be needed eg FFFFFFFF)

I guess I'm still a little confused here and probably should re-read
the specs! If the device can parse the target adress in the header
then source UID's are an implementation complexity (if you've got
the memory to parse the source and target addresses, why then drop
back to UID?). If the device only responds to specific UID's then a
broadcast UID is required to send the UID.add


-   Actually , aside from
> the 1 to 1 config aspect, what you are wanting here is 'groups and
> scenes' ie the ability to ask devices to enter and leave group
> memberships - we have several proposals on this and I believe
Edwards
> X10 conduit even implements it,  in this way inputs and outputs
join
> groups and all become linked as one.  I use a close variant of
this
> alraedy for C-bus.   This can be achieved either by group capable
> hardware or via a 'helper' application . The latter is needed for
> devices that can't manage groups internally.  In your example of a
> dimmer if it was controlled by several switches they can be
considered a
> group.
>
> Or have I misunderstood ???

That would be an ideal way.


>
> >Actually it may be acceptable to commission in that way. Connect
one
> >at time, send the one shot commission/config message, move on. If
a
> >reconfigure is required then it would have to originate from one
of
> >the programmed UID's.
> >
> >
>
> We did have a proposal where a range of UID's was available for
non
> configured devices (currently all UID's of the form  xxFFxxxx and
> xx0000xx and indeed 00xxxxxx are reserved - the idea being a new
device
> would appear in this range, become configured almost like say DHCP
and
> then move to another UID - this really works the same way as your
> comments above but did allow for several devices to be added at
one time
> with an address challenge mechanism say from FFFF00xx upwards for
> perhaps 100 or so addresses.  This maybe ties in with the concept
of a
> 'configuration' reserved UID perhpas ?
>
That would sort out the device itself and is a good proposal. Going
back to the example of 40 identical devices these could randomly
pick the xxxx section.


Lehane