Re: Addressing vs Commands

[Kevin Hawkins <yahoogroupskh@xxxxxxxxxxxxxx>]

Yes, you are free to create whatever schema you wish . The only thing
you mustn't do is name the class starting with 'xAP' as in say xAPBSC as
these are reserved.  The problem with any custom schema is getting
adoption by other developers so if you can create something that uses
the existing BSC schema then almost every other xAP application will
already be able to interact with it. If you do create a new schema give
it lots of thought and try and make it as complete, tidy and useful as
possible - this way it is more likely to be adopted by others.

I believe that derivatives of BSC are beneficial because it is tried and
proven and also more people are likely to be able to adapt their code to
include your schema.  BSC whilst apparently very simple does take a bit
of implementing as it is a two way interactive schema and additionally
supports wildcarding of names and the ID.

Let me also mention you are permitted to take an existing schema ,
including say BSC,  and add your own parameters within the message block
- as these will be ignored by other listeners. Although discouraged you
can also add parameters within the header.   Several schema eg TSC and
xap-audio have derivative similarities to BSC.

Also FYI there are a number of applications out there that already
support X10, 1-wire etc via BSC - some are PC applications and some are
standalone embedded controllers in their own right.  Also if you use any
existing  HA software application and it has a xAP plugin (most do)
then this creates the ability to expose it's internally supported device
list via xAP so you get all those devices 'xAPped' for free.

http://www.edjo.pwp.blueyonder.co.uk/edward/xAP/X10/x10_main.htm
http://www.edjo.pwp.blueyonder.co.uk/edward/xAP/quasar3145.htm
TOM10 1-wire temperature board (no longer available)
http://www.mm-wave.com/honeycottage/tom10.htm
1-wire PC application with many devices supported
http://www.mcssprinklers.com/xapXap.htm
1-wire embedded - many devices supported
http://sites.google.com/a/usapiens.com/opnode/products
 (xAP
embedded 1-wire,  X10 and ModBus)
HomeVision (X10 + 1-wire temp + I/O)  can be xAP enabled via my xAP
embedded gateway
Barix Barionet (1-wire temp + I/O) has xAP BSC embedded firmware option
http://www.edjo.pwp.blueyonder.co.uk/edward/xAP/barionet.htm
xAP HA hub has a 1-wire temp interface
http://www.dbzoo.com/wiki/livebox/hah

K





