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]

[Project] Re-post of habuy topics missed on ukha


  • To: ukha_d@xxxxxxx
  • Subject: [Project] Re-post of habuy topics missed on ukha
  • From: "Dr John Tankard" <john@xxxxxxx>
  • Date: Mon, 21 May 2001 17:28:12 +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

Below is the (Long) repost of the messages on ukbuy which started this
snowball.

I have tried to just include posts which might be usefull, If I have
missed any I am sorry, but I have had to lend my PC with outlook on it
for a few days, so this is composed using a web interface and it is not
the best tool for the job.  If anyone spots a post I have missed please
re-post it

John




Date: Wed, 16 May 2001 16:05:46 +0100
From: "Dr John Tankard" <john@xxxxxxx>
Subject: Collaborative HA Projects

Posting this here because of the copyright rules on yahoo.

The Ideas I am thinking about include.

Lighting controller. This would replace a battery of DIN Rail modules and
work as a multi channel controller, perhaps with X10 send and receive
built
in but also TCP/IP control, it could use RS485 to talk with keypads or use
home run wiring as the x10 DIN rail's do, allowing the system to be
returned
to near normal. The system would handle presets, ramp up/down soft start
etc.

Hardware TCP/IP link for Homevision/comfort, this could replace the
computer
in the link to allow web control without a PC

TCP/IP link to the Davis weather station, I know there is one for the
Dallas
station, but the Davis system is a bit more commercial.

TCP/IP controller allowing messages to be sent to all the above using a
wall
mounted small screen and keyboard

TCP/IP irrigation controller, controlling several valves for watering the
garden.

TCP/IP car detector

TCP/IP Caller ID interface

TCP/IP thermostat interface (DS)

TCP/IP <---> IR interface

TCP/IP Door control (Keypad/Ibutton, door release)

TCP/IP Alarm Clock

TCP/IP audio switcher

TCP/IP power monitor

TCP/IP light level detector

Hardware based reporter/emailer for all of the above

PC based web server to control all the above


All of the above to be designed to be relatively low cost and modular


John

------------------------------





-----Original Message-----
From: James Hoye [mailto:james.hoye@xxxxxxx]
Sent: Thursday, May 17, 2001 7:36 PM
To: kieran j broadfoot
Subject: [habuy] Collaborative HA Projects {22}


This email was delivered to you by The Free Internet,
a Business Online Group company. http://www.thefreeinternet.net
---------------------------------------------------------------
> I agree with all your points hence why I suggest we put together a
formal
> definition of what we would like the system to do rather than how we
> implement it.  Does anyone else think we might be getting too indepth
with
> the technology rather than what we are trying to achieve?

The first thing has got to be a Requirements Specification.  From this we
can see what needs to be achieved, and we can derive a Functional
Specification.  This should start paving the way for System Design and
System Architecture documents.  Each project can then be scoped within the
context of the system architecture, and spawned separately and
independently.  A harness supporting the architecture/infrastructure could
be developed first to permit component integration testing.

This is about as far as I got:

------------------------------------
HA Infrastructure

·	Use RS485 bus for comms
·	Each device has DS ID chip
·	Use PIC to encode/decode message for particular device
·	Use XML based message/event packets
·	PC (Wintel based at first) to receive, decode and process messages
·	Four types of device
o	Controller
§	Can receive, decode and process messages/events
§	Eg. PC, HA interface and software
o	Responder
§	Can only respond to messages/events
§	Eg. Basic appliance module
o	Source
§	Can generate messages/events
§	Can response to messages/events
§	Eg. Keypad, dimmer, intelligent appliance module
o	Source
§	Can only generate messages/events
§	Eg. Doorbell

---------------------------------

Of course, with a PIC and RS485 it isn't practical to start sending XML
packets since it would take ages to transmit and process.  Of course, with
something like Java and Ethernet it becomes more feasible - esp. if
encoded
as suggested.

James




To:     "andy powell" <andy.powell@xxxxxxx>
cc:
Subject:        [habuy] Collaborative HA Projects {10}

1: No objection to using this list, but can't help feel that we're
"abusing"
ukha by having this discussion primarily here!

2: I think a half-day brainstorming would be a great idea to kick off the
project... I'm happy to make my house available one saturday (about 10
minutes from Gatwick airport/BR), since I don't think that a pub would
work,
and don't see the point in paying for a meeting room :-)

Mark Harrison
Head of Systems, eKingfisher




Date: Thu, 17 May 2001 19:14:01 +0100
From: "Broadfoot, Kieran J" <Kieran.Broadfoot@xxxxxxx>
Subject: RE: [habuy] Was Collaborative HA Projects - now overall
architecture {02}

> Whats IPV4 (showing ignorance)

