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: Home Automation in the UK


  • To: ukha@xxxxxxx
  • Subject: Re: Home Automation in the UK
  • From: james@xxxxxxx (James Derrick)
  • Date: Fri, 04 Sep 1998 17:16:49 GMT
  • Delivered-to: listsaver-findlist-ukha@xxxxxxx
  • Mailing-list: contact ukha-owner@xxxxxxx
  • References: <01BDD785.7EB427C0@xxxxxxx>

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

>Hi All,
>
>From the recent flurry of activity on this list it seems that there are
=
several of us
>designing our own systems due to the high cost or non availability of =
commercial
>products. It also seems that there is a certain amount of duplication =
with 2 or 3
>people developing almost identical lighting systems etc.
That is definitely the case here- I started with completely home-brew
kit, but have moved to some 230V X10 as the features developed.

>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?

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).=20

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.

=46or 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.

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?=20

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.

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.=20

With some more imagination, I bet we could put something together at
this level to allow serial, parallel, I/O cards, etc to talk to a
whole range of things from mains lighting to doorbells.=20

I've seen a neat use of RJ45 jacks to provide universal serial ports-
no more DCE/DTE- just a commonly-wired jack that fits standard cable
bits. Again, simple, cheap, and easy.

At the moment my workbench contains a rather neat anemometer kit from
a chap in Australia called Derek Weston. I'm writing the Linux driver
using this architecture. Next comes a PIC-based LCD display terminal
based on LCDproc that does lots of neat things already.
http://www.alphalink.com.au/~derekw/ane/anemain.htm
http://lcdproc.omnipotent.net/

The master plan uses an Java as the GUI, Linux PCs for the back end
and serial LCD terminals for things like alarm control panels. This
way, the house gains a TCP/IP nervous system with servers
communicating to clients regardless of the hardware they are on.=20

The server networking means the hardware can be used from a PC GUI,
data logger or a complex control program all at the same time.=20

Java allows you to run the GUI on the server, family PC, or the old
386 that is just fast enough for Windows 3.1. There is also the JAva
Comms API that provides access to the serial and parallel ports
regardless of the hardware you are running on- perfect for an
universal CM12U X10 driver!

Right now, I don't have the Java client software, but just being able
to use a WWW browser to turn the lights on without leaving the work
desk is kinda neat.

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

What do you lot out there think?=20

Can be put together a Free Automation Project with compatible software
and some basic hardware?=20

With the long winter nights not far away, this could be just the time
to start kicking around ideas...

James
---
James Derrick    james@xxxxxxx, Cramlington, Near Newcastle, =
England
Forwarding Service: jderrick@xxxxxxx
Beyond the Horizon of the place we lived when we were =
young,
In a World of Magnets and Miracles. Pink Floyd.

____________________________________________________________________

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


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.