Re: BSC and OneWire] + X10 mapping

["Michael McSharry" <mcs101main@xxxxxxx>]

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

If "application" refers to a process thread then there will be 16
processes=
trying to share a serial connection with something like a CM12U.  This see=
ms like a step in the wrong complexity direction.=20=20=20

If "application" is simply terminology then one UDP port will
have 16 xap s=
ource addresses.  I had made the assumption in my xapProcess node, as well
=
in my general redundancy management approach that there is a one-to-one
rel=
ationship between an xap application, xap source address, and a windows
pro=
cess thread.  I guess this was not a good assumption.  It also seems to
add=
some ill-effects to routing nodes such as a hub that will want to route to=
16 applications based upon 16 heartbeats.  If the CM12U connector only sen=
ds one heartbeat for all 16 applications to make the hub happy, then
failur=
e monitoring nodes will get confused with an application responding, yet
no=
heartbeats being generated.

The Homeseer device model of status, value, and string are mix and match
an=
d none are required.  House codes A through P will use the status
property.=
Other house codes will use only the value property or only the string, or=
some combination of all three.  While I understand that I can make-up uses=
for a device state in a BSC message, the fact that it is required by the s=
chema implies that it has a well-defined meaning.  This is especially true
=
since it is the only required body entry. It fits for binary devices, but
w=
hy impose an artificial/misleading message on analog devices?

I went through the implementation of using the source address flag to
ident=
ify a message for which data collection should be perfomred.  This works
fo=
r cases where the source only sends BSC messages that want to be recorded,
=
but falls apart when something like my Homeseer pluign wants to provide a
c=
ombination of recorded and unrecorded BSC messages.  I  had played with
cha=
nging the source address dynamically based upon the message recordability,
=
but backed off after butting up against the issues similiar to what I
discu=
ssed above on the CM12U connector implementation.  It looks like the most
v=
iable way it to include the record request as part of the message body if
B=
SC is to be used.
----- 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/>.
>
>