Re: Addressing vs Commands

[Jerome Kerdreux <jerome.kerdreux@xxxxxxxxxxxx>]

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


--
Jerome Kerdreux <Jerome.Kerdreux@xxxxxxx>


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