Re: Re: BSC and OneWire]

["Michael McSharry" <mcs101main@xxxxxxx>]

------=_NextPart_000_000A_01C4D27D.434951C0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'll sketch out how encoding the information in the source address will
pla=
y out.  It will tend to get pretty long as it will have placeholders for
th=
e 1wire flag, interface port, sensor id, channel, and
sensorType/Applicatio=
n.  I'm assuming there is not a restriction on the length of the source
fie=
ld.

The sensors discovered on the 1-wire will change over time and the
interfac=
e to which they are connected will change as well.  I expect to make the
UI=
D autogenerated based upon its discovery sequence.  This means that on any
=
given session a particular sensor's UID will change.  In my applications
th=
at actually use the senor reading, they will only use the ID, channel, and
=
type/application fields from the source address to uniquely identify the
se=
nsor.  Other applications that use the UID for identification will become
c=
onfused.  Is it the case the BSC should only be used for a static
environme=
nt and not for one such as this which is dynamic?=20=20

For example assume a configuration of two xap 1-wire interface nodes. Each
=
of these nodes will have a different base UID.  A 1-wire sensor has a
uniqu=
e 16 character hardware ID.  When this sensor is connected to one of the
tw=
o xap interface nodes then the UID will be the composite of the base UID
of=
the node and a mapping of the 16 characters into two hex digits.  If this =
sensor is moved from the first xap interface node to the second, then the
U=
ID will change.  Same sensor, but a different UID because the UID contains
=
both interface information and sensor information.

The BSC schema requires a State property which tends to imply that a BSC
de=
vice should be able to take on multiple states.  This makes sense for
Binar=
y devices, but it does not for Level and Stream devices that also do not
ha=
ve a State.  What does it mean for a speed sensor to be ON or is OFF? 
What=
is the rationale for the schema's requirement for a device to have a State=
property?
----- Original Message -----=20
From: Kevin Hawkins=20
To: xAP_developer@xxxxxxx=20
Sent: Wednesday, November 24, 2004 3:46 PM
Subject: [Fwd: Re: [xAP_developer] BSC and OneWire]



Hi Michael,

Wouldn't it be possible to group all your 1-wire devices by a level=20
within the source address (not the sub address) to achieve this and then=
=20
just filter on the source

eg setup a filter for  *.*.*.1wire:>     or something  ??

mcs.Sensor.Lounge.1wire:temp.outside

If not then there is an allowance within the spec that says that=20
unexpected key name/values within the header or bodies should be=20
gracefully ignored. This allows for you to add your own key values into=20
a header of an existing schema without breaking  the existing schema=20
parsers.  So you could add a 'type=3D1wire' value into a BSC body.  We=20
generally discourage this because it pollutes the purity of the message=20
but it is permitted.  We used it to allow for experimentation in the=20
header and in that instance we recommended people use key names of=20
Test00  to Test99 and made people aware (via this list) of what=20
interpretation they were putting on these names to test any new features=
=20
that people might wish to see suggested as enhancements to xAP.  So far=20
we haven't seen much, if any need to use this, the only one I can think=20
of is that it has been used for xAP groups and scenes but a neater=20
solution was settled upon. The risk is that should you elect to use a=20
keyname that coincidently later became part of the official schema then=20
you would need to change it as it wouldn't comply with teh official spec=
=20
and BSC is an official 'xAP' spec (xAPBSC). Hence in existing schemas a=20
slightly obsure naming is probably a wise precaution eg dtype=3D or somet=
hing.

Likewise if you wanted to add your own extra custom blocks you could=20
within an existing schema (I think??) - they should just be ignored and=20
not cause errors .

One problem is that this aspect of the spec was overlooked by=20
several early apps so you might find that (certainly with extra pairs=20
within the header) errors are thrown by a hub or something. and the=20
message is dropped as being 'non conformant'. This is a know issue and=20
on the 'to do' list I believe - but as no-one uses this currently it=20
hasn't been a high priority issue. Keynames of Test00 to Test99 are=20
passed OK in the headers in current hubs AIUI.

Kevin


Michael McSharry wrote:

> I have a set of Dallas 1-wire networks running under xap using the=20
> OneWire schema I proposed about 6 months ago and am considering
BSC,=20
> but I have a dilema with respect to my xapDataCollection node.  It=20
> captures all messages on the OneWire schema, but I do not want it
to=20
> capture all BSC messages of which the 1-wire sensor messages would
be=20
> a subset.  I've considered adding a flag as part of the source=20
> subaddress field so the transmitter can identify the sensor value
to=20
> be recordable.  I've also considered adding an additional key to
the=20
> Info and Event BSC message for this purpose.  My least favorite
choice=
=20
> it to put a GUI interface on xapDataCollection where individual=20
> messages can be selected for recording.  I really want the=20
> recordability knowledge to exist at the source rather than at the=20
> target.  The easiest solution is to just leave well-enough-alone
and=20
> not break something that is already working.
>=20=20
> Is there a preferred technique to handle this general class of
problem=
=20
> where the source wants to convey information as part of the
message,=20
> but the schema does not directly support such a capability?
>=20=20
>