The UK Home Automation Archive

Archive Home
Group Home
Search Archive

Advanced Search

[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: One way BSC ?

  • Subject: Re: One way BSC ?
  • From: "Brett England" <brett@xxxxxxxxx>
  • Date: Tue, 04 Jan 2011 14:25:54 -0000

I'd have to agree with you on this one.  Either implement the BSC spec
in its entirety or create your own class - don't just implement that bits
that you need and call it a day.

--- In xap_automation@xxxxxxx, Kevin Hawkins <yahoogroupskh@...>
>   I've noticed a couple of  xAP devices /applications appearing that
> implementing BSC as senders only , either just being lazy or because
> they have no receive capability and hence can not respond to a
> xapbsc.query or xapbsc.cmd.   These report their input states using
> / xAPBSC.event  as it is so pervasively supported.
> Some of these are of necessity senders only as they are bridging from
> another schema or even protocol,  for example xPL, which lacks support
> for UID's ,  sub addressing and the wildcard constructs xAP BSC uses.
> Some applications with inbuilt bridging implement  this mapping using
> 1 way BSC.
> My immediate reaction was that such '1-way' devices don't meet the BSC
> specification and hence must not use BSC - i.e. BSC if implemented
> be bidirectional.  I looked up the BSC spec and it reads that all 4
> schema classes should be implemented.  How do others feel ?  Maybe we
> should allow (identify) an inputs only  '1 way' version of BSC somehow
>     Kevin
> PS  For those wanting a good solution HouseBot allows creating virtual
> xAP BSC endpoints and also  bridging schema as it maintains a true
> bidirectional endpoint and can be scripted to schema translate.


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.