The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024

Latest message you have seen: Re: [OT] - APC Smart UPS


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

Re: Meteor Caller ID drivers ?


  • To: ukha_d@xxxxxxx
  • Subject: Re: Meteor Caller ID drivers ?
  • From: "patricklidstone" <patrick@xxxxxxx>
  • Date: Thu, 01 May 2003 11:37:23 -0000
  • Mailing-list: list ukha_d@xxxxxxx; contact ukha_d-owner@xxxxxxx
  • Reply-to: ukha_d@xxxxxxx

--- In ukha_d@xxxxxxx, "Nikola Kasic" <nikola@k...> wrote:
> Patrick,
> You often refer to xAP and compare it with Autom8it.
> I thought that xAP is just a protocol, not the application.
> Or there is some application available that can handle xAP messages?
> Please enlighten me :-).

At the base level, xAP is a protocol specification. The protocol
specification is published in the public domain, but is copyright.
Anyone is free, and indeed is encouraged, to implement applications
or devices which comply with the protocol. The overall goal is to
promote inter-operability between devices; you can think of it as an
esperanto for HA if you like.

A number of people - myself included - have implemented SDKs
(software development kits) which allow xAP compliant applications to
be built quickly and easily. The terms under which these are made
available varies, but most, if not all, are free for non-commercial
use.

Then at the top level, built on the SDKs, there are a wide variety of
applications. These provide xAP connectivity for a given device or
software application. Examples include: notification of new e-mail
arriving; LCD display drivers; caller id interfaces and so on.

Because xAP is fundamentally a broadcast protocol, any xAP
device/application can potentially act on information broadcast by
any other device/application. This gives a high level of resilience -
you don't *have* to rely on a central controller, and if the central
controller breaks, the system can degrade gracefully. (Having a
central, or at least powerful, PC in the system does make sense for
stuff like web serving, and they do have a place - I just don't want
to rely on them to ensure I get up in the morning!) The esperanto
nature of xAP makes it very easy to add new devices/applications
without having to spend ages reprogramming the rest of the system to
recognise that device: as often as not, the new device "just
works".

Coming back to the central controller issue: Today, whether you use
Autom8it, Homeseer or whatever, when you add a new device you rely on
a plugin being available to support that device. There is a huge
amount of duplicate effort being expended - there are umpteen meteor
plug-ins for example - wouldn't be easier if there was
one "universal" one which was enough? If these controllers choose
to
support xAP (as Mister House has done) they then have instant access
to all current and future xAP devices, with xAP providing a kind
of "Universal plugin" architecture. For the end user that is a
pretty
compelling proposition... but it also levels the playing field
somewhat for the authors of cental controller software, and I can
understand why that is scary for them. Fortunately, most Win based
controllers provide access to VB script - and embedding for an end-
user to embed the xAP active X contol is, for the most part, straight
forward, so they don't have to rely on the controller developers
providing integral support to leverage xAP... (Although I'm sure
integral support will come with time -- and I'm looking forward to
it :-)

Patrick





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.