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] + X10 mapping

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

If "application" refers to a process thread then there will be 16
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
ationship between an xap application, xap source address, and a windows
cess thread.  I guess this was not a good assumption.  It also seems to
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
e monitoring nodes will get confused with an application responding, yet
heartbeats being generated.

The Homeseer device model of status, value, and string are mix and match
d none are required.  House codes A through P will use the status
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
hy impose an artificial/misleading message on analog devices?

I went through the implementation of using the source address flag to
ify a message for which data collection should be perfomred.  This works
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
ombination of recorded and unrecorded BSC messages.  I  had played with
nging the source address dynamically based upon the message recordability,
but backed off after butting up against the issues similiar to what I
ssed above on the CM12U connector implementation.  It looks like the most
iable way it to include the record request as part of the message body if
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
> 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.