Re: Re: [Project] Kbd/LCD device

[Ant Skelton <ant@xxxxxxx>]

Dr John Tankard wrote:
>
> A very good idea, but I am worried that without a centeral controler
> built or designed we could end up with a device that cannot get used,
> perhaps we need to work on three tasks, Lighting, LCD & control
> program

Agreed. None of these devices will successfully interoperate until the
protocol by which they communicate has been defined, and ideally tested
through simulation in software.

> > What's SNAP like these days?

> I used it in my Lighting controler but droped it in favor of
> something more simple because I ran out of space in my PIC's memory.

I've just re-read the SNAP document, and it seems I misremembered it. I
thought it had more to say about the command/control payloads.

I can't see anything else out there that fits the bill for a unified HA
protocol. I'm happy to be corrected, but I think we're looking at
rolling our own. I've seen some discussion along these lines already,
largely along the lines of coercing some other protocol like HTTP or
even ICMP into doing what we want. My advice on that front would be that
we might as well go the extra mile and define the entire protocol from
the ground up, rather than risk being bitten in the future by some
unforeseen limitation of the donor protocol. HTTP for example is fine
for allowing devices to report their status when asked, but because it's
a client-pull model, there's no easy way for a device to actively report
something, for example "hey! somebody just smashed the front
window!".
In a client-server architecture, you'd end up with the central
controller having to poll all its client devices, and polling is well
known to be the work of Satan. In a peer-to-peer environment, it would
be pretty much unworkeable.

In order to get that ball rolling, we need to define two things.
Firstly, the user requirements, ie the expectations of what this system
will be able to do from the people who are going to use it, ie us. This
is of course a function of the marketing department, so over to you Mark
;) This is something to which everybody on this list can usefully
contribute. Even you lurkers! I was thinking maybe one of Grimmy's
infamous web polls might be a good starting point here?

The second prerequisite is to define the system requirements, and this
is a job for the boys in the pointy hats. As far as the interop protocol
is concerned, I'd expect these to be things like: will communicate over
TCP/IP, will adopt a client-server model, will avoid the use of
broadcasts etc.

Hmmm, this is starting to sound like my day job ;)

BTW, if it seems that I've ignored some interim posts, it's not
intentional: I've just discovered that my yahoo mail account (which I'm
using in work at the moment) is throwing any yahoo groups email directly
into the trash! Doh.


cheers

ant
--
/\/\
ant@xxxxxxx                   (`')                  www.ant.org
()
Megawatt Winged Avenger



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/