Re: BSC and OneWire]

["Michael McSharry" <mcs101main@xxxxxxx>]

------=_NextPart_000_009E_01C4D407.CAD12420
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_009F_01C4D407.CAD12420"

------=_NextPart_001_009F_01C4D407.CAD12420
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Attached is xAPmcs1Wire.exe which is an xap interface to Dallas 1-wire
netw=
ork using DS9097U (serial) DS9490 (USB) or functional equivalent PC
adapter=
s to the 1-wire network.  A full set of 1-wire/Ibutton devices typical of
a=
n HA environment are supported.  This includes temperature, voltage,
humidi=
ty, lightning count, water flow, rainfall, wind direction, wind speed,
rela=
ys, switches, air pressure and probably some others that don't come to
mind=
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
no=
t already installed on the PC then they can be downloaded from ftp://ftp.da=
lsemi.com/pub/auto_id/licensed/Install_1_Wire_Drivers_v400b3.exe
Earlier version of these drivers will also function, however some devices
a=
re not supported with the _v3 and erlier drivers.  These drivers utilize
th=
e Microsoft Jave Virtual Machine.  The JAVA VM will need to be enabled on
t=
he PC.

The file can be placed anywhere.  It will create a \config subfolder and
ma=
y create a \data subfolder.  When executed it will run in the tray and a
mo=
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
h=
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
centr=
alized configuration user interface.  The xap schema to support the
configu=
ration discovery and modification are still enabled, but will cause no
harm=
.=20=20

The application-layer logic of this node was extracted from an existing
Hom=
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 xapBSC.info schema.  The discrete
=
values are reported with xapBSC.event and set with xapBSC.cmd.  All
aspects=
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
map=20
> 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

>=20=20
> 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
expect=20
> to make the UID autogenerated based upon its discovery sequence. 
This=
=20
> means that on any given session a particular sensor's UID will=20
> change.  In my applications that actually use the senor reading,
they=20
> 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
the=20
> case the BSC should only be used for a static environment and not
for=20
> 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=
=20
to have persistance of UID's matched wth names though and xAP was=20
originally conceived with this in mind.

>=20=20
> For example assume a configuration of two xap 1-wire interface=20
> nodes. Each of these nodes will have a different base UID.  A
1-wire=20
> 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
be=20
> 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
change.=20=20
> Same sensor, but a different UID because the UID contains=20
> both interface information and sensor information.
>=20=20
> The BSC schema requires a State property which tends to imply that
a=20
> 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
devices=
=20
> that also do not have a State.  What does it mean for a speed
sensor=20
> 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=
=20
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=
=20
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=
=20
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=
=20
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.

Kevin


>=20=20
>
>     ----- 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
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
schem=
a
>     parsers.  So you could add a 'type=3D1wire' 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
th=
e
>     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
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=3D
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
pai=
rs
>     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
i=
t
>     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 th=
e
>     > OneWire schema I proposed about 6 months ago and am
considering
>     BSC,
>     > but I have a dilema with respect to my xapDataCollection
node.  I=
t
>     > 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.
>     >=20
>     > 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?
>     >=20
>     >
>
>
>
>     *Yahoo! Groups Sponsor*
>     ADVERTISEMENT
>     click here
>     <http://us.ard.yahoo.com/SIG=3D1295h73up/M=3D298184.5639630.6699735=
.3001176/D=3Dgroups/S=3D1705007709:HM/EXP=3D1101575730/A=3D2434970/R=3D0/SI=
G=3D11edksnhv/*http://www.netflix.com/Default?mqso=3D60185402>
>
>
>
>    
-------------------------------------------------------------------=
-----
>     *Yahoo! Groups Links*
>
>         * To visit your group on the web, go to:
>           http://groups.yahoo.com/group/xAP_developer/
>=20=20=20=20=20=20=20=20=20=20=20=20
>         * To unsubscribe from this group, send an email to:
>           xAP_developer-unsubscribe@xxxxxxx
>           <mailto:xAP_developer-unsubscribe@xxxxxxx?subject=3DU=
nsubscribe>
>=20=20=20=20=20=20=20=20=20=20=20=20
>         * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>           Service <http://docs.yahoo.com/info/terms/>.
>
>