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]

xAP - The Proposed Architecture Explained...


  • To: <ukha_d@xxxxxxx>
  • Subject: xAP - The Proposed Architecture Explained...
  • From: "Mark Harrison" <Mark.Harrison@xxxxxxx>
  • Date: Wed, 14 Aug 2002 10:37:32 +0100
  • Mailing-list: list ukha_d@xxxxxxx; contact ukha_d-owner@xxxxxxx
  • Reply-to: ukha_d@xxxxxxx

The proposed architecture is such that there will be, on the "network", multiple different "input" devices all BROADCASTING their information.

It will be up to each individual "output" device to determine which of those messages it treats as things to display, and which it treats as potential triggers.

I'm imagining that each input device will broadcast a message containing four things:

- The Name of the Output plugin
- The Instance of the Output plugin
- The Name of the information item
- The Content of the information item


Let's give an example:

I have three input plugins, HomeVision, my Outlook, Mary's Outlook

When I receive a new message (bringing my unread count to 13, say), an xAP plugin running on my inbox (in development by Mrs. H as we speak!) sends a message that reads:

- Output Plugin: Outlook
- Output Instance: Mark
- Output Name: Unread count
- Output Content: 13

I also have several output devices. The device in my study (a VFD) is set up to display:

- Line 1: The current date and time (interally held)
- Line 2: The external temperature (sent from the HomeVision plugin using a 1wire sensor and an HV macro)
- Line 3: My unread message count

The device in Mary's study (a VFD) is set up to display

- Line 1: The current date and time (interally held)
- Line 2: The external temperature (sent from the HomeVision plugin using a 1wire sensor and an HV macro)
- Line 3: HER unread message count

BOTH devices receive the message, because it's broadcast. Mine determines that "Outlook / Mark / Unread Count" is a piece of information it's interested in, and therefore updates the display. Mary's determines that "Outlook / Mark / Unread Count" is a piece of information it's NOT interested in, and ignores it.


Next I receive a message which says:

- Output Plugin: HomeVision
- Output Instance: 9MC (ie - the HomeVision at this house)
- Output Name: Trigger
- Output Content: Trigger 1 ON (ie - the doorbell has been pressed)

In this instance, BOTH devices respond, by changing Line 1 away from the current date and time, and instead displaying the hard-wired message "Someone at the door" in flashing type.

(Then, when I open the door, the power flash module triggers HV, so it sends Trigger 1 OFF.)



Now, in order to pull this off, the input devices need to be capable of:

1: Listening to the broadcasts
2: Determining, by looking at their configuration paramaters, what they're interested in, with the added complexity that there might be multiple states, which are transitioned between when certarin messages are received.

Being an "old hand" Unix type, I can see how to do "1" and "2" _VERY_ easily on a Linux box. Therefore, for me, the obvious Output plugin would be a daemon running on the Linux box that drove a serial output, that drove some LCD / VFD display. (In fact, I'd probably install multiple serial ports and run several, so there'd be a "message forking" daemon as well to multiple instances of the "serial LCD plugin", each with its own config. On Linux, it's fairly obvious how I could write separate config utilities for each serial port.

For a Tini / Rabbit / Siteplayer, there'd need to be some development to build in this logic, probably with the ability to change the config remotely, so some remote admin tool. This is beyond me (but well within in the capability of others.)

One key advantage of doing things this way is that, once I'm 12 months down the line, and have 20 input plugins, then I get a  (by then cheap) 14" TFT screen, and an "el cheapo" P2-300 PC, and have a "full ouput" that displays 20 of them on a hi-res screen, rather than 3 on a VFD screen. This is a long-winded way of saying that it scales up to different output devices as time goes by.

Another key advantage is that incorporating another input trigger is simply a matter of installing it, and changing the CONFIG of the output devices you want to use it, not by changing ANY code on the output device handler.

A third key advantage is that it kind of makes things obvious how various "bridges" could be written, such as :

- An ethernet to SNAP bridge
- An ethernet to ethernet bridge (over the internet), so that I can see the triggers from input sources in my (proposed) penthouse flat in Mayfair :-)

A fourth key advantage is that it's possible to start small. A small LAN, a single PC running outlook, and another PC (or, heh, even the same PC) running an output display server for a serial device...



Mark

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.