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

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

g8kmh wrote:

>
> I'm not sure about the
>transceiver argument. Most devices will (BSC have to?) respond to
>queries anyway.
>
>
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.

>>Ahh I think you may have misunderstood the UID in this respect - no
>>device can 'respond' to a UID as it is not in any way targetable. A
>>message can't be sent to a UID.  You can only target the longform
>>address using target= .
>>
>OK, I'll put it another way. I'm a xAP dumb light dimmer. Single
>channel, zero crossing triac, etc. Which UID is the lightswitch(es) I
>should listen for? If I've made 40 of them, how as 'small' devices do
>they get the source UID(s) they should listen for programmed in? (and
>for the moment assume it's so dumb it can't parse the header fully)
>
>
"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 ?)

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) -   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 ???

>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 ?

K

>Lehane
>
>
>