RE: BSC protocol

[Shane Harrison <shane.harrison@xxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: xAP_developer@xxxxxxx
> [mailto:xAP_developer@xxxxxxx]On
Behalf Of Kevin Hawkins
> Sent: Friday, 29 July 2005 1:57 a.m.
> To: xAP_developer@xxxxxxx
> Subject: Re: [xAP_developer] BSC protocol
>
>
Thanks for the comments Kevin - I'll ponder that for awhile.

Just a couple of spec clarifications:
1) BSC spec and xAP spec has a number of UID's with '00' in the subaddress
field yet the xAP spec states that FF and 00 are reserved fields for
"all
elements of the subaddress".  Also confused because FF is used for the
domain element of the UID .
2) Expanding a little on point 1. The UID is made up of nn dd dd ss
elements. When the spec says 00 and FF are reserved for all elements does
i=
t
mean 'dd dd' is one element or two ie. is '00 01' OK , '01 00' is OK but
'0=
0
00' isn't.
3) BSC spec - in the cmd section it gives an example using wildcard of
outside.> for the subaddress and matches that to 'porchlight'.  Is that
a
typo or am I missing something here?

Cheers
Shane


> Shane Harrison wrote:
>
> >Hi there,
> >
> >Just implemented a helper app for my Linet lighting system ie.
> to xAP enable
> >it.  I was using BSC.
> >
>
> Great - well done.. I don't know a lot about the Linet system
> unfortunately
>
> >  I noticed that the Level tag allows for the reporting
> >of a ? value where the level is unknown.  However in the other
direction=
,
> >often such devices (as mine is) don't allow you to set a
> particular level -
> >only "up" or "down".  I can't track the up's
and down's either since the=
y
> >can be adjusted internally without outside knowledge.
> >
> >
> So you can't recover (by enquiry) from your lighting system the level
of
> a given light ??  .. and local changes aren't reported - that's a
shame..=
.
>
> >So question is: was there ever any discussion on having a
> LEVEL=3D++ type tag
> >value pair.  I notice the xPL basic control schema's do include
> such a thing
> >for what it is worth.
> >
> >
> Briefly there was but we had an overriding prority of keeping it
simple
> - and so a few 'features' were not included to the BSCv1.3 spec.   Two
> notable ommisions for lighting are the setting of a ramp rate and the
> increment/decrement on a level device.    From what you mention above
I
> wonder how approriate a level device is for your Linet lighting - can
it
> ever report a level value accurately ?
>
> There are ways around all things though - you could add your own
> specific schema to handle increment/decrement or you could add a
> parameter into the existing BSC command block that held a dimstep
value
>
> eg
> {
> ID=3D02
> State=3DON
> DimStep=3D+7
> }
>
>     Now this 'dimstep' aparameter will  (should)  be ignored by all
> other applications - however there is a risk in a later BSC spec
release
> that we formalise such a  parameter and then your usage might not
agree
> with the official version so I recommend people use an unusual
parameter
> name like DimStep or something (rather than a more generic name like
say
> Step) .  In response to a 'dimstep' then your device should
immediately
> send a BSC event message reporting its new level but I am not sure you
> can do that in your system - are you always sending '?'  - if so is
BSC
> the right choice as other BSC capable devices get no useful info re
> status from it. ??
>
>
> Another approach is to not use a level device but a text device and
then
> you can send whatever you want to it as a text string including say UP
> or DOWN or something, this allows for very sophisticated
control/states
> but I would always stress that BSC is meant for simple devices and
more
> complex ones should really add their own supplementary schema for
their
> extra functionality - In my C-Bus lighting for example implements BSC
> but also a lighting schema as well for more advanced control..   If
you
> intend to release the application for others to use then complete
> adherence to teh spec is obviously required - for an internal
> implementation you might choose a slightly less rigid approach.
>
> Kevin
>
>
>
>
>
>
> >Cheers
> >Shane
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>