[Fwd: Re: BSC and OneWire]

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Hi Michael,

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

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

One problem is that this aspect of the spec was overlooked by
several early apps so you might find that (certainly with extra pairs
within the header) errors are thrown by a hub or something. and the
message is dropped as being 'non conformant'. This is a know issue and
on the 'to do' list I believe - but as no-one uses this currently it
hasn't been a high priority issue. Keynames of Test00 to Test99 are
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
> OneWire schema I proposed about 6 months ago and am considering BSC,
> but I have a dilema with respect to my xapDataCollection node.  It
> captures all messages on the OneWire schema, but I do not want it to
> capture all BSC messages of which the 1-wire sensor messages would be
> a subset.  I've considered adding a flag as part of the source
> subaddress field so the transmitter can identify the sensor value to
> be recordable.  I've also considered adding an additional key to the
> Info and Event BSC message for this purpose.  My least favorite choice
> it to put a GUI interface on xapDataCollection where individual
> messages can be selected for recording.  I really want the
> recordability knowledge to exist at the source rather than at the
> target.  The easiest solution is to just leave well-enough-alone and
> not break something that is already working.
>
> Is there a preferred technique to handle this general class of problem
> where the source wants to convey information as part of the message,
> but the schema does not directly support such a capability?
>
>