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: xAP - The Proposed Architecture Explained - the first extensio


  • To: ukha_d@xxxxxxx
  • Subject: Re: xAP - The Proposed Architecture Explained - the first extensio
  • From: "PatrickLidstone" <patrickl@xxxxxxx>
  • Date: Wed, 14 Aug 2002 12:50:36 -0000
  • Mailing-list: list ukha_d@xxxxxxx; contact ukha_d-owner@xxxxxxx
  • Reply-to: ukha_d@xxxxxxx

--- In ukha_d@y..., "Mark Harrison" <Mark.Harrison@e...> wrote:
> OK - firstly, the idea is that the messages will be in XML, so that
the message structure can be expanded.

Don't do it! XML is fine as a notation to represent the messages but
the wire format absolutely should not be XML. As I have said before,
it is not suited for parsing by embedded devices, and is also an
unnecessary waste of network bandwidth.

> This is good, since I have a fifth, optional item. The IP address
of the "master bridge". This will be required for WAN implementations
where an ethernet-ethernet bridge is being used. It's purpose is to
obviate the need for globally distinct namespaces, and allow both Mr.
McCall and I to sit in the same office, both reading messages from a
HomeVision at home called "Mark".


This assumes there is one bridge. I think there will be more than 1.
The bridge can be intelligent, introspecting messages. No explicit
addressing is needed.

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.

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.

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 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.

PS. The seetron 20x4 VFD arrived this morning. I have it working,
connected to a rabbit, with a simple web driven interface. Adding
broadcast intelligence should be straightforward. The displays are
nicely made - and the driver software quite intelligent (e.g. auto-
dims if no new message is displayed after given period).



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.