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: MisterHouse xAP BSC Support ??



Kevin Hawkins wrote:

>When using BSC then X10 appears as any other Binary or Level based
>device so you can't tell if a light is X10 or C-Bus for example (indeed
>it shouldn't matter). It is called by its name There is of course a
>specific X10 schema as well in xAP should you so wish and then you get
>the X10 house/unit codes back.
>
>
>
That seems reasonable, and later you mention that some "vendors"
are
using both BSC and some "extended/special purpose" schemas. Does
that
mean that they are essentially broadcasting like events twice (once w/
BSC and a second w/ something "better/different") or is the
"rule" only
one schema transmission per event?

>>
>>
>>
>>
>Is every <devicename> in Misterhouse unique ?
>
yes

>If so this will work, each
>unique <devicename> will also have a corresponding unique UID  eg
>FF123401 FF123402 etc etc.  This will limit you (currently) to 254
>different devices 01-FE - if you need more then you will have to divide
>the devices into groups somehow and start witha  new UID eg FF1235xx
>
>
>
hmmm... I could personally see a situation in whch more than 254 is
reasonable. Are there any xAP modules that "expect" (or are
sensitive
to) a specific subgroup set of names?  Otherwise, I'm somewhat thinking
of automatic grouping via device "type".

>With regard to
>TEXT devices then you can add any length of text up to the limit of
your
>packet size which on UDP will be 1500 bytes.
>
I forgot about UDP packet size; I'd better watch that.  I'm guessing a
better/safer number might be <=1492 for aDSL clamped users?

>The text must be in the
>ascii printable range
>
I had assumed chars like curly braces, equals signs and other symbols
used to delimit xAP messages would be "off-limits".  Am I wrong?

>>Perhaps a tangent, but Bruce Winter (Misterhouse's creator)
recently
>>added support into mh to "sync" the state of two running
mh instances
>>using xAP (albeit--again, a mh-specific schema).  Currently, the
support
>>is really only applicable for "slaving" or
monitoring--not for real-time
>>failover/redundancy.  However, I'm interested in the latter (for
more
>>critical operations).  Has any thought gone into this specific to
xAP
>>(additions to schema; guidelines on target wildcarding; etc.)?
>>
>>
>>
>>
>
>James might have some comments here as he has used xAP and BSC to
>achieve similar with a couple of apps including HomeSeer - the two apps
>stay in  synch via BSC and I guess if both were addressed with a
>'wildcarded' target then both would respond. This leads to thinking
that
>if one could be 'active' and one 'reserve' with a  way of switching in
>the second should the first fail then you achieve your goal. So, a
>script running on instance B that monitored the heartbeats (and
expected
>xAPBSC.events) from 'A' could take over 'transparently as soon as A
failed.
>
>
>
Precisely!  So, how do the apps "agree" as to who is the master?
Further, how is this communicated via xAP (maybe a new attribute in the
header for heartbeats)?  If a "slave" decides that it must become
the
"master" (either a "slave" config'd timeout--or perhaps
something
transmitted via xAP), how does it communicate that? Again, I would think
via heartbeat--as it's the only repetitive message that an errant
"master" might see on regaining network consciousness.

BTW: I quite appreciate the dialog.  I've been a "lurker" for
some time
on both this and the xpl lists.  You've been most informative and I hope
that I might eventually reciprocate.

Regards,

Gregg





xAP_Automation Main Index | xAP_Automation Thread Index | xAP_Automation 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.