On 01/06/2010 15:10, Jerome Kerdreux wrote:
>
> First, I would like to thanks for all the support here, this is a
great
> experience.
>
> When I first sent my email today, I was wondering if source based
filtering
> could be used. You have answered here.
>
> So my final question, is : Can I build some special schemas (for X10,
and
> X2D, 1wire for instance) that support a BSC derivative. I mean with
BSC like
> schema (.query, .cmd, .state, .info) with special feature like the
negative
> value for 1wire, or association ID for X2D ..
>
> I thinks the answer is yes, but I'm wondering the side effects and the
way
> the community usually handles this case.
>
>
> Bye
>
>
> On Tue, 01 Jun 2010 13:08:49 +0100
> Kevin Hawkins<yahoogroupskh@xxxxxxx>  wrote:
>
>
>> Hi Jerome,
>>
>> BSC is a universal schema for simple devices. It can very neatly
model a
>> device with an unlimited* number of endpoints where these can be
>> categorised as either binary, level or text.  There are
restrictions
>> however, for example that the level can't be negative and the
units eg
>> degrees Celsius aren't formally presented.   Other schema handle
these
>> situations better.
>>
>> BSC is extensively supported by almost every xAP controller and
because
>> of this there is a tendency to try and model every device using
BSC. For
>> example it would be possible to model an audio amplifier using BSC
>> creating endpoints for every control.  Whilst achievable it would
be far
>> better to use a different schema specifically designed for AV
amps.
>> This is because then the amplifier is astracted to a functional
device
>> and later should you change your ACME brand amplifier for a new
Denon
>> and as long as both used the AV amp schema it would just swap
without
>> any changes within your control system.  Here the schema class is
>> defining the functionality . Having said that designing such
schema is
>> not as simple as it sounds and we don't yet have the range of
schema we
>> need, but anyone can create them.
>>
>> Regarding your specific X10 question at the end about knowing the
type
>> or functionality of a device.  Using BSC you don't as the class is
>> generic so a good alternative is to include this information in
the
>> source address. For example creating a 'lighting' category rather
than
>> 'X10' as your aim typically is to address the functionality rather
than
>> the specific hardware used.    As X10 offers lighting control does
it
>> actually matter if C-Bus, ZigBee or X10 hardware is used.  Then
you
>> could do something like this to control 'LightName'.
>>
>> target=*.*.lighting:LightName
>>
>> and then whatever technology was used for your lighting it would
work,
>> it could be mixed X10, ZigBee, C-Bus, Dynalite etc
>>
>> Having said that it is very likely that the type of the device is
>> presented in the source address but that is up to you to
configure.
>>
>> source=ACME.controller.X10:LightName
>> source=ACME.X10.controller:LightName
>> source=ACME.controller.lighting.X10:LightName
>> or even better as it supports the target example above
>> source=ACME.X10.lighting:LightName
>>
>> if only some of your X10 devices were used for lighting and others
say
>> for irrigation you could instead name the endpoints at the sub
address level
>> source=ACME.controller.X10:lighting.LightName
>> source=ACME.controller.X10:irrigation.Sprinkler
>> still preserving that same flexibility across lighting
technologies
>> target=>:lighting.LightName
>>
>> If you do want to allow X10 device codes within BSC  you could
include
>> them instead of or additionally to the friendly name
>>
>> source=ACME.X10.lighting:D7
>> source=ACME.X10.lighting:D7.LightName
>>
>> then you could use this to control a specific X10 device
>>
>> target=*.X10.*:D7
>>
>> Addressing usage is very much your choice for your own
installation  -
>> how it works best for you.
>> I personally prefer the schema class defining the functionality of
a
>> device but for the general BSC devices I use an address position
to
>> include this information (as above) which allows me to choose and
later
>> transparently swap at each endpoint level what technology is used.
>>
>> The X10 schema still exists by the way and you can always have a
device
>> that implements several schema, in this case both X10 and BSC
should you
>> wish.
>>
>>      K
>>
>> *PS If you are supporting BSC then do familiarise yourself with
xAP v1.3
>> proposed changes .   In a nutshell the UID format has changed from
>> FF123409 to FF.1234:09    ie a '.' and a ':' have been inserted to
>> delimit the three segments.     Additionally each value can now be
any
>> even number of uppercase hex digits, although there are common
>> combinations.  The main reason for this was that in xAP v1.2 the
last
>> two digits of the UI,   '09' in the example above ,  previously
>> restricted the number of endpoints to 254 (01-FE) but this was
found to
>> be too restrictive and so expanded in xAP v1.3 to support any
number you
>> wish.  As a consequence the ID= parameter in a BSC body now can
include
>> any even number of uppercase hex digits.
>>
>>
>>
>> On 01/06/2010 09:45, Jerome Kerdreux wrote:
>>
>>> Thanks for the highlight, I missed that stuff. That looks
quite exactly
>>> what i'm looking for.
>>>
>>> So, if I clearly decode both mails, you say I should use BSC
for this
>>> kind of devices. This is used for X10 in the new version ..
but there
>>> is something that sound strange.
>>>
>>> If every device use a BSC schema, how could you know the type
of device,
>>> as every device has the same class. This could cause issues
for example
>>> to build a GUI or anything else, or is there a new X10 schema
with a BSC
>>> like behaviour ?
>>>
>>>
>>> Thanks
>>>
>>>
>>
>
>



------------------------------------