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: BSC and OneWire]

Content-Type: multipart/alternative;

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

Attached is xAPmcs1Wire.exe which is an xap interface to Dallas 1-wire
ork using DS9097U (serial) DS9490 (USB) or functional equivalent PC
s to the 1-wire network.  A full set of 1-wire/Ibutton devices typical of
n HA environment are supported.  This includes temperature, voltage,
ty, lightning count, water flow, rainfall, wind direction, wind speed,
ys, switches, air pressure and probably some others that don't come to
at the moment.  I'm making it available to enhance the library of BSC-comp=
liant applications.

The software uses the drivers developed by the Dallas Semiconductor.  If
t already installed on the PC then they can be downloaded from ftp://ftp.da=
Earlier version of these drivers will also function, however some devices
re not supported with the _v3 and erlier drivers.  These drivers utilize
e Microsoft Jave Virtual Machine.  The JAVA VM will need to be enabled on
he PC.

The file can be placed anywhere.  It will create a \config subfolder and
y create a \data subfolder.  When executed it will run in the tray and a
use click on the icon will provide selection options which include
"Setup" =
"IO Window" and "Exit".  The other options have been
disabled as they only =
have meaning in the context of a system with other xap nodes that support
ealth, redundancy management and centralized configuration management.

The "Setup" will show a Windows GUI that I quickly put together
to provide =
a stand-alone user interface.  Normally this node is configured via a
alized configuration user interface.  The xap schema to support the
ration discovery and modification are still enabled, but will cause no

The application-layer logic of this node was extracted from an existing
eseer plugin so some of the setup context is not obvious.  For typical use
the "Poll" button, the Metric/English units selection, and the
sample inter=
val will be the only setup items of interest.

The analog values are returned using the schema.  The discrete
values are reported with xapBSC.event and set with xapBSC.cmd.  All
of the BSC 1.3 schema have been implemented.  Each 1-wire device has 6 xAP=
UID values reserved.  This means a little over 40 devices can be supported=
per instance of the application.  The body of the BSC xap message also has=
a Database=3DTrue key/value as these values are intended to be recorded by=
the xap datacollection node.

----- Original Message -----=20
From: Kevin Hawkins=20
To: xAP_developer@xxxxxxx=20
Sent: Friday, November 26, 2004 11:58 AM
Subject: Re: [xAP_developer] BSC and OneWire] + X10 mapping

Michael McSharry wrote:

> What are those doing BSC for the X10 interface adapters doing to
> the 255 BSC codes into the 256 X10 codes?

The approach has been to divide the application into 16 individual=20
applications each with the 16 sub ID's -a ctually it can be more as=20
applications like HomeSeer use virtual devices beyond 16  eg=20=20=20
ACME.X10.location.B:Lounge    equiv to FF11110B   and perhpas=20
ACME.X10.location.A:HallLamp equiv to FF111004

We are discussing expanding the length of the UID for exactly this reason

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

Really xAP uses the source address line and not the UID for=20
identification of devices - it is true that a receiver could look for a=20
UID as a match but I dont think it happens in practice. It would be nice=
to have persistance of UID's matched wth names though and xAP was=20
originally conceived with this in mind.

> For example assume a configuration of two xap 1-wire interface=20
> nodes. Each of these nodes will have a different base UID.  A
> sensor has a unique 16 character hardware ID.  When this sensor is=20
> connected to one of the two xap interface nodes then the UID will
> the composite of the base UID of the node and a mapping of the 16=20
> characters into two hex digits.  If this sensor is moved from the=20
> first xap interface node to the second, then the UID will
> Same sensor, but a different UID because the UID contains=20
> both interface information and sensor information.
> The BSC schema requires a State property which tends to imply that
> BSC device should be able to take on multiple states.  This makes=20
> sense for Binary devices, but it does not for Level and Stream
> that also do not have a State.  What does it mean for a speed
> to be ON or is OFF?  What is the rationale for the schema's=20
> requirement for a device to have a State property?

Some Level devices do have a use for STATE for example a light can be at=
level 50% but ON or OFF - if it is off and then turned ON it would come=20
on at 50% - so the level is like a stored level for the device.  X10=20
breaks this and comes on at 100% of course ! (but that would be apparent=
from teh content of the  .event that would be sent)  You can choose to=20
apply what interpretation you want to this STATE value - for example a=20
thermostat could use a TEXT BSC device to report 34.5 degrees and state=20
of ON/OFF could be applied to the call for heat. However I would=20
recommend a different schema for this. Perhpas a Text device showing the=
last share price for Microsoft could use ON /OFF to show the feed data=20
it was watching was still active - eg an internet source. If you dont=20
have a use for it leave it set as one or the other.   Some of this comes=
from the fact that HomeSeers state model is based around keeping an=20
ONOFF value and a level and indeed a TEXT (display) vlaue for all=20
devices eg so it can say HIGH  LOW instead of ONOFF. hence our=20
DisplayText parameter to allow such labeling.


>     ----- Original Message -----
>     *From:* Kevin Hawkins <mailto:lists@xxxxxxx>
>     *To:* xAP_developer@xxxxxxx
>     <mailto:xAP_developer@xxxxxxx>
>     *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
>     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
>     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
>     parsers.  So you could add a 'type=3D1wire' value into a BSC body.
>     generally discourage this because it pollutes the purity of the
>     message
>     but it is permitted.  We used it to allow for experimentation in
>     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.=20
>     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
>     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=3D
>     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
>     within the header) errors are thrown by a hub or something. and
>     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
>     hasn't been a high priority issue. Keynames of Test00 to Test99
>     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 th=
>     > OneWire schema I proposed about 6 months ago and am
>     BSC,
>     > but I have a dilema with respect to my xapDataCollection
node.  I=
>     > captures all messages on the OneWire schema, but I do not
>     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
>     > subaddress field so the transmitter can identify the sensor
>     value to
>     > be recordable.  I've also considered adding an additional key
>     the
>     > Info and Event BSC message for this purpose.  My least
>     choice
>     > it to put a GUI interface on xapDataCollection where
>     > messages can be selected for recording.  I really want the
>     > recordability knowledge to exist at the source rather than at
>     > target.  The easiest solution is to just leave
>     and
>     > not break something that is already working.
>     >=20
>     > Is there a preferred technique to handle this general class
>     problem
>     > where the source wants to convey information as part of the
>     message,
>     > but the schema does not directly support such a capability?
>     >=20
>     >
>     *Yahoo! Groups Sponsor*
>     click here
>     <
>     *Yahoo! Groups Links*
>         * To visit your group on the web, go to:
>         * To unsubscribe from this group, send an email to:
>           xAP_developer-unsubscribe@xxxxxxx
>           <mailto:xAP_developer-unsubscribe@xxxxxxx?subject=3DU=
>         * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>           Service <>.

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.