IPV4 is TCP/IP as most people know it.  Its a particular specification of
IP
and its addressing specification.  I might be wrong but the 4 references
the
4 octets used to define the address.  The worry is of course that we are
running out of name space in IPV4 given the whole world and its brother
are
now on the internet.  As such IPV6 is its new cousin which supports a much
much larger name space.  To run side by side with IPV4 you need some funky
address translation tools and is therefore limiting its use across the
globe.

> Definetly, provided the cost does stand in the way, for example my
light
> controler has a problem if every switch has to be 10BaseT even the
cheapest
> Rabbit is 34USD, TINI 55USD and that will not fit in a 1 gang box.

Hence my preference for zoned buses controlled my multiple controllers.

> I am lost here (ignorance) can you point me to some reading matter, I
am
> just a dim low level programmer

If I understand Mark correctly he is suggesting that we define the
functionality of all types of devices within an XML definition.  Depending
on the complexity of the device it will only implement certain functions
of
the definition (or protocol as a better term).  In other words the basic
light switch with very limited capabilities will not have the
functionality
to talk to the outside world (i.e the users client web browser) etc but
would have have the functionality to talk "ukha bus language" to
your
controllers.  The same protocol for everything but each device talks the
subset its capable of talking to.

I dont know if that helps at all really ;-)

kieran

------------------------------

Date: Thu, 17 May 2001 19:18:28 +0100
From: "Broadfoot, Kieran J" <Kieran.Broadfoot@xxxxxxx>
Subject: RE: [habuy] Collaborative HA Projects {20}

I agree with all your points hence why I suggest we put together a formal
definition of what we would like the system to do rather than how we
implement it.  Does anyone else think we might be getting too indepth with
the technology rather than what we are trying to achieve?

As to your point about OO.  I disagree.  The great feature of java is that
we can run it across multiple platforms.  Maybe the controller could run
on
a PC or on a TINI depending on how the user wanted to spec their HA
design.
Given all the extra functionality you get as free plus the ability to run
different bits of code on different architectures it might make the whole
project run a little more smoothly.  Maybe even less compatibility issues
which might arise in a distributed project such as this.

Thanks
kieran

p/s maybe we should also consider defining OO in this context as packages
of
code designed to provide a certain function which can be used across
multiple devices.




Date: Thu, 17 May 2001 17:08:35 +0100
From: Mark Harrison <mark.harrison@xxxxxxx>
Subject: Was Collaborative HA Projects - now overall architecture

OK, how about this for a strawman for overall architecture. I don't
_think_
I'm saying anything that hasn't already been implied:


- Core IPC and IDC (Inter-Device Communication) will be fundamentally
based
on message passing between devices with IPV4 addresses.

- IP transports may vary wildly, but where possible should use existing
standards where these can be implemented without material licencing
charge.
--- ie, you don't implement a multi-wire, high bandwidth proprietary
transport - you use 10BaseT

- For interoperability, an XML DTD will be defined, with an agreed
semantic.
All device ranges should either support XML message passing directly, or
implement a "bridge" to handle byte coding and IP
routing/bridging. Where
they handle IP bridging/routing, this _only_ need handle the methods of
the
XML DTD that devices using that transport would support.
--- ie, you don't have to implement a full physical stack which could be
used as a WAN route unless you want to ;-)


This suggests that there are several different, but inter-related, work
streams:

- Definition of an XML DTD, to cover the full range of existing HA
functionality requirements.

- Agreement on recommended low-bandwidth transports for initial product
implementation.

- Once both of these have some flesh around them, thought about byte-
coding
of the information.






Mark Harrison
Head of Systems, eKingfisher

------------------------------



Date: Fri, 18 May 2001 09:25:02 +0100
From: Mark Harrison <mark.harrison@xxxxxxx>
Subject: RE: [habuy] Was Collaborative HA Projects - now overall
architect ure {03}

Kieran,

Thanks for that.

To clarify where I was coming from:

- IPV4 rather than IPV6 because of cost, common usage, and the fact that
there is "always" going to be backwards
compatability even if IPV6 does take off. With my corporate hat on, I
can't
see IPV6 really taking off, because NAT has gone a long way to relieve the
pressure on the IPV4 address space.

- You DON'T have to implement 10BaseT. However, if you do, you should run
Ethernet over it rather than something else proprietary!

- Yup - hit my thinking on XML spot on!

Regards,


Mark Harrison
Head of Systems, eKingfisher

**************************************************************************
**
Kingfisher plc
Registered Office: North West House, 119 Marylebone Road, London NW1 5PX
Registered in England, Number 1664812

