xAP - The Proposed Architecture Explained...

["Mark Harrison" <Mark.Harrison@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.