Re: Kieran's comments was Last Night in London?

["Dr John Tankard" <john@xxxxxxx>]

> ideas:
>
> i. second ukha product - 1 and 2 gang wall switches controlled by
xap.
> Standard wall sockets providing the same functionality as x10 just
over
> tcp/ip and with state

We had talked about this one before, its a idea I like but the
general feeling was, its overkill and it would be to expensive.

I like the wall switch which would do more ie lcd/kbd module.

There is another problem with the wall switch. The lighting project
is going to handle two/three forms of local control:-
1) standard low voltage switch closures which could come from either
CAT5 or 1.5mm t&e home run, this would allow the users with DIN
modules to conver over to the new system and allow users to switch
back to almoust normal wiring if the move home (Not done but very
easy)
2) multi drop serial comms over cat5 (Done using SNAP at the moment)
3) 1 wire interface to the PIC (Not sure about this no code written)
Now in your example although you would not have TCP/IP at the wall
switch, you would have it at the lighting controler, so there is no
problem in the lighting controler passing the TCP/IP message out from
the wall switches.

>
> ii. Maybe the project doesnt need a full software control system
but rather
> a software API written in various languages.  Maybe the HA masses
would
> prefer a COM object they can embed into their VB?  Or the perl
geeks can
> have a perl module, or those java heads can get their hands on a
jar file.
> Whatever way we produce it the important thing is that it keeps
some of the
> complex stuff hidden with a nice little API for people.  They could
wrap
> objects and other groovy data objects round it if they want to build
> relationships between devices but alternatively they could
something as
> simple as:
>
> import net.sf.ukha.xap.*;
>
> Xap x = new Xap();
>
> public void main() {
>    Array a = new Array();
>    x.scanNet(a);
>    x.turnOnDevice(a[4]);
> }
>
> // you get the idea ....
>

I think we must also allow interface to other hardware controlers,
HV, Comfort. The reason I say this is you have to get people to trust
a PC, not easy (had to reset my W2K yesterday) I have never had a
problem with HV. Actualy I have just reset a Novell 5 server today
(uptime 602 days). The point I am making is its a bit of a leap of
faith to trust your house to a PC. I like the idea of the level of
control we can accheive with it but the house must not crash if the
PC's hard disk packs up. I know we could have two PC's but I dont
think we would sell the idea.

> iii. We also talked about sponsorship for the ukha project from
letsautomate
> or laser etc to help cover up front costs for CE compliance etc.
In return
> they get guaranteed stock and the honour of being the only
stockists for x
> number of months or x amount of stock etc.
>

It sounds nice, but its a risk for them, I think we need to make
something first so they can see it might happen first.


> I think there are two major issues with nearly all HA systems
currently:
>
> a. There is virtually no easy way to integrate the components in a
> controlled fashion (thats what makes the expensive systems a good
deal if
> you could afford them)

I fully agree with this, but what is the answer, we could make a
complete system, but there is a lot of work in this.

We could look at the main systems and try and intergrate them into
our devices.

>
> b. Most people implement HA by controlling devices and then adding
sensing
> capabilities
>
> Im in the very early stages of implementing my own home brew system
but Ive
> been thinking about it for quite some time and the idea of an
intelligent
> house must indicate you start with setting up the house to be aware
of its
> surroundings.  I am basing this stuff on 1-wire/ibuttons and TINI
as my
> chosen platform because it all supports java ;-)
>
> Each room has a number of sensor modules.  A module would be made
up of a
> small breaboard containing a 64kbit iButton plus n+1 1-wire sensors
(light,
> humidity, temp etc).  Using the xml 1-wire project (on sourceforge)
you can
> define relationships between 1-wire devices.  The idea is that each
sensor
> has its own local data storage on the nvram.  This is then farmed
off
> through an object model into a database for historical use.  The
great thing
> is that even if you lose the database you can still boot strap the
house
> using the few hours worth of data on the nvram buttons.
>
> Historical mapping of data provides trend analysis of the house
status which
> can then be used with a bit of logic to define outcomes when
situations
> occur.  I wanted to be able to dim lights in a room to different
levels
> depending on light levels in different parts of the room so you get
a
> uniform light level across the room.

All sounds good, it reminds me of LonWorks which I wanted to use but
the development stuff was way over budget.

John

John






____________________________________
Automated Home UK
http://www.automatedhome.co.uk
____________________________________

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