Re: BSC protocol

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Shane Harrison wrote:

>=20=20
>
>>-----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
>>
>>
>>=20=20=20=20
>>
>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 .
>=20=20
>
Ahh..  ok that probably needs a little bit of expanding upon  I
guess.=20=20
It was meant to apply to teh higher order part of the device address=20
only and there have been a couple of instances where the reserved 00 or=20
FF has been applied a special meaning already (FFxxxxxx =3D local network,=
=20
xxxxxx00 =3D main application sub address)
Assuming a UID is in the format NNDDDDSS (this may be expanded later btw)

The following are reserved

00xxxxxx
xxxxxxFF
xxFFxxxx
xx0000xx

I do not believe xx00xxxxxx is reserved unless someone wants to correct=20
me ? However probably best to avoid this range FTTB pending confirmation.


>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 =
it
>mean 'dd dd' is one element or two ie. is '00 01' OK , '01 00' is OK
but '=
00
>00' isn't.
>=20=20
>
yes, sorry that's what we meant to convey - certainly 0000 is reserved=20
but I am not sure re 00xx - I think that is OK (see above)

>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?
>=20=20
>
Ahhh - well spotted - that's a typo -  I'll get it corrected . If anyone=20
else has spotted any others  please let me know.

The line should read

ACME.Lighting.apartment:outside.porchlight

I have just made an adjacent post on current wildcarding usage that I=20
hope clarifies some of this too

Kevin


>Cheers
>Shane
>
>
>=20=20
>
>>Shane Harrison wrote:
>>
>>=20=20=20=20
>>
>>>Hi there,
>>>
>>>Just implemented a helper app for my Linet lighting system ie.
>>>=20=20=20=20=20=20
>>>
>>to xAP enable
>>=20=20=20=20
>>
>>>it.  I was using BSC.
>>>
>>>=20=20=20=20=20=20
>>>
>>Great - well done.. I don't know a lot about the Linet system
>>unfortunately
>>
>>=20=20=20=20
>>
>>> 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
>>>=20=20=20=20=20=20
>>>
>>particular level -
>>=20=20=20=20
>>
>>>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.
>>>
>>>
>>>=20=20=20=20=20=20
>>>
>>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..=
.
>>
>>=20=20=20=20
>>
>>>So question is: was there ever any discussion on having a
>>>=20=20=20=20=20=20
>>>
>>LEVEL=3D++ type tag
>>=20=20=20=20
>>
>>>value pair.  I notice the xPL basic control schema's do include
>>>=20=20=20=20=20=20
>>>
>>such a thing
>>=20=20=20=20
>>
>>>for what it is worth.
>>>
>>>
>>>=20=20=20=20=20=20
>>>
>>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
>>
>>
>>
>>
>>
>>
>>=20=20=20=20
>>
>>>Cheers
>>>Shane
>>>
>>>
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>=20=20=20=20=20=20
>>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>=20=20=20=20
>>
>
>
>
>
>=20
>Yahoo! Groups Links
>
>
>
>=20
>
>
>
>
>=20=20
>