[Date Prev][Date
Next][Thread Prev][Thread Next][Date
Index][Thread Index]
RE: Re: [Project] Lights was Foundations are in!
- To: <ukha_d@xxxxxxx>
- Subject: RE: Re: [Project] Lights was Foundations are
in!
- From: "Keith Doxey" <ukha@xxxxxxx>
- Date: Sat, 2 Jun 2001 19:53:02 +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
Doing the lighting controller is fine by me.
I have been thinking about this whole TCP/IP Ethernet thing a lot for the
last few days and have come up with the following thoughts.
1. Does EVERY lightswitch etc need to be TCP/IP enabled. As you have
already
mentioned, the Rabbit modules are quite cheap for what they are, but they
still arent cheap. A light switch has very limited requirements even for a
multi-switch plate. A few buttons, a few LED's and possible an LCD display.
This is easily accomplished with a low cost PIC. A Lightswitch, even if it
controls other systems is still dependant upon other modules with more
processing power and functionality.
2. The press has done several articles where "All the appliances
communicate
with each other" but under what circumstances would a Freezer need to
talk
to the Hot Water Tank ?
Hot Water Tank to boiler, Room sensor to heating controller - yes.
3. If every device is to be interconnected by its own Ethernet connections,
where will you put the rack full of Ethernet Hubs ?
4. When John started development of his lighting system we had some quite
lengthy discussions on features/resilliance etc. I dont know if he followed
that route or modified it slightly but my ideal system would be....
Room Controller - aka Dimmer Pack which would house the dimming circuits
for
the lights in a room plus relays for curtains etc. Keypads and sensors in
the room would communicate with the room controller via RS485 or similar
where all the keypads/sensors could be daisy chained on one CAT5 back to
the
controller.
Room Controller does not specifically mean 1 per room. It is a
generic/working name for a unit with several channels of lighting control,
a
few relays etc. Some rooms such as a Home Theatre may need a controller of
their own whereas several bedrooms may share one controller.
The Room Controller would form a functional self contained sub system
capable of operating even if its comms with the rest of the house were lost
although it may have some of its functionality limited. This should be the
case with any automation system. You may currently use Homevison or Pronto
for controlling your AV Kit but in the event of that failing you can use
the
original remotes....or heaven forbid....get up and walk to the TV and press
a button on the set.
That describes the limited functionality quite well. With HV/Pronto, one
button fires off a Macro accomplising several events in one go. With the
Original Remotes you have to press several buttons, Geting up off your A***
you may only be able to change channel or adjust the volume of the TV but
you do still have some control.
Originally I suggested that these sub systems would be connected via a
second RS485 bus back to the HA Controller. This is where I now believe
TCP/IP should come into the equation. That would give direct access to the
room controller via TCP/IP and would be totally independant of other
controllers/equipment/computers in the house. The status of all switches
and
sensors could still be visible because the room controller would be
communicating with them via its local bus.
If a switch on a particular Keypad was needed to control something on
another sub system no problem. The Room Controller in Room A detects the
keypress and knows that it is a message for
Comfort/Homevision/AVcentre/whatever and sends it via TCP/IP to the
appropriate sub system.
Whilst the ideal of every single device being TCP/IP enabled may seem nice,
I dont believe it is realistic until you can buy a low cost Microcontroller
that can provide a single chip solution. To do this the chip must connect
directly to a multidrop RS485 bus (negating the need for multiple hubs),
handle all the TCP/IP functionality through dedicated hardware (like the
onboard UARTS in some PIC's handle Serial comms) and have sufficient I/O
pins to interface to all the switches/displays. Some analogue input might
also be nice but most analogue commodities that need measuring such as
volume/light/heat/humidity seem to be getting dedicated 1 wire devices
developed giving nice digital values to work with. When such a
microcontroller is available for a quid then having every device TCP/IP
enabled will be a reality.
Keith
> -----Original Message-----
> From: Dr John Tankard [mailto:john@xxxxxxx]
> Sent: 02 June 2001 15:59
> To: UKHA
> Subject: [ukha_d] Re: [Project] Lights was Foundations are in!
>
>
> --- In ukha_d@y..., "Graham Howe" <graham@s...> wrote:
> > Lights are controlled via x10 unless you want great expense.
>
> Maybe not.
>
> After a lot of discusion, we are thinking of switching from starting
with
> the LCD/KBD to the lighting controler.
>
> Reasons:
>
> 1) On its own the LCD/KBD can do little that will help anyone
>
> 2)It requires us to think about all the other devices(not yet
produced)
> and how they interact with it, which is proving difficult.
>
> 3)We have a prototype 4 channel lighting system already, which we can
use
> to make a start.
>
> 4)Because of the limitations of X10, it is likley to be of interest to
a
> wide user base.
>
> 5) The command structure will be easy to define.
>
> What will this device do
>
> Control 4 lighting channels fully dimable
> programed ramp rates
> programed presets
> Perhaps a further 4 channels (non dimable)
> Level -> power curves
> Zero volt at when off
> Soft start
>
> Any strong views against this switch ?
>
> We still need to resolve how the controler might get local control
from
> switches. Clearly when we do build the kbd/lcd device that will
control
> it via tcp/ip but that will be a bit expensive for every room.
> I have two posibilities at the moment, 1 wire and 422. the latter
would
> be a bit more expensive but would allow more features, perhaps even a
> display. more ideas needed please.
>
> I know some may not be happy with the change in project, but we need
to
> make a start on something.
>
> Keith is woking on the power side and he will get one of the spare
Rabbit
> cores from my order on Monday (Just posted it Keith). Kieren is
working
> on a protocol/command list. I am working on some code do do the low
level
> stuff, it needs porting from a 16c65. Hardware help to Keith, protocol
to
> Kieran, and bit bashing to me.
>
> I am away for a few days, and hope to read all the Rabbit manuals and
> test some code.
>
> John
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Home |
Main Index |
Thread Index
|