The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

RE: Introduction


  • Subject: RE: Introduction
  • From: "Patrick Lidstone \(Personal E-mail\)" <patrick@xxxxxxxxxxxx>
  • Date: Tue, 26 Apr 2005 13:18:28 +0100


> Greetings,
>
> I thought I'd take a moment of your time to introduce myself
> to the group.

Ah, hello again :-)

> You may have seen a post I sent to the xAP_Automation group,
> which Stuart picked up on and pointed me in the direction of
> this group.
>
> I'm a developer who has been playing around with home
> automation for 5 or 6 years (www.the-firs.org).  I'm not into
> home automation in a big (eg, expensive!) way, but do have a
> number of X10 modules and a 1-wire network for temperature
> monitoring and the like.

I like the "TiVo now watching" banner!

> Over the last few years, I've written quite a bit of software
> for my own personal use, and after recently discovering xAP
> (or at least, deciding to find more about it), I've realised
> that much of the development I've been doing for myself is
> stuff which I could more easily use existing xAP modules for,
> and spend my time more constructively developing new xAP
> applications which could be released back into the community.
>
> Although I do some .net development, I'm more at home with
> Delphi, which is what most of my existing HA software is
> written in.  Delphi 2005 allows importing of .net libraries,
> although I haven't made the switch to 2005 yet (still on v7).
>  Are there any people using Delphi for xAP development?

I think Delphi can also use OCX's? In which case you might be able to use
my
VB OCX as a starting point prior to diving in to .net?

> >From what I understand, as xAP is "just" a protocol,
then as long as
> >I'm
> happy with UDP communication,  there is no specific need for
> me to use the xAP .net framework.  Is that correct?

The xAP framework adds a lot of value - in terms of being able to connect
to
hubs, parse incoming message elements, build outgoing messages, validate
messages and so. Whilst none of it is terribly difficult in itself, the
combined effort is pretty considerable, and it makes sense to leverage it
where you can - leaving you to concentrate on the app interface bit, rather
than the nuts and bolts of the messaging bit. Also, whilst it sounds like
you're perfectly comfortable with sockets programming, many people find
this
a bit arcane and the xAP framework hides the intricate details nicely.

> At the moment, I have a Meteor/Sipua caller ID program, which
> currently broadcasts over UDP to inform PC clients on
> incoming calls.  In theory (I say "theory" because I'm aware
> there is already a Meteor CID module), if I modified the
> program to send xAP information over UDP (rather than it's
> own protocol, which is what is does at the moment), then that
> would make it an xAP application?  Is that correct? - Is that
> all there is to it, or am I missing something?!

Nope, that's pretty much it. The message you need to send should be sent
broadcast, not point to point, and it needs to adhere to the caller id
schema to be visible within other xAP applications that are CID compliant,
such as xAP desktop. As I mentioned before, you should also try to make
your
apps hub-aware if possible. UDP broadcasts can only be received by a single
endpoint - the hub is a small bit of software that runs on a PC where
multiple xAP apps are installed, that intercepts incoming broadcasts and
redistributes them to any interested xAP applications by rebroadcasting on
the loop back interface.

HTH

Patrick





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.