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]

RE: Re: [Project] Kbd/LCD device


  • To: ukha_d@xxxxxxx
  • Subject: RE: Re: [Project] Kbd/LCD device
  • From: "Paul Gordon" <paul_gordon@xxxxxxx>
  • Date: Tue, 05 Jun 2001 10:48:52 +0100
  • Delivered-to: rich@xxxxxxx
  • Delivered-to: mailing list ukha_d@xxxxxxx
  • Mailing-list: list ukha_d@xxxxxxx; contact ukha_d-owner@xxxxxxx
  • Reply-to: ukha_d@xxxxxxx

There's some thoughts here though...

IM has some interesting features that could be directly mapped so some
useful functions in a HA scenario...

IM uses "presence information" to set instantly changeable status
modes,
such as:
online
offline
busy
on the phone
out to lunch
appear offline
Be right back
away

etc...

>From a device perspective, I reckon it could be useful to implement a
similar ability for any device on the network to independantly set it's
status to any of several modes, such as:

online
offline
locked
do not disturb
alarm

etc...

The device could switch between modes independantly according to it's own
local programming, depending on various conditions, or the controller could
set it into any mode (for instance, a lighting controller which is in the
Home cinema room could be set to "do not disturb" mode when a
movie is being
watched, to prevent it responding to lighting commands & turning the
room
lights on during the film)

Don't know how practical all this is, but it just struck me when the IM
protocol was mentioned, that the presence information features of IM could
be useful for us. - Any device on the net can change status, but more
importantly, ALL other devices on the net are aware of the status change
almost instantaneously...

£0.02

Paul G.


>From: "Broadfoot, Kieran J" <Kieran.Broadfoot@xxxxxxx>
>Reply-To: ukha_d@xxxxxxx
>To: "'ukha_d@xxxxxxx'" <ukha_d@xxxxxxx>
>Subject: RE: [ukha_d] Re: [Project] Kbd/LCD device
>Date: Mon, 4 Jun 2001 16:58:18 +0100
>
>I agree a simple socket based network protocol is more than adequate. 
Do
>we
>need the complexity of IM or IRC though?  Take a look at smtp or ftp
for
>instance.  The handshaking and comms is very simple and pretty much as
much
>complexity as we need.
>
>Thanks
>	Kieran
>
>-----Original Message-----
>From: patrickl@xxxxxxx [mailto:patrickl@xxxxxxx]
>Sent: Monday, June 04, 2001 4:48 PM
>To: ukha_d@xxxxxxx
>Subject: [ukha_d] Re: [Project] Kbd/LCD device
>
>
>
> > > The model I'm thinking of is more along the lines of
> > > each client device opening a connection to the
> > > central
> > > server, which remains open indefinitely, and which
> > > is
> > > bi-directional: either party may send a message to
> > > the
> > > other at any time. A good metaphor for this style of
> > > communication would be any of those instant
> > > messenging
> > > protocols.
>
>Now there's an interesting starting point (IM).
>Another interesting starting point could also be a bastardised
>version of IRC.
>
>
> > > Ideally, I'd like to see each node communicating in
> > > this way, but I'd also like to see them with a
> > > simple
> > > web/cgi interface for configuration and monitoring
> > > from a browser, and an even simpler remote
> > > command-line interface (like a really lame telnet
> > > implementation) for doing the same thing, which can
> > > also be accessed from a serial interface.
> > >
> > > Does that lot make any sense, or am I talking
> > > bollocks?
>
>Spot on mate.
>
>Patrick
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.




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




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.