This e-mail is only intended for the person(s) to whom it is addressed and
may contain confidential information.  Unless stated to the contrary, any
opinions or comments are personal to the writer and do not represent the
official view of the company.  If you have received this e-mail in error,
please notify us immediately by reply e-mail and then delete this message
from your system.  Please do not copy it or use it for any purposes, or
disclose its contents to any other person.  Thank you for your co-
operation.
**************************************************************************
**



-----Original Message-----
From: Broadfoot, Kieran J [mailto:Kieran.Broadfoot@xxxxxxx]
Sent: 17 May 2001 19:14
To: mark harrison
Subject: [habuy] Was Collaborative HA Projects - now overall
architecture {03}


> Whats IPV4 (showing ignorance)

IPV4 is TCP/IP as most people know it.  Its a particular specification of
IP
and its addressing specification.  I might be wrong but the 4 references
the
4 octets used to define the address.  The worry is of course that we are
running out of name space in IPV4 given the whole world and its brother
are
now on the internet.  As such IPV6 is its new cousin which supports a much
much larger name space.  To run side by side with IPV4 you need some funky
address translation tools and is therefore limiting its use across the
globe.

> Definetly, provided the cost does stand in the way, for example my
light
> controler has a problem if every switch has to be 10BaseT even the
cheapest
> Rabbit is 34USD, TINI 55USD and that will not fit in a 1 gang box.

Hence my preference for zoned buses controlled my multiple controllers.

> I am lost here (ignorance) can you point me to some reading matter, I
am
> just a dim low level programmer

If I understand Mark correctly he is suggesting that we define the
functionality of all types of devices within an XML definition.  Depending
on the complexity of the device it will only implement certain functions
of
the definition (or protocol as a better term).  In other words the basic
light switch with very limited capabilities will not have the
functionality
to talk to the outside world (i.e the users client web browser) etc but
would have have the functionality to talk "ukha bus language" to
your
controllers.  The same protocol for everything but each device talks the
subset its capable of talking to.

I dont know if that helps at all really ;-)

kieran




------------------------------

Date: Fri, 18 May 2001 18:02:34 +0200
From: Andy.Powell@xxxxxxx
Subject: Re: [habuy] Collaborative HA Projects {20}

Has anyone taken a look at the PLM-24 - apparently it can co-exist with
X10 (but the speed is 2400 baud) and can both send AND receive.???

( http://www.hth.com/plm-24/ )

There are all sorts of gateways available  (IR, TCP/IP) which would
essentially cut down development time and if the S.N.A.P. protocol was
used then up to 16.7 million nodes can be on the system....

there are some examples for it's use on the site too.... The one that got
my attention was to do with temperature measurement. Essentially you plug
in you PLM-24 ( & DS1620) and the PC can 'ask' for the current temp....

I guess (from the non-response to my other stamp stuff) that you lot
would
like to go a more propriatory (sp?) route... is that correct?? I was just
thinking of TTL ...

Just think about X10 speed * 40 plus all units can send and
receive...???!!!

Just my 0.02p again...

A.






> -----Original Message-----
> From: BadMsgQ@xxxxxxx [mailto:BadMsgQ@xxxxxxx]On Behalf Of A
> Purchaser
> Sent: 18 May 2001 19:51
> To: mick furlong
> Subject: [habuy] Was Collaborative HA Projects - now overall architect
> ure {08}
>
>
> ...and another...
>
>  http://www.siteplayer.com
>
> A.
>
> p.s please let me know if this is p*ssing you all off...
>
>
> *********** REPLY SEPARATOR  ***********
>
> On 18/05/01 at 11:03 Andy.Powell@xxxxxxx wrote:
>
> >I'm reall sorry,
> >
> > http://www.embeddedethernet.com
> >
> >I can't spell! (2 dd's not 1)
> >
> >A.
> >
> >
> >
> >
> >
> >"Dr John Tankard" <john@xxxxxxx>
> >Sent by: BadMsgQ@xxxxxxx
> >18/05/2001 11:01
> >Please respond to habuy
> >
> >
> >        To:     "Andy Powell"
<andy.powell@xxxxxxx>
> >        cc:
> >        Subject:        [habuy] Was Collaborative HA Projects -
now
> >overall architect ure {06}
> >
> >
> >> I think you might like to take a look at:
> >>
> >> http://www.embededethernet.com
> >>
> >>
> >> There are pic version notes AND basic stamp version notes
> >>
> >> A.
> >>
> >I cannot see that is it correct or is it just BT.
> >
> >John
>
>--habuy--------------------------------------------------------------
> >If you want to get off this list :-
> >send a PLAIN TEXT email to mdaemon@xxxxxxx
> >with the first line of the body:-
> >UNSUBSCRIBE habuy [address]
> >
> >--POWERED BY
MDAEMON!------------------------------------------------
> >





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.