The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Re: xAP - The Proposed Architecture Explained - the first extensio


  • To: <ukha_d@xxxxxxx>
  • Subject: RE: Re: xAP - The Proposed Architecture Explained - the first extensio
  • From: "Mark Harrison" <Mark.Harrison@xxxxxxx>
  • Date: Wed, 14 Aug 2002 14:08:25 +0100
  • Mailing-list: list ukha_d@xxxxxxx; contact ukha_d-owner@xxxxxxx
  • Reply-to: ukha_d@xxxxxxx

Patrick wrote (inter alia):

I also think you need to review the addressing mechanism. In your
previous mail you spoke of the input plug-in using specifying the
output-plugin address. I don't know if this is a typo, or what you
intenteded, but the input device should simply identify the unique
data source, nothing more. The output device is then configured to
listen to a given data source. This is an important and subtle
distinction.

--- It was a typo. The input device simply identifies the unique data source. The output device is configured as to which data sources it's listening out for.

Imagine that you have a caller id plugin. This plugin is dumb and
broadcasts just the phone number. You want to display the name of the
caller too. This requires cascading of plug-ins. The caller-id output
is picked up by a name/address lookup device and then re-broadcast
with additional information appended for display.

--- Yup - makes a lot of sense.

It is also common-sense to establish some standard HA data types, so
that all devices represent certain attributes (e.g. temperature) in
the same way. I would recommend a policy which includes a text device
status field (for display use etc) and also includes value fields.

e.g. "Outside temp. 31'c"; out_temp_C=31.2

--- This is why I'm suggesting an XML-style model. What I've called "value" is better as "display value", but other fields can be broadcast.

This suggests that messages should have a header + body, with the
body being hierarchial. It also suggests it might be useful to embed
some kind of hop-count might be useful. Conveniently this meets most
of the requirements of a bridging protocol too.

Finally, some thought needs to be given to group addressing or the
concept that a device might belong to more than one address space.
Eg. it may be desirable to send messages to all
displays "downstairs". Where is this mapping maintained? Probably as
a service running fault-tolerant on one or more PC's with an LDAP
backend.

- The messages are, in my view, simply broadcast. The displays downstairs have to work out whether they want to do anything with the messages received. This mapping, therefore is maintained in the config of the display devices. (Which may, of course, have a central management tool / console / database, but that's within the scope of the set of display devices possible.)



Yahoo! Groups Sponsor
ADVERTISEMENT

For more information: http://www.automatedhome.co.uk
Post message: ukha_d@xxxxxxx
Subscribe:  ukha_d-subscribe@xxxxxxx
Unsubscribe:  ukha_d-unsubscribe@xxxxxxx
List owner:  ukha_d-owner@xxxxxxx

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Home | Main Index | Thread Index

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.