Home Automation in the UK

[Patrick Lidstone <patrick-lidstone@xxxxxxx>]

>On Thu, 3 Sep 1998 21:52:00 +0100, you wrote:

[Big snip]

>>It would be great if we could all pool ideas and come up with a set
of
"UKHA standards"
>>which could either be based on existing commercial products or be
tailored to the
>>UK/European market.
>This is something that has been lurking in the back of my brain for a
>while. Why are there several implementations of a Linux CM11A/ CP290
>driver? Why don't we all help out by making one the best?

Sounds good to me.

>The architecture I use is based around Linux, but could be ported to
>amy platform with TCP/IP. The key to it is simply networking- each
>hardware device has a network socket server/ driver for it, so control
>software can connect to it across the 'net (local LAN or WAN is no
>different- security can easily be provided by TCP wrappers).
>
>I can telnet to a server and control it directly, use a command line
>client in script or write a Java app using the socket class to give a
>GUI on a PC.

Nice architecture - but sounds like it could get a bit expensive dotting
PCs around the house to provide UI's. The UI problem is a big deal; PCs are
a bit unwieldy; even the DEC terminal I have in my sitting room is too
dominant for my liking. I'll probably get shot for saying this, but I think
we really need something with the same physical format as a Palm Pilot -
with a radio or IR interface. Small, compact, portable - with a
bidirectional interface.

>For collaboration the hard job would be to define a set of guidelines,
>not unlike the fist set of documents written for the Internet- the
>RFCs. Then the command "get status bedside_lamp" could
operate via
>X10, parallel port relay driver, or whatever.
>
>Like the 'real' RFC standards, this home auto protocol would be ASCII
>with simple commands. Something like the POP3 email protocol is
>usually done by software, but I can telnet to the port and use the
>server directly without too much difficulty.

Excellent idea...

>Naming and address resolution is more of a problem- you have a bedside
>lamp, but is it connected by a relay hung off a 8255 I/O card Port B2,
>or X10 via a CP290 on serial port A?

Second protocol layer here perhaps - offering low level control over
various common physical interfaces (serial, parallel etc), and a DNS style
system to register the capabilities of each named device. One obvious
problem with this approach is that the "DNS" server would be a
single point
of failure.

>The standards already defined for SNMP and MIBs probably have a lot
>that can be re-used. Simple Network Management Protocol and Management
>Information Base are used throughout LAN hardware to allow one control
>application to access many different bits of hardware- just like hone
>auto.

I'm not familiar with SNMP and MIB - time to track down the RFCS ;-)

>At an electrical level, I got fed up having to solder several sorts of
>cable together. To fix this, I use 10pin DIL headers and ribbon cable-
>8 data lines, 2 power lines. Simple, easy, cheap and I have PCB foils
>for relay cards, jumpers, LED drivers, input buffers, etc.

[big snip - comments about RJ45 for serial i/f too]

Third protocol layer - physical interface. The specification of the
interface could be done hand-in-hand with the low level control protocols.

[Big snip on Java]

>Now if I only had a bit more spare time all this would be documented
>and downloadable from the WWW ;-(

Please, please do!

>What do you lot out there think?
>
>Can be put together a Free Automation Project with compatible software
>and some basic hardware?

Here's hoping...

Patrick

____________________________________________________________________

List Site: http://www.findmail.com/list/ukha/
To unsubscribe, send to ukha-unsubscribe@xxxxxxx

FREE group e-mail lists at http://www.findmail.com