Re: BSC and OneWire] + X10 mapping

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Michael McSharry wrote:

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

The approach has been to divide the application into 16 individual
applications each with the 16 sub ID's -a ctually it can be more as
applications like HomeSeer use virtual devices beyond 16  eg
ACME.X10.location.B:Lounge    equiv to FF11110B   and perhpas
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
> interface to which they are connected will change as well.  I expect
> to make the UID autogenerated based upon its discovery sequence.  This
> means that on any given session a particular sensor's UID will
> change.  In my applications that actually use the senor reading, they
> will only use the ID, channel, and type/application fields from the
> source address to uniquely identify the sensor.  Other applications
> that use the UID for identification will become confused.  Is it the
> case the BSC should only be used for a static environment and not for
> one such as this which is dynamic?

Really xAP uses the source address line and not the UID for
identification of devices - it is true that a receiver could look for a
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
originally conceived with this in mind.

>
> 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 unique 16 character hardware ID.  When this sensor is
> connected to one of the two xap interface nodes then the UID will be
> the composite of the base UID of 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 UID 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 device should be able to take on multiple states.  This makes
> sense for Binary devices, but it does not for Level and Stream devices
> that also do not have a State.  What does it mean for a speed sensor
> to be ON or is OFF?  What is the rationale for the schema's
> 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
on at 50% - so the level is like a stored level for the device.  X10
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
apply what interpretation you want to this STATE value - for example a
thermostat could use a TEXT BSC device to report 34.5 degrees and state
of ON/OFF could be applied to the call for heat. However I would
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
it was watching was still active - eg an internet source. If you dont
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
ONOFF value and a level and indeed a TEXT (display) vlaue for all
devices eg so it can say HIGH  LOW instead of ONOFF. hence our
DisplayText parameter to allow such labeling.

Kevin


>
>
>     ----- 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
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?
>     >
>     >
>
>
>
>     *Yahoo! Groups Sponsor*
>     ADVERTISEMENT
>     click here
>     <http://us.ard.yahoo.com/SIG=1295h73up/M=298184.5639630.6699735.3001176/D=groups/S=1705007709:HM/EXP=1101575730/A=2434970/R=0/SIG=11edksnhv/*http://www.netflix.com/Default?mqso=60185402>
>
>
>
>    
------------------------------------------------------------------------
>     *Yahoo! Groups Links*
>
>         * To visit your group on the web, go to:
>           http://groups.yahoo.com/group/xAP_developer/
>
>         * To unsubscribe from this group, send an email to:
>           xAP_developer-unsubscribe@xxxxxxx
>           <mailto:xAP_developer-unsubscribe@xxxxxxx?subject=Unsubscribe>
>
>         * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>           Service <http://docs.yahoo.com/info/terms/>.
>
>