The UK Home Automation Archive

Archive Home
Group Home
Search Archive

Advanced Search

[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Re: BSC and OneWire]

Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable

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

The sensors discovered on the 1-wire will change over time and the
e to which they are connected will change as well.  I expect to make the
D autogenerated based upon its discovery sequence.  This means that on any
given session a particular sensor's UID will change.  In my applications
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
nsor.  Other applications that use the UID for identification will become
onfused.  Is it the case the BSC should only be used for a static
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
e 16 character hardware ID.  When this sensor is connected to one of the
o xap interface nodes then the UID will be the composite of the base UID
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
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
vice should be able to take on multiple states.  This makes sense for
y devices, but it does not for Level and Stream devices that also do not
ve a State.  What does it mean for a speed sensor to be ON or is OFF? 
is the rationale for the schema's requirement for a device to have a State=
----- 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=
just filter on the source

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


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

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.


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
> 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
> capture all BSC messages of which the 1-wire sensor messages would
> a subset.  I've considered adding a flag as part of the source=20
> subaddress field so the transmitter can identify the sensor value
> be recordable.  I've also considered adding an additional key to
> Info and Event BSC message for this purpose.  My least favorite
> 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
> not break something that is already working.
> Is there a preferred technique to handle this general class of
> where the source wants to convey information as part of the
> but the schema does not directly support such a capability?

xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.