The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024

Latest message you have seen: Protocol name (again)


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Project] RFC re Bulkhead (98k attachment)


  • To: "'ukha_d@xxxxxxx'" <ukha_d@xxxxxxx>
  • Subject: RE: [Project] RFC re Bulkhead (98k attachment)
  • From: "Broadfoot, Kieran J" <Kieran.Broadfoot@xxxxxxx>
  • Date: Mon, 4 Jun 2001 09:21:24 +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

Kenneth,

I agree with your comments below I have too many remotes as well and would
like to ensure we have an easy to use system here.  I think we need to draw
a distinction though between

i. intra device communication

ii. user management communication

Intra device communication is the stuff I was refering to when I was
talking
about http and naturally I can see how we could use this to manage the lcd
panel.

User management communication has not yet been finalised or for that matter
discussed.  Naturally we need some form of GUI to manage setup and
interdependencies and of course we need a macro lanaguage to define events
based on alarms from devices etc.  Finally how do we manage all this stuff.
Thats open to the user... how about these for possibilities:

i. IR: The ukha IR receiver communicates ir codes it receives to the
devices
it has relationships with.

ii. Epod/IPaq - using the inbuilt web server in the bulkhead software

iii. lcd panel - the panel forwards requests both to the console and to
devices by defined relationships

iv. The console itself, i.e sitting in front of the PC.

v. Wap via a dialin modem.

vi. Shouting at a mic in the ceiling

I would hope to see a system where all of the abover could be handled in
one
place using one piece of software.  I might have missed your concerns in
your email so I hope I were are talking about the same things here!

Just my tuppence.

k.


-----Original Message-----
From: Kenneth Watt [mailto:kennethwatt@xxxxxxx]
Sent: Monday, June 04, 2001 8:54 AM
To: ukha_d@xxxxxxx
Subject: RE: [ukha_d] [Project] RFC re Bulkhead (98k attachment)


Guys,

I've watched this project with interest and it is fascinating reading, I
myself have never been an electronics buff when it comes down to building
things, I just like using them really.

But here's my thing, its all very well designing equipment that talks via
HTTP, one-wire etc. and I applaud you guys on your efforts thus far but I
have an issue with I-Paqs and EPODS in that, yes they can talk to a PC or
they can talk to a home auto set-up via a PC/wireless network with no
problem, but as a consumer I still need a Pronto or remote to turn on the
TV
or the amp or whatever really!

Keith mentions the Creston remotes as the granddaddy of all remotes and it
probably is, but it's beyond most peoples means, or wills to buy. But, it
does have full IR capability therefore controlling devices that fall
outside
the remit of any project are controllable using that box. What I want as a
consumer is one-box solutions for control methods, not a steadily
increasing
amount of control systems or remotes glorified or otherwise to do,
essentially one job. In other words, why do I need a Pronto, an EPOD and
several remotes for RF stuff too?

I see where you are going with this, I think, in that the control via an
I-Paq/EPOD or whatever is an additional feature of the system you are
designing but when EPOD fever gripped the HA scene I resisted, simply
because it was not worth my while to buy an EPOD to control X10 when I
already had a Pronto that controlled it all as well as a EPOD really. Yes,
the EPOD would be nice and it allows true real time interaction etc etc but
you still come back to the questions, do I really need it and why?

All I'm trying to point out is that these devices have a limited
functionality outside of talking to devices that can be seen by a PC, we
tried playing about with an Aero a while ago to get it to send standard IR
codes and that was a bust, anyway the range was next to useless and the
batteries only last a few hours once the device is off its cradle.

Just some thoughts, I could be barking up the wrong tree here but it's just
my tuppence worth and I hope I have not offended anyone with my ignorance
;o)

K.

-----Original Message-----
From: 	Keith Doxey [mailto:ukha@xxxxxxx]
Sent:	03 June 2001 20:56
To:	ukha_d@xxxxxxx
Subject:	RE: [ukha_d] [Project] RFC re Bulkhead (98k attachment)

Hi Keiran,

It looks good.

One thing worth considering though, you mentioned HTTP as an implementation
method. do you mean running a webserver on the device? If so, it might be
worth considering an option to run with pages optimised for 240x320
resolution.

This would allow a PDA such as iPaq, Cassiopia etc to directly access the
device using a wireless lan. This would mean that you could then have
something much cooler than a Pronto. A colour tochscreen remote contrl that
had full feedback from the devices it was controlling and you can do all
your email etc as well.

It would also give the kind of features offered by Crestron Colortouch
panels which cost a fortune. In fact, it would be better than a Crestron
because that has bitmaps stored in the panels and is limited in what it can
store/display. Pocket Internet Explorer can show you anything. Doorbell
rings, doorcam.jpg can be displayed on the iPaq. :-)

When accessing from an Epod, TV or PC the pages could then be optimised for
the optimal resolution of the viewing device.


Keith


-----Original Message-----
From: Broadfoot, Kieran J [mailto:Kieran.Broadfoot@xxxxxxx]
Sent: 03 June 2001 17:06
To: 'ukha_d@xxxxxxx'
Subject: [ukha_d] [Project] RFC re Bulkhead (98k attachment)



Everyone,

I know John and Keith have been very noisy with regards the minutae of the
UKHA project and to be honest they lost me pretty quickly.  However I know
some of you have shown an interest in helping with the software component.
So I think its time to see who wants to help out.  Having spoken
extensively
with John on this are current thinking is that quite possibly the protocol
between console and rabbit does not need to be complex.  One of the
features
of the rabbit is that its very easy to implement http and cgi and all of a
sudden it makes the complexity of the protocol much easier to handle.

Anyway we need to think about the console will know how to deal with each
device.  Should the user install some object code on the management code
that comes with the device or should we be a little more clever and allow
the system to self determine this?  I am quite tempted to suggest that we
payload into the rabbit a serialized java class detailing how to use the
device.  Its a simple task for a java app to read this object and handle it
correctly.  Anyone have any further ideas?

I made a bit of a start playing around with possible gui ideas this morning
and attached is a prototype.  You can ask for the code but I promise it
cant
do anything at all ;-)  As you can probably see its written n Java which I
like for its speed of development and multiple platform capabilities.  You
could even consider running a cut down non GUI version on a TINI or similar
acting as an embedded controller of the system.

Anyway if you have any thoughts/ideas/flames etc direct them to me ;-)

Enjoy the rest of the weekend.

Kieran




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/


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com




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

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.