Peter Lawton
Neil Cherry wrote:
<snip>
>
> So here is the challenge skip the marketing hype and don't bother to
> tell us which system is better (X10 ain't it). Instead point us to
> your products, tell us where to purchase them. And if you think that a
> development system that runs at $1K and up is it then please say
> so.
<snip>
> --
> Linux Home Automation Neil Cherry nch...@home.net
> http://members.home.net/ncherry (Text only)
> http://meltingpot.fortunecity.com/lightsey/52 (Graphics)
> http://linuxha.sourceforge.net/ (SourceForge)
--
--------------------------------------
My email address is formatted to prevent spam bots finding anything useful.
When sending mail directly to me, remove the period you see, then fix the "dot".
So here is the challenge skip the marketing hype and don't bother to
tell us which system is better (X10 ain't it). Instead point us to
your products, tell us where to purchase them. And if you think that a
development system that runs at $1K and up is it then please say
so. We probably won't like it, especially when a few are more than
willing to create Open Source projects to use your products. We the
hobbiest would appreciate it if you did not ignore us. I know that we
won't bring in large sales but we certainly reflect the opinion
makers, the article writers, and the early adoptees in HA. I'm not
overly impressed that LonWorks is used by the major railroads. I don't
plain on spending that kind of money to build a railroad in my home.
Sorry that I'm picking on LonWorks, I just have a bit more knowledge
of their technology. I am really lacking knowledge in either
technology and I won't bother to learn more until I can get my hands
on the equipment.
I'm seriously beginning to think we the hobbiest should start to look
at alternatives such as HTH SNAP and PLC's at least the speed is
greater than X10's and the devices are cheaper than CeBUS and
LonWorks. Remember that the best doesn't win in this market. This, if
nothing else, we have learned well from Microsoft.
>Thank you, Neil. I asked for the same answers in my reply to the
>LonWorks note you mentioned, and was ignored. I don't understand why
>Echelon would "promote" LonWorks for home automation, if they're not
>interested in actually _selling_ the products. And if they're
>interested in selling, pricing should be available one way or
>another. I just don't get it.
And neither will they unless they can provide us with products to
use. The average person is _NOT_ going to purchase an Installed HA
service from qualified resellers. They're going to buy things bits and
pieces. If all these manufacturers are going after in the installers
market then telling _Us_ about their product is probably useless in
the short run (but I'm willing to bet a few here may be 'big business'
in HA in the future).
I'm just tired of getting ignored, I'll venture a guess that these
companies don't see much value in Open Source projects. The cost to
them would be low, we buy the boards, they provide the specs and the
users would then purchase the systems (yes I know, that's simplified).
I work for a company called 'SeaChange Controls' we manufacture HVAC
products 'based' on Echelon technology. We have a unique "plug and play"
system, more details are available from our web site.
see our range at www.seachange-home.com for the domestic market
or www.seachange-controls.com for the commercial sector.
Darren Simons
Senior Development Engineer
SeaChange Controls
"Neil Cherry" <n...@CC47532-A.ewndsr1.nj.home.com> wrote in message
news:slrn8tl53...@CC47532-A.ewndsr1.nj.home.com...
> In preparing for my presentation on HA and Linux I discovered that we
> lack a great deal of information on CeBUS and LonWorks. It seems that
> CeBUS is in better shape in that at least you can get the prices of
> devices. Where as LonWork I could only find their dev kits (start at
> ~$1000 and up). This doesn't include the protocol specs, but I was
> looking for interfaces. We recently had a post from an employee of
> Echelon (LonWorks) and he extolled the virtues to us. But he failed to
> point us to any parts we can purchase (I'm not talking chips here)....etc
>
> So here is the challenge skip the marketing hype and don't bother to
> tell us which system is better (X10 ain't it> --
> I did not intend this to be a advertisement, more to show that
> products based on Echelon do exist.
In this particular instance, advertisements are warranted, even
encouraged.
For me, HVAC is a known quantity and has a nice wealth of connectivity
options. The same holds for security systems.
Individual home entertainment units have some degree of control but
very little integration. Solutions exist to translate several top
manufacturers' proprietary interlinks.
Outside of X-10, lighting/power control is fairly opaque and
proprietary. Both the hobbyist and consumer market would be well served
with a replacement for X-10. Don't point to Phast, they pander to a
completely different market.
--
Comments are On behalf of myself only.
Work: j (dot) klar (At) xpedite (dot) comNOUCE
Home: j (nodot) klar (aT) projectplasma (dOt) comNOUCE
Sent via Deja.com http://www.deja.com/
Before you buy.
Well you just got yourself off the hook! :-) I'm sorry about the rant
but we, the CHA community, are tired of being ignored. We want to use
the technology but can't even find it for sale. Hence the challenge.
About half way through your post I started to think part of it was a
sales pitch forLonWorks. The reason, lot of stuff that sounds great
but nothing I can get my hands on. Most of the techies I work with are
quickly turned off by this. Which is why you never send just a sales
person to a labs location. The sales person tends to get abused.
BTW, 2 things: 1st) I'm glad you told us about what you sell I've
poked around you pages and I am interested (but right now I have all
'lectric heating). 2nd) the pool heater page seems to be broken.
I take it your systems are really more geared towards hotels,
apartment building etc as opposed to the small scale setups
in the home, yes?
Hope you like our product range!
This was not meant as a sales pitch for LonWorks. Our products use Echelon
Neuron chips and transceivers and can be supplied in one of two flavours:.
1. Open system (requiring Echelon binding tool and a plenty of time -
"LonWorks")
2. SeaChange push button registration (plug and play) This forms the bulk of
our sales.
http://www.seachange-controls.com/cd/seachange/Articles/Press_releases/opens
ys_press.htm
As for the target market our system is fully scalable from a single
room/apartment to hotel complex, with support for wide area networking and
internet access.
Darren Simons
Senior Development Engineer
SeaChange Controls
"Neil Cherry" <n...@CC47532-A.ewndsr1.nj.home.com> wrote in message
news:slrn8tmhm...@CC47532-A.ewndsr1.nj.home.com...
Oh no, not yet, you've got to get them to fix the web page. :-)
>Hope you like our product range!
Don't take this the wrong way, I didn't find anything that I'm
interested in. That's because what I'm after right now is not what
your selling. But I've bookmarked the page for future reference. The
pool will eventually need a heater (and these ceramic disk thingies
that shouldn't be put under the concrete.... ;-)..
Which web page or did you mean that link
http://www.seachange-controls.com/cd/seachange/Articles/Press_releases/opens
ys_press.htm
(i bet the server truncates it again)
do we get a mention at your presentations on HA!
Thanks for all the feedback.
Darren Simons
SeaChange Controls Ltd
Interesting article ...
The broken link was on the Home section (http://www.seachange-home.com/):
http://www.seachange-controls.com/cd/seachange/modules/
Pool%20controllers/features/pool_controller_features.htm
Sorry had to break it into two parts.
>do we get a mention at your presentations on HA!
The presentation was on October 2 so you didn't directly make
it. Although I did mention that I needed to find out more about the
protocols (CeBus, LonWorks and now HTH SNAP/PLC).
>Thanks for all the feedback.
Yikes, slow that web site down! It's going nuts like hyperactive kids!
Initially I didn't go and look at the commercial part (the hyperactive
kids), it looks interesting. More interesting than the Home
section. I'll try to poke around some more but I'm running too many
process and will have to push out the low priority ones.
Right now, one of my higher priorities is to get Echelon and CeBus to
take notice of this group so we can get access to their technologies.
Since only HTH has responded (I just purchased a PLC and a demo board
from one of their Canadian distributors) I'm going to write letters
and give them the benefit of the doubt that they don't know of my
requests.
Does anyone know of any Lonworks AV bits? All I can find is commercial power
management and HVAC stuff. There are rumours of LGE appliances with Lonworks
interfaces - are these availiable?
HTH (http://www.hth.com/) is willing to provide us the source to their
libraries (at least the Linux ones). I've been able to order a PLC and
a demo board from a distributor in Canada and should get it in a few
days (unless the sent it via their postal service, then I receive it
in a month )-: . The nice thing about the HTH PLC is that it "can
co-exist with X-10 equipment and won't false trigger X10". The draw
back is that there are no ready made outlets or modules.
Does any one else have any suggestions for getting the manufacturers
to take serious notices of us?
<snip>
>Does any one else have any suggestions for getting the manufacturers
>to take serious notices of us?
My guess is that the hobbyist market is too small.
I think there is a reference implementation of LonTalk on the Echelon
website, http://www.echelon.com/Products/Core/protocol/Default.htm and
it's also an EIA standard 709.1, I think. Unfortunately, these aren't
complete solutions. The reference implementation would need some
extra hardware not usually found on your typical PC serial port and
neither implement the LonMark profiles at the top layers.
But for Echelon products, check out their promotional organization at
http://www.lonmark.org which coordinates all the companies using
Echelon technology.
You also might look into Universal Plug 'n' Play, UPNP. Intel
http://developer.intel.com/ial/upnp/ has some open source on
sourceforge. There's a upnp.org http://www.upnp.org/default.htm and
Microsoft http://www.microsoft.com/HOMENET/ is pushing it, too. UPNP
talks about needing a UDP/IP stack, but since light switches wouldn't
support that, just announced something called SCP
http://www.microsoft.com/HOMENET/scp/ . I don't know what it stands
for, I just got the CD fm MS. It's supposed to be based on CEBus,
lightweight enough to run on a lamp, and easily integrated with
TCP/IP. If it could only make dinner...
I hear Windows ME supports UPNP, but like all the other home
automation protocols, I haven't seen any stereos, vcrs, tvs, washing
machines, or toasters with a control protocol connector.
Best,
B.O. Oct. 6, 2000
--
Bob Old
Lindenhurst, IL USA
The hobbiest market is small but the Open Source market is large. ;-)
Sometime it's all in the way you market yourself.
>I think there is a reference implementation of LonTalk on the Echelon
>website, http://www.echelon.com/Products/Core/protocol/Default.htm and
>it's also an EIA standard 709.1, I think. Unfortunately, these aren't
>complete solutions. The reference implementation would need some
>extra hardware not usually found on your typical PC serial port and
>neither implement the LonMark profiles at the top layers.
>
>But for Echelon products, check out their promotional organization at
>http://www.lonmark.org which coordinates all the companies using
>Echelon technology.
I'm going to poke around all these sites but it's going to take me a
while.
Someone has already warned me that the Lonworks uses expensive
software to create the neural networks and then you get into the
hardware. Sounds like we're not going to see over the counter stuff
from them.
CeBus looks like we may have a chance with as there are a few vendors
selling the parts. Domosys has some demo kits (and what-not) that we
may be able to use.
>You also might look into Universal Plug 'n' Play, UPNP. Intel
>http://developer.intel.com/ial/upnp/ has some open source on
>sourceforge. There's a upnp.org http://www.upnp.org/default.htm and
>Microsoft http://www.microsoft.com/HOMENET/ is pushing it, too. UPNP
>talks about needing a UDP/IP stack, but since light switches wouldn't
>support that, just announced something called SCP
>http://www.microsoft.com/HOMENET/scp/ . I don't know what it stands
>for, I just got the CD fm MS. It's supposed to be based on CEBus,
>lightweight enough to run on a lamp, and easily integrated with
>TCP/IP. If it could only make dinner...
I'm going to have to d/l this. I joined a while back when Intel
announced Linux support. To be honest I don't want to run a project
which has to create new standards and develop hardware and software to
match when such a project is available to us already.
So maybe I'm baking up the wrong tree, but I'll still keep making
noise. The good news is that the vendors are responding and so are the
manufacturers. So we are not totally being ignored.
Thanks
"Neil Cherry" <n...@CC47532-A.ewndsr1.nj.home.com> wrote in message
news:slrn8u179...@CC47532-A.ewndsr1.nj.home.com...
> On Sat, 07 Oct 2000 13:42:05 -0500, Bob Old wrote:
> >On Fri, 06 Oct 2000 01:01:17 GMT, n...@CC47532-A.ewndsr1.nj.home.com
> >(Neil Cherry) wrote:
> >
> ><snip>
> >
> >>Does any one else have any suggestions for getting the manufacturers
> >>to take serious notices of us?
> >
> >My guess is that the hobbyist market is too small.
>
> The hobbiest market is small but the Open Source market is large. ;-)
> Sometime it's all in the way you market yourself.
>
> >I think there is a reference implementation of LonTalk on the Echelon
> >website, http://www.echelon.com/Products/Core/protocol/Default.htm and
> >it's also an EIA standard 709.1, I think. Unfortunately, these aren't
> >complete solutions. The reference implementation would need some
> >extra hardware not usually found on your typical PC serial port and
> >neither implement the LonMark profiles at the top layers.
> >
> >But for Echelon products, check out their promotional organization at
> >http://www.lonmark.org which coordinates all the companies using
> >Echelon technology.
>
> I'm going to poke around all these sites but it's going to take me a
> while.
>
> Someone has already warned me that the Lonworks uses expensive
> software to create the neural networks and then you get into the
> hardware. Sounds like we're not going to see over the counter stuff
> from them.
Yes, this is why we created our "push button registration system!" to avoid
the use of binding tools. The other important thing to remember here is that
having all the parts does not give you the solution, you cannot power a car
with a box full of engine parts. You need to now how the bits fit together,
the binding tool shows you all the connections but you have to make the
links, this is why we moved the problem up a layer and produced modular
controls. The modules know how to control the plant the application
knowledge is embedded in the product the user just joins them together by
pressing buttons.
i know the link will cut off but here goes..
http://www.seachange-controls.com/cd/seachange/introduction/Modular%20contro
ls/modular_controls.htm
It is our aim to remove the need for low level control knowledge. (We all
happily connect new items to our 'hifi', but we don't really care how they
work inside.)
>
> CeBus looks like we may have a chance with as there are a few vendors
> selling the parts. Domosys has some demo kits (and what-not) that we
> may be able to use.
>
> >You also might look into Universal Plug 'n' Play, UPNP. Intel
> >http://developer.intel.com/ial/upnp/ has some open source on
> >sourceforge. There's a upnp.org http://www.upnp.org/default.htm and
> >Microsoft http://www.microsoft.com/HOMENET/ is pushing it, too. UPNP
> >talks about needing a UDP/IP stack, but since light switches wouldn't
> >support that, just announced something called SCP
> >http://www.microsoft.com/HOMENET/scp/ . I don't know what it stands
> >for, I just got the CD fm MS. It's supposed to be based on CEBus,
> >lightweight enough to run on a lamp, and easily integrated with
> >TCP/IP. If it could only make dinner...
>
> I'm going to have to d/l this. I joined a while back when Intel
> announced Linux support. To be honest I don't want to run a project
> which has to create new standards and develop hardware and software to
> match when such a project is available to us already.
>
> So maybe I'm baking up the wrong tree, but I'll still keep making
> noise. The good news is that the vendors are responding and so are the
> manufacturers. So we are not totally being ignored.
>
> Thanks
>
> --
> Linux Home Automation Neil Cherry nch...@home.net
> http://members.home.net/ncherry (Text only)
> http://meltingpot.fortunecity.com/lightsey/52 (Graphics)
> http://linuxha.sourceforge.net/ (SourceForge)
Darren Simons
SeaChange Controls Ltd
> On Fri, 06 Oct 2000 01:01:17 GMT, n...@CC47532-A.ewndsr1.nj.home.com
> (Neil Cherry) wrote:
> <snip>
> >Does any one else have any suggestions for getting the manufacturers
> >to take serious notices of us?
[snip]
> You also might look into Universal Plug 'n' Play, UPNP. Intel
> http://developer.intel.com/ial/upnp/ has some open source on
> sourceforge. There's a upnp.org http://www.upnp.org/default.htm and
> Microsoft http://www.microsoft.com/HOMENET/ is pushing it, too. UPNP
> talks about needing a UDP/IP stack, but since light switches wouldn't
> support that, just announced something called SCP
> http://www.microsoft.com/HOMENET/scp/ . I don't know what it stands
> for, I just got the CD fm MS. It's supposed to be based on CEBus,
> lightweight enough to run on a lamp, and easily integrated with
> TCP/IP. If it could only make dinner...
> I hear Windows ME supports UPNP, but like all the other home
> automation protocols, I haven't seen any stereos, vcrs, tvs, washing
> machines, or toasters with a control protocol connector.
Not to be left out, there is an implementation for linux at
http://sourceforge.net/projects/upnp/
but it's just source, so it should be compilable on most Unixen.
dave
--
David Weis | "Great spirits will always encounter violent
djw...@sjdjweis.com | opposition from mediocre minds" - Einstein
http://www.sjdjweis.com/ |
>i know the link will cut off but here goes..
>
>http://www.seachange-controls.com/cd/seachange/introduction/Modular%20contro
>ls/modular_controls.htm
I'll check this out, I'm not going to leave any stone unturned. And if
I've said in the past that my project won't use something that doesn't
mean that in the future I can't be convinced that it a good thing now.
I have to keep somewhat of an open mind (but oh! the headaches).
>It is our aim to remove the need for low level control knowledge. (We all
>happily connect new items to our 'hifi', but we don't really care how they
>work inside.)
Actually this is not a bad thing sometimes. I'm not really interested
in re-inventing the wheel (unless I'm tinkering/learning). Sometimes I
just want something that takes care of the lower protocols and lets me
worry about merging the upper layer protocols.
Right now I'm reading the docs from Intels UPNP SDK. I'm a little lost
(to say the least) but I'm make headway yet. I'm not too happy with
having another layer on top of the various layers but having
interoperablity is extremely important.
Thanks
Definitely not left out but somewhat forgoten on my part (sorry). I'm
playing with the demo and it's interesting. But I'm confused, I'm
looking for a simple software/hardware example (yea I know the TV demo
is not that complicated).
Later I'll attempt to add at least one upnp interface to my LHA
project. This is important for 2 reasons:
First, UPnP is a standard and with heavy names.
Second, I can see some of the value in UPnP, XML for example.
I just wish I could get my little mind around it.
no problem.
> Later I'll attempt to add at least one upnp interface to my LHA
> project. This is important for 2 reasons:
> First, UPnP is a standard and with heavy names.
> Second, I can see some of the value in UPnP, XML for example.
> I just wish I could get my little mind around it.
i have faith in your little mind :-) i like the idea of a nice substrate
to build on, so you don't have to worry about little stuff like request
and response formatting, getting possible values, etc. grunt work that
someone would have to determine. glad MS and Intel paid for it.
Both SCP and UPnP have a discovery mechanism by which a node/device can find
other node/device. This is by no means a new concept, but very useful in
distributed systems. JINI also, offers the same capability.
The SCP documentation makes mention of a "bridge" which allows SCP and UPnP to
interoperate. Some of the issues regarding interoperability have to do with
address translation (32-bit pair vs IP/URL ), event model (property
subscription vs event sink), bandwidth ( low vs higher for large
transmissions), and resource requirements.
As far as CEBus is concerned, the SCP documentation provides information on
how they interoperate. SCP specifies the application and transport layers (ISO
model). The data link and physical layers may be implemented by a CEBus
device. Of course, this is where the interoperabiity ends. Messages sent over
CEBus DL and physical layers will be ingnored by SCP devices, and vice versa.
One thing that could be prototyped is using the Domosys DomoSIP modules for a
CEBus data link and power line physical layers and SCP on application and
transport. The DomoSIP modules can be ordered online at www.domosys.com, they
run for $39.00 a piece. You would also need the power adapter which supplies
10VDC and couples the node to the AC line.
So, it seems to me that one could have a nice HA system with a master that
runs UPnP and small nodes that use CEBus/SCP. I would rather see a solution
emerge that would use Jini and OSGi, but I'm keeping my eyes open to other
possibilities. Actually, nothing precludes having UPnP, SCP, Jini and OSGi
working together.
Ah, almost forgot, yep, Lonworks looks good, but from what I gather it is a
VERY expensive proposition. It seems like you need something in the order of
$10K to be able to prototype some product that uses the technology. Echelon
shows some modules that might make the prototyping process easy and
inexpensive, but they don't make it easy to get them (i.e. order online in
single qty. for example), so I'm staying away from them. Coactive Networks use
Lonworks in their products for residential gateways, but most of the success
I've seen is in the European market, where I believe Lonworks is more popular
than CEBus. I've also read somewhere that the CEBus standard conflicts with
some European standards regarding signals that travel through the power lines.
Edmund
David Weis wrote:
> On Mon, 9 Oct 2000, Neil Cherry wrote:
> > On Mon, 9 Oct 2000 07:39:14 -0500, David Weis wrote:
> > >On Sat, 7 Oct 2000, Bob Old wrote:
> > >> On Fri, 06 Oct 2000 01:01:17 GMT, n...@CC47532-A.ewndsr1.nj.home.com
> > >> (Neil Cherry) wrote:
> > >> <snip>
> > >> >Does any one else have any suggestions for getting the manufacturers
> > >> >to take serious notices of us?
--
Edmund Troche
Chief Technology Officer
Home iPliance
11005 Burnet Rd. Suite #112-117
Austin, TX 78758
E-Mail: edm...@homeipliance.com
Tel.: (512) 246-6975
FAX: (801) 751-8446
Edmund
Yes but it's one little mind, I need to get some progress on the LHA
project and soon. So I'm going to be coding quickly without all the
fancy protocols. Just a plain telnet/8bit interface (to start off
with). I am a little worried about working with MS but eventually it
comes down to what ever is making progress.
Thanks for the pointers, I'll check these out later.
Just a small question what are you planning to run LHA package on?
All of our products Echelon/Web server/etc based on embedded designs as you
cannot trust a PC for long term operation. Imagine dialing up your home to
find the PC has expired.
Comments...
Just a small question what are you planning to run LHA package on?
>>Neil Cherry wrote
>>
>> Yes but it's one little mind, I need to get some progress on the LHA
>> project and soon. So I'm going to be coding quickly without all the
>> fancy protocols. Just a plain telnet/8bit interface (to start off
>> with). I am a little worried about working with MS but eventually it
>> comes down to what ever is making progress.
>>
>> --
>> Linux Home Automation Neil Cherry nch...@home.net
>
>Just a small question what are you planning to run LHA package on?
>
>All of our products Echelon/Web server/etc based on embedded designs as you
>cannot trust a PC for long term operation. Imagine dialing up your home to
>find the PC has expired.
>
>Comments...
We have Linux running on a 5V TS-2800 embedded PC (with watchdog) from
Technologic Systems.
Besides, most of the problems imputed to a PC are really Windows problems.
I've run a WFW machine that was dedicated to HA for several months w/o a
glitch.
And I have some not-quite bottom-of-the-barrel (consumer level)
machines that have been up and running for over a year.
> Besides, most of the problems imputed to a PC are really Windows
> problems. I've run a WFW machine that was dedicated to HA for
> several months w/o a glitch.
Both of my machines are on 24x7 (in theory improves reliability).
In addition, one pre-boots from flash (OK, a CF card) and decompresses
the rest of the OS (Linux LRP) into a ramdisk. No moving parts! :)
But, I view the PC as a supervisory/management role. Something like
the Ocelot or HCS-II is the right amount of smarts for the right price.
It's going to be a mix of processors, the central computer is going to
be a PC. It will perform normal server functionalities (File sharing,
print sharing, Web sharing, etc.). It will require access to databases
and whatnot. Of course this is the central server and not the
controllers. The controllers themselves may vary from 8 bit devices
to the latest and greatest. The server redundancy will be the greatest
problem but Dave's correct that the main problems have been with the
Windows OS. I still have Linux running on the 386SX even after a the
keyboard controller went dead (don't use manual keyboard/mouse
switchers). Of course there are still further decisions to be made
(only the future can tell). I'll take advantage of the technology as
it's available (and is inexpensive).
My primary "home server" is on a cable modem (@Home didn't care that I run
Unix - but they didn't know how to support it. DUH! I think I can handle
that myself gents; you got four green lights, get outta here :-))
It also runs the automation.
It sits in my utility room (the wirepoint for all my cabling) on top of the
cabinets (fits real nice in there.) Its on all the time, and gives the
house both automation and networking (file service, etc.)
I have "plug and go" network capability everywhere in the home. Real nice;
just plug in and your PC gets an IP address from my DHCP pool, and you
suddenly are online with full cable modem bandwidth available to you.
Fax and laser printer service are available as well, provided you have
the passwords to connect to them (guest get them on request :-))
All this is blocked off from the "outside world"; the only thing visible
from outside is inbound email to my machine (for me) and HTTPS, and the
second only for CGI applications (that all require a password as well.)
There are no public servers anywhere, and all the "accidental" services
that might show up as servers (like Windows file shares!) are firewalled
off at the gateway.
This keeps @Home happy (contractually) and it keeps me happy too - I really
don't like the idea of someone breaking into my PRIVATE machines. :-)
That machine runs FreeBSD. Other than power disturbances (UPS batteries
only last for so long) and intentional shutdowns for routine preventive
maintenance, software upgrades and the like, this machine has not gone down
in more than three years. It has *NEVER* actually crashed. It is, in fact,
a lowly (by today's standards) Pentium Pro 200; an outcast from my previous
company that today is so far behind the curve of "state of the art" that
its not funny. Yet it typically runs with load averages (that's the number
of processes, on average, waiting for resources to run) of about 0.08.
I *DO* have some public services (like the web servers below) available,
but they're not on that machine. I have another machine at a friend's home
that is on a "servers are ok" network connection, and he hosts it for me.
All the "public" stuff that I want others to be able to see sits over there.
I believe in using what you know and like - as long as its not Windows 95
or 98. If you MUST run Windows for this stuff, run NT or Win2k. While
both have crashed on me, neither is anywhere near as unstable as 95/98 is.
--
--
Karl Denninger (ka...@denninger.net) Internet Consultant & Kids Rights Activist
http://www.denninger.net Cost-effective Consulting Solutions
http://childrens-justice.org SIGN THE UPREPA PETITION AT THIS SITE TODAY!
DO NOT VOTE FOR AL GORE! See the above site.
I got so excited in my last post I forgot to post the comment which I
wanted to make. Windows 95 isn't necessarily THAT bad. I know I've used
it in a pinch to run the timers for my house while we took a 2.5 week
vacation, and I was afraid the whole time that if the unit crashed, it
would be painfully obvious to any would-be thieves. Turned out the system
ran quite happily, 24/7 for 3 weeks, doing lighting control via
ActiveHome. But it was still painfully obvious to would-be thieves that
we weren't home, because it had rained a lot and our GRASS was about a
foot tall... oops.
But in my scheme I outlined before (computer as back-end to Leopard), even
a schedule reboot every 3 weeks isn't a big deal.
--
Kevin
While I don't plan on running Windows 95 as a home automation server, I
must admit that I'm looking at it as a dead-easy way to install some basic
services. After my last exchange of emails with you, you're probably
aware that I'm a newbie when it comes to the sysadmin side of things!
I'm considering a hybrid approach. I like what HomeDaemon does, but it's
going to be a bit of a learning curve. I can only pretend to be the
Denninger Residence for so long ;)
I was thinking I'd use the CPUXA smarts for doing things like basic
cause-effect scenarios, i.e. I press this button, that light turns on.
The Leopard is good enough in that regard. So this was my plan:
A) Run basic HA stuff through C-MAX code -- press this, that light turns
on, that IR fires, etc. Very simple, and hopefully very reliable, without
worries of computer glitches. This will probably do 80-90% of everything
I'd dream of having it do anyway -- ADICON will take care of I/O, and
possibly even audio feedback, if Speak-EZ is any good...
B) When I'm ready to expand I can attach a computer as a back-end to the
Leopard. I'd either modify HomeDaemon, or roll my own in a Linux
environment or (horrors!) DOS or Windows. This backend would be
responsible for "value-added" services (*snicker*) like being able to
report the weather, etc. to the Leopard screen, or being able to
dynamically specify timers and alarms and use the keypad. Since this
stuff isn't as critical, there's less of a worry that a computer problem
(or an incompetent programmer *cough*) would cripple the system.
That's my idea, anyway.
--
Kevin
Well, not a bad idea, provided you don't need any of the things that you
can't do that way (like, for instance, scaled analog inputs :-))
j. ak
"Darren_Simons" <Dar...@lowbox.freeserve.co.uk> wrote in message news:8s16r6$gpl$1...@news8.svr.pol.co.uk...
> >Neil Cherry wrote
> >
> > Yes but it's one little mind, I need to get some progress on the LHA
> > project and soon. So I'm going to be coding quickly without all the
> > fancy protocols. Just a plain telnet/8bit interface (to start off
> > with). I am a little worried about working with MS but eventually it
> > comes down to what ever is making progress.
> >
> > --
> > Linux Home Automation Neil Cherry nch...@home.net
>
> Just a small question what are you planning to run LHA package on?
>
> All of our products Echelon/Web server/etc based on embedded designs as you
> cannot trust a PC for long term operation. Imagine dialing up your home to
> find the PC has expired.
>
> Comments...
>
Let me restart, in a different way, what the LHA project will run on.
First my entire vision is really a bunch of projects, but we need to
start at the beginning. :-) That's why we're building what was called
agents but I may now have to rename as gateways (so Dan Lanciani gets
credit for the first residential gateway ? :-). And instead of
describing what those projects are let me describe my current setup
and a little of my background (oh no, not again!).
I work, now, as a network test engineer (Cisco, Nortel, ATM, Frame,
10BaseT, 100BaseT, Gigabit, etc). I was previously a Systems Engineer
(with some Systems Architect work on small, less than 500 router
networks). I've been in computers since 1978 and played with
everything from 1940 centronics type interfaces (+/- 25Vdc) and current
loop to todays 100BaseT and OC3's. I've programmed in everything from
Fortran WATV (punch cards) to java and php. I collect computers (and
dust :-). I have a 2yr degree in electronics, but I'm self taught on
the rest (that's good and bad). And I'm always broke which requires me
to be frugal (actually I live with a budget every month).
Now my setup: (just what I have currently running)
Server:
Linux 2.2.14 AMD K6 3D 350Mhz 64M ram 22G storage (ram and storage
will be upgraded in the next few months). Samba, Appletalk/Nettalk,
print services, HomeDaemon, SSH access (remotely), ip firewall, tcpd,
and tftp, ftp, telnet and rcmds locally, http/https, NFS, snmp, smtp,
and dhcpd. I use this system for developemnt and Inet access. I also
have dial-in access but haven't setup the PPP access yet (another
'thing to do').
I/O Server:
Linux 2.2.12 486DX 100M 16M ram 2G storage (I use ~650M and I should
clean that up too). It has 10 Serial ports for the Ocelots, the
CM11A's, the HCS II, the weather station, the Palm Pilot and whatever
else I need. NFS, tftp, ftp, telnet, rmcds, smtp, snmp, HomeDaemon,
X10d, hcsd, wx200d and any other daemons I tend to develop. It is
strictly a local server, supporting local services. It currenly runs
cold at <1% utilization (it's been up for the last 26 days, taken down
for a very nasty electrical storm).
Firewall:
Netgear RT311, NAT/PAT services, blocks and logs various info, very
nice box. But will be replaced with a PII 133Mhz 64M ram no drive
firewall running Linux 2.4.x, diskless, etherboot and Netfilter (IP
mangler, NAT/PAT, etc. :-). This is because I need further info about
what is touching my ports so I can effectively/selectively block or
open services. I would love to get an embedded server to do this but
why should I spend that kind of money when I can build the entire
thing for less than $300 (motherboard & CPU <$100, 64M Ram <$100 and 2
Netgear 10/100 cards <$50, and case $10).
I have a bunch of other PC's which will be used for various things. My
wife has now become interested in access to the net and more
automation. So now I need to have an extremely stable network and
servers. So my next new machine will be for development. I also have
lots of 8 and 16 bit processor boards for use in automation projects.
BTW: I'd love to see a DMZ in a box (with external access to the DMZ
portion too). I could see such a device for less than $600.
DMZ in a Box
Home Internet
---+ +---
| |
+--o--+-----+--o--+
| | | |
| | +-+ | |
| Box |-|H| | Box |
| | |U| | |
| A | |B|-| B |
| | +-+ | |
| | | | |
+-----+--o--+-----+
|
Local DMZ
Imagine dialing up to an embedded processor that just expired. In my
experience both are as likely to occur. My PC currenly live in a very
harsh enviroment. There is lots of construction going on around the
house and dust gets kicked up everywhere. I have a regular maintenance
schedule for cleaning the dust out of the boxes (usually when I get to
it :-). The only weird casualty so far has been an NCR computer which
lost it's DMA controller while running. Weird, never seen anything
like that before.
I am in the process of building a room in the garage that will store
the racks or equipment. It will use filters and it will be air
conditioned. I doubt I'll need more than that for my equipment.
Remember I have more equipment that the average geek! :-)
I accept that all products fail what I was after was a measure of how many
of you are already running embedded PC solutions, and how much emphasis was
placed on the variation of operating systems.
Thanks
Darren Simons
"Neil Cherry" <n...@CC47532-A.ewndsr1.nj.home.com> wrote in message
news:slrn8u9a2...@CC47532-A.ewndsr1.nj.home.com...
> On Wed, 11 Oct 2000 09:07:05 +0100, Darren_Simons wrote:
> >>Neil Cherry wrote
> >>
> >> Yes but it's one little mind, I need to get some progress on the LHA
> >> project and soon. So I'm going to be coding quickly without all the
> >> fancy protocols. Just a plain telnet/8bit interface (to start off
> >> with). I am a little worried about working with MS but eventually it
> >> comes down to what ever is making progress.
> >>
> >> --
> >> Linux Home Automation Neil Cherry
nch...@home.net
> >
> >Just a small question what are you planning to run LHA package on?
> >
> >All of our products Echelon/Web server/etc based on embedded designs as
you
> >cannot trust a PC for long term operation. Imagine dialing up your home
to
> >find the PC has expired.
>
someone was too busy writing for embedded linux journal to be coding :-)
just got a copy of the magazine, great article.
for the other hardware disadvantaged authors, there is a contest in the
magazine, best 100 ideas for a project using an embedded 486 SOC with 4
meg flash and 32 megs of RAM get a free one with a copy of embedded linux,
etc.
don't have a url currently, but i'll try to find one.
david
Thanks, actually it was a very quickly written article (1 week), I'm
waiting for the community to chew it to pieces (I actually beleive
that). I have further articles that I'm working on but they will be
more hands on with coding. Now if I can only get my copy of the
article to see how it was edited (I told you it was written quickly).
>
>for the other hardware disadvantaged authors, there is a contest in the
>magazine, best 100 ideas for a project using an embedded 486 SOC with 4
>meg flash and 32 megs of RAM get a free one with a copy of embedded linux,
>etc.
>
>don't have a url currently, but i'll try to find one.
Now there is a challenge I'd love to undertake! No not getting the URL ...
I thought it was my mail server as I also saw a lot of other posts
doubled.
>I accept that all products fail what I was after was a measure of how many
>of you are already running embedded PC solutions, and how much emphasis was
>placed on the variation of operating systems.
I hope you didn't take my reply as a snide remark (it wasn't meant
that way). I was just giving my experience. Although I've left out the
bad days when I couldn't get a PC put back together (all the same
parts, no changes ;-). Turned out the the PC's BIOS setting had gotten
corrupted and reset itself to auto PNP mode. Put the boards where ever
it thought they would be best. Decided that it should use any of the
normal standards for things like serial ports (IRQ 3 & 4). Really
ruined my day. I fell back on using a MAC to complete my work!
>
> I hope you didn't take my reply as a snide remark (it wasn't meant
> that way). I was just giving my experience.
No, i guess the server was on a bad day.
Regards
Darren Simons
it doesn't look like their site is up yet. they usually take a while to
send out author copies, but they should appear eventually.
> >for the other hardware disadvantaged authors, there is a contest in the
> >magazine, best 100 ideas for a project using an embedded 486 SOC with 4
> >meg flash and 32 megs of RAM get a free one with a copy of embedded linux,
> >etc.
> >don't have a url currently, but i'll try to find one.
> Now there is a challenge I'd love to undertake! No not getting the URL ...
start thinking. i'll talk to someone at the LJ booth and tell them to mail
your copies sooner (i'm at the atlanta linux showcase now).
dave
There were a number of questions, criticisms and challenges. I
apologize for any missed. If you wish to repost, I will try to
answer.
First let me respond to the posts about being ignored etc. I think
many of you misunderstand Echelon's business model. Echelon is not a
manufacturer or developer of consumer products. The company's goal is
to provide the technology and infrastructure for OEMs to build into
their products. It is NOT Echelon's business to make, market and sell
light switches etc.
Echelon is talking to a wide variety of consumer goods manufacturers
but it is up to those companies to decide if there is sufficient
market to warrant the development and marketing of products. Echelon
is actively working on helping develop and extend those markets but it
takes time. The European market is developing at a far faster rate
than the US - as evidenced by ENEL etc. So, is Echelon ignoring you?
Not really, they recognize the desire for many products, but like any
company these days, they have limited resources, a defined business
model, and priorities. Echelon will continue to work with OEMs and
encourage them to produce the products needed for the market. It
doesn't hurt if you request the products from the OEMs as well.
Some will point out that you can buy CEBus light switches from (I
think) Domosys. However, try buying volume. Domosys is only
concerned with a limited technology that is only for the North
American HA market. Because of that, they created some prototype
products for testing. You might ask why doesn't Echelon do that, but
what would that serve? We are not set up to produce light switches in
volume, someone like Leviton is capable of doing that at far lower
cost than Echelon. So instead of producing a few prototype devices,
Echelon would rather spend that time producing products that Leviton
et. al. could integrate into their products in volume.
Next - Brent Eldstrom takes issue of our association with Sun/Java.
While we do have a relationship with Sun, if you look closely at the
various press releases, you will see that Echelon is involved in the
OSGi group, UPnP, Bluetooth, Jini etc. Echelon is actively involved
with various groups that are complementary with LonWorks.
Next - Costs. There were several issues - from cost of development to
cost of products. First lets deal with cost of products. Unlike
CEBus, LonWorks sells to an international market. Because of various
and fluctuating currencies and a multiple of internation distribution
agreements, Echelon does not post pricing on the website. If you go
to the contact page on the website, you can easily find a local
representative to call or email in order to get pricing. Its not
secret nor is it difficult to get pricing.
On the development side, pricing really depends on what you mean by
development ( uhh or was that - depends on what "is" is?). If you
want to create LonWorks networks based on off the shelf products, you
can do so for ~ $1100 using LonMaker for Windows and an interface
card. If you want to actually create your own hardware and
write/compile/debug/test your own device software, then you can do so
for ~$4500 US using the Nodebuilder (not $10K like someone
misstated). While some might say that is too expensive for hobbyists,
I point out that Echelon's business model is not aimed at hobbyists
but OEMs developing products for production. For OEM's this cost is
insignificant.
Peter Lawton asked about specifics on I/O specs. Peter, it was
unclear whether you were talking about I/O specs on the control
modules or the Neuron chip itself. The Neuron chip is produced by
Toshiba and Cypress so you can get data books from those companies
respectively. For the control module or any Echelon products, all
the manuals are online at :
http://www.echelon.com/products/technical/manuals.asp
Specifically the control module users guide is :
http://www.echelon.com/products/technical/pdfs/manuals/TPCTRLv2.pdf
I hope this answers most of the questions. I will add one additional
point that I didn't discuss in my earlier post detailing why I think
LonWorks will win out. The issue involves the light switch. In a
vast majority of homes in North American, light switches are wired
with no hot or ground wire. Typically the Neutral is run from the
light to the switch and back. Basically the switch is breaking the
circuit so that current cannot flow through the lightbulb. This is
also known as Switched Leg circuit. CEBus cannot communicate in such
a circuit. In other words you cannot put a CEBus light switch in such
a location without going to the trouble of running HOT to the switch
location as well. Echelon had engineered its powerline solution so
that it can operate in the Switched Leg circuit. Given such a large
base of homes with Switched Leg circuits, which technology would you
rather install?
Regards,
Fred
On Tue, 03 Oct 2000 22:39:48 -0400, Peter Lawton
<pe...@always.thinking-dot-com> wrote:
>Thank you, Neil. I asked for the same answers in my reply to the LonWorks note you mentioned, and
>was ignored. I don't understand why Echelon would "promote" LonWorks for home automation, if
>they're not interested in actually _selling_ the products. And if they're interested in selling,
>pricing should be available one way or another. I just don't get it.
>
>Peter Lawton
>
>
>Neil Cherry wrote:
>
><snip>
>
>>
>> So here is the challenge skip the marketing hype and don't bother to
>> tell us which system is better (X10 ain't it). Instead point us to
>> your products, tell us where to purchase them. And if you think that a
>> development system that runs at $1K and up is it then please say
>> so.
| I hope this answers most of the questions. I will add one additional
| point that I didn't discuss in my earlier post detailing why I think
| LonWorks will win out. The issue involves the light switch. In a
| vast majority of homes in North American, light switches are wired
| with no hot or ground wire.
I think this is a bit of overstatement. Switch loops are used, but not
(in my experience) in the vast majority of circuits (or even houses).
| Typically the Neutral is run from the
| light to the switch and back.
Now this I have never seen. The NEC has prohibited switched neutrals (except
in very special circumstances) for a *long* time. All legal switch loops
run hot to the switch and back.
| Basically the switch is breaking the
| circuit so that current cannot flow through the lightbulb. This is
| also known as Switched Leg circuit. CEBus cannot communicate in such
| a circuit. In other words you cannot put a CEBus light switch in such
| a location without going to the trouble of running HOT to the switch
| location as well.
(running neutral)
| Echelon had engineered its powerline solution so
| that it can operate in the Switched Leg circuit. Given such a large
| base of homes with Switched Leg circuits, which technology would you
| rather install?
This indeed a good point, and I think it was one of the clever aspects of
X10's original design that has made it so popular. It is entirely possible
that the feature is critical to the acceptance of a new automation standard,
at least one intended for retrofit. Sounds like a really good move on
Echelon's part.
Can you point me to a web site where I can order a LonWorks<->RS232 serial
adapter (with programming documentation of course) and a few LowWorks light
switches (in small quantity)?
Dan Lanciani
ddl@danlan.*com
:-) Amazing how only a few years ago, people were scrabbling for the
privilege of using dial-up connections while on the road....
[snip]
While I'm a late entry onto this thread, there's a few things I'd like to
add...
[snip]
> Some will point out that you can buy CEBus light switches from (I
> think) Domosys. However, try buying volume.
Yes this is true. However, Domosys runs more like the Echelon model than
your comments suggest, they prefer to deal with OEMs and partnerships rather
than design the products entirely themselves. There's a lot of popular
press lately about enabling technologies for the technology sake ("Sure we
can home-automate or home-network your teapot, but what benefits does it
add??"). I believe that the engineers who can and do solve these
networking/automation problems _are_ doing a good job, and they _shouldn't_
be expected to come up with uses for the products. Why should we refuse to
design a network interface into a product simply because no-one today can
imagine what it could ever do. I think we'd still be in the Dark Ages if
that was the prevailing attitude. I see Echelon and Domosys as being the
Technology Enablers, and I think that it's right that both companies should
pursue OEMs to be the "Applications developers". There are very few people
in the work who are good at both.
> Domosys is only
> concerned with a limited technology that is only for the North
> American HA market.
Whilst this used to be relatively true until quite recently, the recent
announcement of their U-Chip changes things rather profoundly. It claims to
be compatible with a wide range of Powerline standards across Europe and
North America.
> So instead of producing a few prototype devices,
> Echelon would rather spend that time producing products that Leviton
> et. al. could integrate into their products in volume.
I suspect Domosys is pursuing similar lines of approach.
> Next - Brent Eldstrom takes issue of our association with Sun/Java.
I don't have a problem with that. I think that it's too early to tell which
of the various networking solutions is most broadly applicable in the home.
Each has its features and benefits, each has its downsides too. For the
various movers and shakers to be co-operating-while-competing, at least in
theory, should ensure that we wind up with something close to the best
possible standards, picking and chosing the best features of each. The only
thing to watch is that the drive doesn't come from a single large direction
(some call it Redmond) to steamroll everyone else out of the way. However I
think that there are too many largish players for that to happen.
> Next - Costs. (Products)
[snip]
Again, no issue there, Echelon reps are out there...
> On the development side, [...] ~ $1100 using LonMaker for
> Windows and an interface card. [...] ~$4500 US using the
> Nodebuilder (not $10K like someone misstated).
If that someone's from Australia, $10K (Aus dollars) is about spot on!
[...]
> I point out that Echelon's business model is not aimed at hobbyists
This is true, however, this newsgroup pretty much IS aimed at,... well, not
so much hobbyists per se, but DIYers. Sometimes these folks have a hard time
seeing that it's not in many people's business interests to cater for
hobbyists.
> For OEM's this cost is insignificant.
There is, however, a class of developers (small start-ups with often quite
good ideas and limited capital) where this _does_ represent a significant
(but not insurmountable) cost. While they're not hobbyists, they are not
full blown OEMs with megadollar budgets either. Maybe Technology enablers
should consider charging, rather than a flat rate, say a fixed percentage of
a companies annual turnover for the development tools. (Don't bother taking
me up on this, I already know how impractical it is, my point was to suggest
that all OEM's had to start somewhere and they likely did start very
small!).
> Peter Lawton asked about specifics on I/O specs. .... The
> Neuron chip is produced by Toshiba and Cypress
... and Motorola??... although I understand that's not on-going...
> I hope this answers most of the questions. I will add one additional
> point that I didn't discuss in my earlier post detailing why I think
> LonWorks will win out. The issue involves the light switch.
I think people should be considering putting the node in the light fitting,
rather than the switch. In many countries it's not even legal to remove the
screws holding the light switch to the wall, much less play with the wiring,
without a license. The costs are therefore going to be similar if not
identical to put the network node at either end of the circuit.
Sure, offer the line of products for DIYers in those countries that permit
it, but there are high costs associated with packaging (has to look like a
light switch), size (has to fit in a 1" wide architrave knock-out), heat
(often totally enclosed) etc. Nodes designed for installation in the roof
space will ALWAYS be cheaper, since those issues are not of concern. So
they should be the first lines of products offered, since they give the OEMs
opportunities to make a better profit to recover their startup costs, and
THEN produce the visible modules (probably cheaper than if they started the
other way around).
Now for something that I've heard suggested elsewhere...
It's also totally pointless having two separate network nodes for a light
switch and light fitting (even in a retrofit). And that's regardless of
whether it's X-10, CEBus, Lonworks, TCP/IP, Bluetooth or what... Why waste
all that traffic between two devices that 99% of the time only talk to each
other anyway!? Save your bandwidth (and dollars) for where you need it,...
_between_ the small sub-systems (where a light switch and socket is
considered a subsystem).
David.