TCP/IP home automation?
Matt
I'm looking for some info on what's available for TCP/IP home automation.
What I'm looking do is run Cat 5, or maybe even a higher capacity cabling,
and connect everything to this and control it all via an intranet. TCP/IP
seems to be the ideal solution since:
1. I have a very complex, multi OS, home LAN with two dedicated servers.
2. It's the most flexible and widely used protocol today.
3. It's a lot faster and more reliable than X-10
I have heard a lot about the iPic, but not much besides that. Does anyone
have any experience with this?
Mike Baptiste
things like wall switches, etc. X-10 is simple. Most switches use a small
PIC processor inside to handle all control. Problem is, 8-bit PIC micros
are not designed to implement complete TCP/IP stacks. I've seen cool
solutions with highher end PICs tied to one chip TCP/IP solutions (the iChip
from Seiko is really neat - but again pulls an iPic and uses a serial SLIP
interface) One person tied a PIC to a Cirrus network chip and managed to get
on the Ethernet with two chips. The iPIC is neat, but it uses a serial port
connected to a router to connect to Ethernet.
You'll hear lots about a product called emWare which uses a tiny kernel put
inside PIC hardware and then sends tokens over a hardwire bus to a 'gateway'
to teh Ethernet which can be an embedded PC board or standalone PC. Its a
neat idea. The PIC can become a type of web server, but the need for a
gateway is an achilles heel in some sense. It is still unclear what type of
setup they will use to communicate between the emWare device and the
gateway.
Dallas Semi has gotten a fully funcitonal TCP/IP Java computer onto a SIMM
form factor which holds a lot of promise. The TINI board has Ethernet,
RS-232, and Dallas 1-Wire allowing it to serve as a bridge. It is fairly
new and undergoing a lot of changes software wise, but there are LOTs of
folks interested in it. Goto http://63.67.172.146:9000/ to see a simple
page served up by this tiny device. I know a number of folks are trying to
tie them to CM11As to make a standalone X-10 controller. Dallas obviously
is looking to push folks towards making appliances and such 1-wire enabled,
tied to a TINI bridge. The good news here is 1-wire is cheap, easy to wire
(2 wires, data and ground) and the TINI board is about $50. Since they use
Java, it is easy to program and lots of classes are already out there.
You also have to think of wiring. Power LIne Carrier solutions are so
popular because you don't have to add wiring to control the devices. Plus,
the National Electric Code is a bit squimish about low voltage control
wiring terminating inside the same junction box as 110VAC wires. Can you
imagine if you ran Ethernet into a J-box and it shorted with 110VAC. If you
were lucky only your hub would be fried!
The hard truth is, unless CeBus takes hold (which until now it hasn't - why?
Too complex), X-10 will remain the dominant way to control 110VAC. Ethernet
will come into play, but mostly as an interface medium. You use a wireless
browser touchpad (Honeywell showed an AWESOME one at Comdex) to browse to
some type of HA controller with an Ethernet port to control stuff, etc. I
think the idea of a 'home server' is interesting (Cisco wants to put
everything inside the DSL/Cable modem) but I worry about open standards and
such. I also worry that the big corporations goal is to provide more of a
control bridge solution (ie how can a person control their A/V, HVAC,
lights, etc from a central device) vs true automation of a home.
I'm rambling and these are just my opinions. Do I think Ethernet will have
a big impact on HA? Absolutely and we are hard at work to add Ethernet
access to our HCS-II product without using a gateway PC since the HCS-II is
a standalone hoem automation solution (it'll probably be a TINI board serial
to Ethernet bridge) But will Ethernet replace PLC and low voltage hardwire
control like 24VAC for HVAC and RS-485 for true networking of industrial
control systems, etc? I doubt it. It is hard to justify the added cost and
complexity for being able to network to it. That is why bridging solutions
will become sought after.
My opinons only, flame at will.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mike Baptiste bapt...@cc-concepts.com
Creative Control Concepts http://www.cc-concepts.com/
** Home Automation Products for the Serious Enthusiast **
Check out the new HA FAQ http://63.67.172.146/cgi-bin/fom
See Our Home Renovation http://63.67.172.146:8002/remodel
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Matt" <Ma...@w3board.com> wrote in message
news:gD6r4.1107$co6....@typhoon.mw.mediaone.net...
Dave Houston
[...]
>
>The hard truth is, unless CeBus takes hold (which until now it hasn't - why?
>Too complex), X-10 will remain the dominant way to control 110VAC. Ethernet
>will come into play, but mostly as an interface medium. You use a wireless
>browser touchpad (Honeywell showed an AWESOME one at Comdex) to browse to
>some type of HA controller with an Ethernet port to control stuff, etc. I
>think the idea of a 'home server' is interesting (Cisco wants to put
>everything inside the DSL/Cable modem) but I worry about open standards and
>such. I also worry that the big corporations goal is to provide more of a
>control bridge solution (ie how can a person control their A/V, HVAC,
>lights, etc from a central device) vs true automation of a home.
I'd also worry about what data they will harvest.
BTW, I agree with most of your other points about a zillion percent.
---
Dave Houston
http://Commander-X.com
Dan Lanciani
| The trouble is, TCP/IP is not simple to implement in an embedded nature for
| things like wall switches, etc.
Actually, tcp/ip is pretty simple to implement, embedded or otherwise. However,
for this kind of control application where there is no reason to be moving bulk
data around, I would more likely choose udp/ip and that is downright trivial to
implement. But of course, whether you are talking ip or X10, the hardest part
in a wall switch or similar device is the physical transport layer. The second
hardest task is probably configuration. Traditional X10 got by with a house and
unit code (thus keeping things simple enough to set with dials), but more modern
devices with their scenes and options need configuration comparable to what an
ip device would require. Probably ip would win since it now has several well-
understood "auto" configuration mechanisms.
| X-10 is simple.
Not simple enough it would seem: virtually every third-party manufacturer of
"X10 compatible" equipment manages to screw up the protocol in one way or
another. At least ip has published standards to refer to...
| Most switches use a small
| PIC processor inside to handle all control. Problem is, 8-bit PIC micros
| are not designed to implement complete TCP/IP stacks.
And here we come to my pet peeve. Manufacturers of consumer electronic gadgets
(and this seems to apply especially to the X10 market) feel compelled to select
the absolute cheapest MCU that they think might possibly handle the task. (This
is not good cost engineering; it's just inexperience combined with greed.) As
the development process continues, they find that the processor is not capable
of correctly handling X10 (which turns out to be a little less "simple" than
they thought). But since they have committed to the inadequate hardware they
press on and kludge something together, documenting the resulting bugs as
"features." There is no need of this. There is a _huge_ variety of MCUs
available in an incredible range of computing power. There are families of
microcontrollers that would let you trade up as needed without any other circuit
or package changes. Trying to minimize the cost of the production unit (and
locking yourself to particular hardware) before you even have a notion of the
prototype is rarely the optimal way to design a product.
The above said, the fact that _current_ switches typically use a processor that
is inadequate for running tcp/ip is largely irrelevant. There are plenty of
processors that _are_ adequate which could be incorporated in future designs.
Maybe as a byproduct we could get a switch platform with enough power to
run 2-way X10 correctly... :(
| You also have to think of wiring. Power LIne Carrier solutions are so
| popular because you don't have to add wiring to control the devices.
PLC and ip are not mutually exclusive; you could implement a power line
transport for ip. I'm not saying this would be the greatest idea in the
world, but I'd prefer it to CEBus at this point.
| Plus,
| the National Electric Code is a bit squimish about low voltage control
| wiring terminating inside the same junction box as 110VAC wires.
Well, the NEC has a number of largely archaic provisions. They are not
archaic because they are no longer good ideas from a safety standpoint
(though there is some question about how vital they really were) but because
they are effectively trumped by UL listings. Any manufacturer can get a
UL listing for a device with low- and high-voltage wiring in the same box
without even an internal partition. Just look at any number of X10 products
or low-voltage lighting control systems. About all the NEC does in this area
is prevent DIY'ers from putting together their own solutions and installing
them legally. However, this is really moot since I suspect any marketable
product along these lines would have to be PLC-based.
| Can you
| imagine if you ran Ethernet into a J-box and it shorted with 110VAC.
I imagine it wouldn't be too different from the effect I'd get if the 110V
and Ethernet connections inside my flimsy plastic hub were shorted by, say,
a scrap of wire that fell in a vent. (Yes, this hub really has a 110V cord
and no wall wart.)
| The hard truth is, unless CeBus takes hold (which until now it hasn't - why?
| Too complex),
CEBus hasn't caught on because its documentation has been kept out of the hands
of the public...
Dan Lanciani
ddl@danlan.*com
Mike Baptiste
products - because they work and are easy to develop with. I've designed a
number of them with X-10 funcitonality including one which converts parallel
data into X10 commands and it was done in under 500 bytes. And it is
compliant with the X-10 FAQs out there. NO, it doesn't do extended, but the
TW-523 can't do it anyway. Obviously using a PIC directly connected to the
power line requires more complexity (ie doing the timing and TW-523
functionality) Choosing any device simply because it is cheap is bad
practice. But in many areas these devices work wonders and perform tasks
that used to requrie lots of silicon and lots of $$$ And the bottom line
is, cost does matter because there is a point where people won't open their
wallets. Sure, Panja sells lots of excellent and feature rich systems, but
not to the mass market. Who can afford $15k for Home Automation when they
build their house? Not many from a marketing point of view, even in this
wildly good economy. My remote products use 8-bit micros to get the job
done and at a price that is reasonable. But each to their own I guess.
When I said TCP/IP was hard to implement, I meant a functioning stack that
would handle things like DNS, DHCP (a must), and such. Sure, things are
getting a lot smaller - but there are many hurdles to overcome including, as
you mentioned, how to transport IP and on what media (powerline, dedicated
wires, etc) I still say simpler protocols will get you farther in teh
stability arena (X-10 excluded of course :) ) And even though you can fit a
functioning TCP node into a light switch, doesn't necessarily mean you
should since things like transport, wiring, safety, and such some into play.
Look how many people hedge at buying higher quality X10 stuff? I'll be the
first to say they function MUCH better and that AGC/Intellisense work
better. MY PCS switches are a dream. But even I develop a quirk when
thinking about putting PCS switches throguhout my house. Say $30 switches
at $50. $1500 seems like a trivial amount and when building a $300,000 home
it is. But it is psychological. I still have not decided if I'll do it,
even though I can. But $1,500 here and there adds up when your dreamhouse
is overbudget before you start :)
As for CEBus simply being a documentation issue, thats part of it. But if
anyone out there gets Circuit Cellar INK, a gentleman from Echelon did an
article on CEBus and how easy it was to design a remote CEBus node -
basically a remote relay. Simple - turn on and turn off though it did do
plug and play. It was March 1999, Issue 104. By the time he had setup all
his dozens of classes, and objects, and such, plus used a $40 interface chip
(Just the chip mind you), he had managed to turn the relay on. Never saw
any code (guess that is still private) but the overview was complex enough.
Too complex IMHO for turning a relay on and off.
Don't get me wrong - I think CEBus drives at the right thing. A way to make
devices plug and play no matter what medium they use. But the problem is,
the plug and play part of CEBus requires so much CPU power to oversee, you
end up substantially increasing the cost of any central controller you might
have (and the nodes) just to gain the leisure of not having to set a few dip
switches.
I'm not trying to start another holy war thread over CEBus. I think deep
down in teh specs it has lots of promise and benefit for home automation.
But its completness becomes a handicap when it comes down to implementation,
no matter how complex silicon has gotten.
Mike
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mike Baptiste bapt...@cc-concepts.com
Creative Control Concepts http://www.cc-concepts.com/
** Home Automation Products for the Serious Enthusiast **
Check out the new HA FAQ http://63.67.172.146/cgi-bin/fom
See Our Home Renovation http://63.67.172.146:8002/remodel
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Dan Lanciani" <ddl@danlan.*com> wrote in message
news:620...@news1.IPSWITCHS.CMM...
> In article <vxRr4.55628$ox5.15...@tw11.nn.bcandid.com>,
bapt...@cc-concepts.com (Mike Baptiste) writes:
> | The trouble is, TCP/IP is not simple to implement in an embedded nature
for
> | things like wall switches, etc.
>
> Actually, tcp/ip is pretty simple to implement, embedded or otherwise.
However,
> for this kind of control application where there is no reason to be moving
bulk
> data around, I would more likely choose udp/ip and that is downright
trivial to
> implement. But of course, whether you are talking ip or X10, the hardest
part
> in a wall switch or similar device is the physical transport layer. The
second
> hardest task is probably configuration. Traditional X10 got by with a
house and
> unit code (thus keeping things simple enough to set with dials), but more
modern
> devices with their scenes and options need configuration comparable to
what an
> ip device would require. Probably ip would win since it now has several
well-
> understood "auto" configuration mechanisms.
>
> | X-10 is simple.
>
> Not simple enough it would seem: virtually every third-party manufacturer
of
> "X10 compatible" equipment manages to screw up the protocol in one way or
> another. At least ip has published standards to refer to...
>
> | Most switches use a small
> | PIC processor inside to handle all control. Problem is, 8-bit PIC
micros
> | are not designed to implement complete TCP/IP stacks.
>
> | You also have to think of wiring. Power LIne Carrier solutions are so
> | popular because you don't have to add wiring to control the devices.
>
> PLC and ip are not mutually exclusive; you could implement a power line
> transport for ip. I'm not saying this would be the greatest idea in the
> world, but I'd prefer it to CEBus at this point.
>
> | Plus,
> | the National Electric Code is a bit squimish about low voltage control
> | wiring terminating inside the same junction box as 110VAC wires.
>
> Well, the NEC has a number of largely archaic provisions. They are not
> archaic because they are no longer good ideas from a safety standpoint
> (though there is some question about how vital they really were) but
because
> they are effectively trumped by UL listings. Any manufacturer can get a
> UL listing for a device with low- and high-voltage wiring in the same box
> without even an internal partition. Just look at any number of X10
products
> or low-voltage lighting control systems. About all the NEC does in this
area
> is prevent DIY'ers from putting together their own solutions and
installing
> them legally. However, this is really moot since I suspect any marketable
> product along these lines would have to be PLC-based.
>
> | Can you
> | imagine if you ran Ethernet into a J-box and it shorted with 110VAC.
>
> I imagine it wouldn't be too different from the effect I'd get if the 110V
> and Ethernet connections inside my flimsy plastic hub were shorted by,
say,
> a scrap of wire that fell in a vent. (Yes, this hub really has a 110V
cord
> and no wall wart.)
>
> | The hard truth is, unless CeBus takes hold (which until now it hasn't -
why?
> | Too complex),
>
Dan Lanciani
|Well, I can't speak for other manufacturers, but I use PICs in many of my
|products - because they work and are easy to develop with. I've designed a
|number of them with X-10 funcitonality including one which converts parallel
|data into X10 commands and it was done in under 500 bytes.
Would that have any relation to the PLIX?
|And it is
|compliant with the X-10 FAQs out there.
I wish those FAQs were a little more detailed for the benefit of other
manufacturers. :) Just for fun, I'll attach another copy of my X10
selection state diagram in hopes that it might make it into one of
those FAQs.
|Obviously using a PIC directly connected to the
|power line requires more complexity (ie doing the timing and TW-523
|functionality)
Actually, the TW523 doesn't do any timing for you (or what timing it does do
does not relieve you of doing any timing :) so the burden in that respect
is about the same.
|Choosing any device simply because it is cheap is bad
|practice. But in many areas these devices work wonders and perform tasks
|that used to requrie lots of silicon and lots of $$$ And the bottom line
|is, cost does matter because there is a point where people won't open their
|wallets.
We are typically talking about high-end products here with end-user prices
> $50. I'm not convinced that manufacturers who skimp by shaving $0.50 or
so off the cost of the MCU really have low end-user prices in mind since
that price is usually set by what the market will bear. (This is further
reinforced by the fact that companies will sometimes sell the exact same
hardware platform with different firmware options enabled at different
prices.) Again, I think the main problem is inexperience and greed. Now,
I'm not saying there is anything wrong with PICs per se: even considering
only a single PIC family there is a huge range of computing power available.
The problem comes when a designer locks himself in to the least powerful member
of the family that he thinks (incorrectly) he can get away with. It's an
interesting phenomenon that seems to afflict this industry. The meta-problem
comes from the catch-22 as others observe the under-powered hardware barely
getting the job done and then assume that running a more sophisticated protocol
is out of the question for cost reasons.
|When I said TCP/IP was hard to implement, I meant a functioning stack that
|would handle things like DNS, DHCP (a must), and such.
Again, these things really are not hard to implement. Of course, I doubt
you would want DNS services within a light switch. DHCP is merely a bloated
version of bootp which is itself trivial. I strongly doubt that you would want
to use DHCP as-is in this kind of application. Perhaps a customized version
of bootp or an entirely different autoconfiguration protocol would be in order.
|Sure, things are
|getting a lot smaller - but there are many hurdles to overcome including, as
|you mentioned, how to transport IP and on what media (powerline, dedicated
|wires, etc)
The transport problem remains the same independent of the selected protocol.
|I still say simpler protocols will get you farther in teh
|stability arena (X-10 excluded of course :) )
I guess then I'm asking: what is an example of such a simpler protocol? IP
is a very simple and very powerful protocol that incorporates good mechanisms
to solve internetworking problems from the start. It is well documented and
extremely well understood (because of many collective man-years of analysis).
You would be hard pressed to come up with something better without extensive
work. And it's not that people (reasonably smart people, too) haven't tried
from a number of different angles. We have for example Appletalk (copy the
protocol with minor changes) and OSI (design by committee). Look what
happened to them...
|And even though you can fit a
|functioning TCP node into a light switch, doesn't necessarily mean you
|should since things like transport, wiring, safety, and such some into play.
Again, transport, wiring, and safety issues remain the same no matter what
protocol you run on the wire.
|Look how many people hedge at buying higher quality X10 stuff?
While I can't speak for others, the reason I don't buy higher quality X10
components is that (at least until very recently when Leviton introduced
true rocker switches) they don't (didn't) exist. Sure, you can buy higher
_price_ X10 components but most of the third-party products have serious bugs
that disqualify them from the category of high (let alone higher) quality.
|I'll be the
|first to say they function MUCH better and that AGC/Intellisense work
|better.
Hmm, I haven't noticed any obvious benefit from AGC in X10 products.
|MY PCS switches are a dream.
The PCS switches I tried a few years ago were a nightmare. The selection
state machine was so broken that simple commands like A1A2AON would fail
to activate unit A1. Moreover, the designers didn't even understand how
commands from different house codes (don't) interact. I hear they fixed
the first problem (no updates to previous users, of course) but I think
the other remains. It just amazes me that people will set out to build
a product with no knowledge of how it is supposed to work. Couldn't they
at least educate themselves by obtaining a real X10 module and observing
its responses _before_ implementing?
|As for CEBus simply being a documentation issue, thats part of it. But if
|anyone out there gets Circuit Cellar INK, a gentleman from Echelon did an
|article on CEBus and how easy it was to design a remote CEBus node -
|basically a remote relay. Simple - turn on and turn off though it did do
|plug and play. It was March 1999, Issue 104.
And there was another article (series) before that by someone from Intellon.
It failed to mention that the examples wouldn't run on the serial interface
that they had sold only a few months before since it didn't support addressed
packets--unaddressed packets had effectively been deprecated before the spec
was even released.
|By the time he had setup all
|his dozens of classes, and objects, and such, plus used a $40 interface chip
|(Just the chip mind you), he had managed to turn the relay on. Never saw
|any code (guess that is still private) but the overview was complex enough.
|Too complex IMHO for turning a relay on and off.
Indeed, the CEBus protocol is a disaster as protocols go. It seems to have
been put together mostly by people who understood neither networking nor
automation. (Though one could cynically observe that some understood their
patented transport layer implementations well enough to embed them in the
standard and insure a royalty stream from implementors.) It appears that
the authors struggled valiantly with problems whose solutions have been well
understood in the networking community for years, finding their own answers
rather than drawing on existing wisdom. The result was a protocol that had
warts like the aforementioned obsolete unaddressed packets before it was even
published. We won't even talk about the multiple layers with variable-length
headers that make parsing IP look like a cakewalk.
For all of its problems, though, CEBus looked like it would be a real standard,
and those of us who realize that any standard is often better than no standard
would have done our best to support it if given half a chance. Personally, I
bought a few of just about every CEBus device made (all the revisions of the
early serial interfaces, dimmer switches, relay switches, RF interfaces, etc.)
But after several years of being locked out of the documentation process I just
gave up. The "standard" was conveniently developed as proposed (but never
approved) pieces of EIA600 rather than updates to IS60. This allowed Global
to ship nothing in return for the yearly subscription fee while claiming that
they had already provided up-to-date documentation. Sure, if you really pushed
the issue you could order individual sections of the real spec, but they cost
hundreds of dollars each (for a few dozen pages) making the total set cost in
the thousands. Moreover, you could never order everything at once since EIA
only allowed the sections to be sold while they were open for comment. When
it looked like some pieces of EIA600 were finally going to move to a state
of approval that they could no longer justify withholding, Global preemptively
raised the subscription price (remember that the subscription was always
supposed to include the released EIA600). Yet even though my existing
subscription at the time had several months to run, they managed to not have
those pieces available in time to ship before it expired. That's when I
bailed. Truly this was the most closed open standards process I have ever
experienced.
|Don't get me wrong - I think CEBus drives at the right thing. A way to make
|devices plug and play no matter what medium they use.
The whole plug & play thing is a relatively recent addition to CEBus. It almost
seems like an attempt to salvage parts of the protocol by adding yet another
layer of kludge. Nevertheless, any standard for interoperability may still be
better than none.
|But the problem is,
|the plug and play part of CEBus requires so much CPU power to oversee, you
|end up substantially increasing the cost of any central controller you might
|have (and the nodes) just to gain the leisure of not having to set a few dip
|switches.
Surely we can afford a little CPU power in the central controller...
|I'm not trying to start another holy war thread over CEBus. I think deep
|down in teh specs it has lots of promise and benefit for home automation.
IMHO it has little technical merit as far as the details of the protocol go.
The main (only) benefit I see is that it is a standard.
Dan Lanciani
ddl@danlan.*com
----- (begin X10 selection state diagram) -----
------------------------------------------------------------------------------
The below state diagram describes only the selection machine behavior. It does
not define operational state changes. State changes occur only on commands and
unit codes directed to the module's house code. All other house codes are
ignored. Self-transitions are not shown.
________________________________________
| |
| |
| |
| IDLE |------------
| | |
| | |
| | |
---------------------------------------- |
| |
\|/ (my unit code) |
________________________________________ |
| | |
| | /|\
| | |
| SELECTED |-----------| (ALL_UNITS_OFF)
| | |
| | |
| | |
---------------------------------------- |
[2] /|\ | (any command except |
(my unit code)| \|/ ALL_UNITS_OFF [1]) |
________________________________________ |
| | |
| | |
| | /|\
| COMMANDED |-----------| (ALL_UNITS_OFF or any
| | unit code other than
| | my own [2])
| |
----------------------------------------
[1] This really means *any* command except ALL_UNITS_OFF. It includes
global and unit-specific commands. It includes commands that are not
relevant to the operational state of the module (e.g., DIM/BRI for
an appliance module) and even commands that are not implemented by any
module (e.g., Hail).
[2] Note that any unit code exits the COMMANDED state with the new state
determined by a match on the module's identity. This is important to
maintain a single non-IDLE state per house code. In other words, within
a single house code domain (and assuming of course that all modules hear
all transmissions), all non-IDLE modules will be in the same state. It is
impossible to have one module in the SELECTED state and another in the
COMMANDED state.
The operational state change rule is simple. A module executes a command
unless the command is unit-specific and the module is in the IDLE state.
Here are some examples of correct operation for a module at A1.
A1 AON A2 AOFF -> the module is on
A1 AON B1 AOFF -> the module is off
A1 AOFF A1 AHAIL_ACK B1 AON -> the module is on
A1 AOFF A1 AHAIL_ACK A2 AON -> the module is off
A1 AON ASTATUS_REQUEST -> the module is on and responds to the status query
Patrick Hurley
about 4 months before the walls go up and my only option through the builder
is an OnQ system they admit they have never installed before...
pth
rich <ro...@127.0.0.1> wrote in message
news:slrn8aqovt....@stomper.micro.lucent.com...
> Also schrieb Dominik Hartl:
>
> >An X10 lamp module goes for approx. $10. The same for the switch. So we
have
> >$200. If a good, reliable non-X10 switch is around $100 then the whole
thing
> >is $2000. Big deal. How much do people normally spend on e.g. the carpet
> >upgrade or a Corian countertop ??? I really don't understand this run for
> >super-cheap, crappy X-10 components... I think it will hurt the home
> >automation market more than it helps.
>
> The biggest drawback with the hardwired stuff is that you have to plan
> everything and prerun the wire. Which is okay if you're building, but
> in older homes it can be a bitch to retrofit automation into a house
> without gutting the house, or using powerline, or doing something
wireless.
>
> I wish I had the wherewithal and the time to put in hardwire to all my
> switches. As it is, I'm taking a hard, hard look at a wireless option.
> My electrician has done a bunch of home automation installations
> (strange, huh, to find an electrician who knows this stuff and likes
> it?) and he is really hot on wireless. (Saves him work while his wires
> are going in, so I can see why.)
>
> --
> Catch the cluetrain. http://www.cluetrain.com
> A philosopher sees the earth as a large planet, traveling through the
> heavens, covered with fools. -- Bernard le Bovier de Fontenelle
(1657-1757)
carl
home automation technology together is Crestron
(www.crestron.com) For about $2000 you can get a box that
has an ethernet port,8 low voltage contact closures,8
contact inputs, 8 ir outputs, 8 ir inputs, 6 serial ports,
and the brains for a rs-485 network that can control
anything from touchscreens to lights depending on what
modules you add. The ir ports can be programmed to
control any t.v. or other ir conntrolable device. The
system isn't cheap, but it is reliable. If you're into HTML
and have a full-time internet connection, you can write a
page that lets you control your whole house from the net.
(better put a good password on that page)
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
Robert L Bass
several HAI dealers represented here, including Brian Karas and myself, who
would be happy to provide you with everything you'd need at much better prices
than the inexperienced builder will charge.
Also, by installing it yourself you will gain a much better understanding of the
system than by paying someone else to do it. The job is not all that hard if
you have some patience and a modicum of tool skills.
--
Regards,
Robert L Bass
==========================>
Bass Home Electronics
The Online DIY Alarm Store
http://www.Bass-Home.com
80 Bentwood Road
West Hartford, CT 06107
860-561-9542 voice
860-561-5210 fax
alar...@home.com
==========================>
Patrick Hurley <sp...@hurleyhome.com> wrote in message
news:tSxs4.70$fc6....@typhoon.mw.mediaone.net...
: Any links on wireless stuff? I am still trying to make up my mind. I have
:
:
Patrick Hurley
up a pandora's box of choices :-) Now I have existing CPU-XA/and other
various X-10 devices, but really want something faster and more reliable
than X-10. I was going to get with Omni's lighting system, but now I have to
pick from more choices. Any pro's and con's between the various hard wired
(or possibly wireless?) choices?
Also I have heard on occasion (around here) that having your lighting "home
run" is a "good thing". I assume this means that all master circuit switches
go through a common panel (additional to the breaker panel)? I understand
that that is what having my Cat 5 and cable home run means (and I have
already got that spec'd), but those are not "switched".
Thanks in advance
pth
Robert L Bass <alar...@home.com> wrote in message
news:ywJs4.18172$hT2....@news1.rdc1.ct.home.com...
Jonas Hellgren
RJ45.
http://www.lantronix.com/products/uts/cobox_micro/
"Matt" <Ma...@w3board.com> skrev i meddelandet