Economical Insteon+X10 HA?

[Matthew]

Insteon looks like the best HA control system, but it's expensive. A "cheap" plug-in lamp module is a minimum $25, which at 150W probably supplies at most 2-3 lamps (a 300W module is $35). But lamps are often $10-20 themselves, so the controller adds something like 50-100% to the price at the low end (which is where most lamps fall). And that's for controlling a bank of lights as a unit - real scenarios would call for a $25 module for each lamp, or hundreds/thousands of dollars for a decent sized home (that could most benefit from automation).

X10 is a much cruder form of control, but it's much cheaper. An X10 lamp controller is as little as $4 (cheaper than that would be hard to ask for).

Insteon controllers are supposed to be completely backwards compatible with X10 modules, so X10 modules should be treatable as cheap, low-function additions to a higher quality Insteon network. Is that really true? Is there any benefit to using an Insteon module where a cheaper X10 module will be sufficient?

[blackoper]

Cheap or 100% effective w/ rf
pick one.

home automation isn't a cheap endeavor.  Insteon is one of the best types of new home automation tech and it's price reflects it, similarly X10 is not  the best way to automate and sometimes has commuication problems/misses and delays. Since x10 is so cheap, you can buy a few of the modules and see how it works for you. and insteon is compatible with the older x10 tech.

[ddamron]

Matthew,
The Insteon PLM driver is now complete, and DOES support bidirectional X10 ON/OFF commands.
Search the wiki for Insteon PLM.

IMHO, Insteon is 5-6 times as expensive as older X10 modules, but 1000 times better.

41 times faster, FULLY BIDIRECTIONAL, Confirms messages, smart, DUAL mesh architecture, and on and on and on..
X10 is SLOW, does NOT confirm messages, dumb, limited (only 256 devices), PLC only, needs filters/phase couplers, etc, etc, etc

I suggest you get yourself a PLM, 1 insteon device, and 1 X10 device.  Try them both out, and you decide.

Regards,

Dan

(Insteon PLM Driver developer)

[Matthew]

Matthew,
The Insteon PLM driver is now complete, and DOES support bidirectional X10 ON/OFF commands.
Search the wiki for Insteon PLM.

IMHO, Insteon is 5-6 times as expensive as older X10 modules, but 1000 times better.

41 times faster, FULLY BIDIRECTIONAL, Confirms messages, smart, DUAL mesh architecture, and on and on and on..
X10 is SLOW, does NOT confirm messages, dumb, limited (only 256 devices), PLC only, needs filters/phase couplers, etc, etc, etc

I suggest you get yourself a PLM, 1 insteon device, and 1 X10 device.  Try them both out, and you decide.

I understand that X10's cheapness reflects its reliability. But since you've now got LMCE supporting bidirectional commands to X10 devices, does that mean that when an X10 command fails, that LMCE can sense the actual state, and retry the command until it succeeds? Is the kind of X10 failure we get for cheap the intermittent kind, or something else, and can it be compensated by getting feedback and retrying? If so, it does for X10 what TCP does for unreliable networks: makes it fairly reliable, just requiring occasional repair. And therefore really cheap. Cheap enough that an automated lamp that merely lights a place reliably can cost $10-15, not $30-35, which means about 3x as many new lights on the same (purchase) budget, or 5x as many lights controlled on the same purchase budget - which can be controlled to save power, and therefore money, and break even quicker.

[ddamron]

Matthew,
The Insteon PLM driver is now complete, and DOES support bidirectional X10 ON/OFF commands.
Search the wiki for Insteon PLM.

IMHO, Insteon is 5-6 times as expensive as older X10 modules, but 1000 times better.

41 times faster, FULLY BIDIRECTIONAL, Confirms messages, smart, DUAL mesh architecture, and on and on and on..
X10 is SLOW, does NOT confirm messages, dumb, limited (only 256 devices), PLC only, needs filters/phase couplers, etc, etc, etc

I suggest you get yourself a PLM, 1 insteon device, and 1 X10 device.  Try them both out, and you decide.

I understand that X10's cheapness reflects its reliability. But since you've now got LMCE supporting bidirectional commands to X10 devices, does that mean that when an X10 command fails, that LMCE can sense the actual state, and retry the command until it succeeds? Is the kind of X10 failure we get for cheap the intermittent kind, or something else, and can it be compensated by getting feedback and retrying? If so, it does for X10 what TCP does for unreliable networks: makes it fairly reliable, just requiring occasional repair. And therefore really cheap. Cheap enough that an automated lamp that merely lights a place reliably can cost $10-15, not $30-35, which means about 3x as many new lights on the same (purchase) budget, or 5x as many lights controlled on the same purchase budget - which can be controlled to save power, and therefore money, and break even quicker.

No, X10 does not support failure reports.. (at least not to my knowledge)
and even though the PLM Driver supports X10 2-way, that doesn't mean that X10 does..
All that means is that when an X10 command is transmitted across the powerline, the insteon PLM can hear it, and report that command to lmce.

I don't have any 2-way X10 devices, so I can't be sure if they transmit when they are controlled manually..

I do know there is a report status.. but I haven't implemented that (I need 2-way X10 devices)

Currently, the only X10 commands supported are ON/OFF.. but they ARE bidirectional..

If you send an X10 command from an X10 controller, then chances are, LMCE will hear that.

HTH,

Dan

[Matthew]

Matthew,
The Insteon PLM driver is now complete, and DOES support bidirectional X10 ON/OFF commands.
Search the wiki for Insteon PLM.

IMHO, Insteon is 5-6 times as expensive as older X10 modules, but 1000 times better.

41 times faster, FULLY BIDIRECTIONAL, Confirms messages, smart, DUAL mesh architecture, and on and on and on..
X10 is SLOW, does NOT confirm messages, dumb, limited (only 256 devices), PLC only, needs filters/phase couplers, etc, etc, etc

I suggest you get yourself a PLM, 1 insteon device, and 1 X10 device.  Try them both out, and you decide.

I understand that X10's cheapness reflects its reliability. But since you've now got LMCE supporting bidirectional commands to X10 devices, does that mean that when an X10 command fails, that LMCE can sense the actual state, and retry the command until it succeeds? Is the kind of X10 failure we get for cheap the intermittent kind, or something else, and can it be compensated by getting feedback and retrying? If so, it does for X10 what TCP does for unreliable networks: makes it fairly reliable, just requiring occasional repair. And therefore really cheap. Cheap enough that an automated lamp that merely lights a place reliably can cost $10-15, not $30-35, which means about 3x as many new lights on the same (purchase) budget, or 5x as many lights controlled on the same purchase budget - which can be controlled to save power, and therefore money, and break even quicker.

No, X10 does not support failure reports.. (at least not to my knowledge)
and even though the PLM Driver supports X10 2-way, that doesn't mean that X10 does..
All that means is that when an X10 command is transmitted across the powerline, the insteon PLM can hear it, and report that command to lmce.

I don't have any 2-way X10 devices, so I can't be sure if they transmit when they are controlled manually..

I do know there is a report status.. but I haven't implemented that (I need 2-way X10 devices)

Currently, the only X10 commands supported are ON/OFF.. but they ARE bidirectional..

If you send an X10 command from an X10 controller, then chances are, LMCE will hear that.

Maybe the X10 lamp modules can't send an ACK. But I wonder whether an entire room could have a lighting sensor that's calibrated to detect whether a lamp went on/off after a command was sent. I suppose in bright daylight, a failed "OFF" command might not be detected, but then probably it wouldn't matter (except the power draw, and in a hint of "bad style"). Maybe a power-draw sensor could detect the effects of the command, calibrating results in effect to results in power drawn. Again, if the increment in the sensor is undetectable within the noise error of the circuit (eg. a failed command to dim a 20W bulb by 1% can't be distinguished in a busy power circuit from some other load variance in some other connected device), then it's probably negligible in effect to the people in the room, too. If commands can be timed to wait for their feedback with some precision and accuracy, then maybe few (or even one) current sensor can detect whether a single command was effective in the following milliseconds, before sending another command.

Seems to me that LMCE can compensate for some of what makes X10 cheap, by increasing feedback and intelligence in the whole site LMCE is monitoring. Then more robust and expensive devices like Insteon can be used for more expensive and reliable operation of more complex device scenarios that can't afford to rely on compensation mechanisms. For example, if LMCE were feeding my baby or medicating my grandma, I'd want both Insteon and redundant feedback paths for confirmation.

I know this is a really "perfectionist" design. But you're doing so much, so fast, and apparently so well producing HA SW for LMCE, that I thought you might be interested in looking at the problem this way. And everyone can benefit from using cheaper equipment when it can perform as well as the expensive stuff. And especially when reducing the marginal cost of including all the cheap devices that fill homes and businesses into an LMCE scenario. And especially when you seem to like programming complicated technical problems into user simplicity .

[ddamron]

Hmmm... Let me get this straight..
You want to put a light sensor to see if the light went out..
How did you plan on interfacing the light sensor?

The main reason I implemented the X10 (honestly) was because Insteon does not have any PIR devices yet.. aka motion sensors..
X10 motion sensors are a dime a dozen, and for all intents and purposes, they work well.

It's kinda like running linuxmce on a 486... It probably can be done, but I wouldn't want to...

Don't get me wrong, I think X10 support is required... but after writing the bidi x10 in insteon, I can kinda see why they didn't make the cm11a bidirectional to begin with...

There is a major communication breakdown with x10.. when you turn on a light switch, the switch goes on, but the switch won't send anything..
They attempted to fix it with 2-way X10.. but again, it's a bandaid solution, that hasn't been documented very well..

Add to that X10's powerline problems.. needing repeaters, filters, phase couplers..
By the time you put 50 X10 devices in a location, you'll be so mad at yourself for not going with insteon to begin with.. costs of the filters / repeaters / phase coupler have to be worked into your pricing... and you don't know what filters or repeaters you'll need UNTIL you start installing them.  THEN, you need a meter to check signal strength..  work that into pricing..

Insteon takes a different aproach..it uses a simultaneous broadcast method to repeat signals.. and each device acts as a repeater..

Their broadcast method actually takes a situation others try to AVOID (simultaneous transmissions) and turned it into a strength!

Honestly, I wouldn't recommend X10 for anything but sensors / remote controls.. Their RF stuff is much better.. even though it is still 1-way, with remotes and sensors, that's all you need..

HTH,

Dan

[Matthew]

Hmmm... Let me get this straight..
You want to put a light sensor to see if the light went out..
How did you plan on interfacing the light sensor?

The main reason I implemented the X10 (honestly) was because Insteon does not have any PIR devices yet.. aka motion sensors..
X10 motion sensors are a dime a dozen, and for all intents and purposes, they work well.

It's kinda like running linuxmce on a 486... It probably can be done, but I wouldn't want to...

Don't get me wrong, I think X10 support is required... but after writing the bidi x10 in insteon, I can kinda see why they didn't make the cm11a bidirectional to begin with...

There is a major communication breakdown with x10.. when you turn on a light switch, the switch goes on, but the switch won't send anything..
They attempted to fix it with 2-way X10.. but again, it's a bandaid solution, that hasn't been documented very well..

Add to that X10's powerline problems.. needing repeaters, filters, phase couplers..
By the time you put 50 X10 devices in a location, you'll be so mad at yourself for not going with insteon to begin with.. costs of the filters / repeaters / phase coupler have to be worked into your pricing... and you don't know what filters or repeaters you'll need UNTIL you start installing them.  THEN, you need a meter to check signal strength..  work that into pricing..

Insteon takes a different aproach..it uses a simultaneous broadcast method to repeat signals.. and each device acts as a repeater..

Their broadcast method actually takes a situation others try to AVOID (simultaneous transmissions) and turned it into a strength!

Honestly, I wouldn't recommend X10 for anything but sensors / remote controls.. Their RF stuff is much better.. even though it is still 1-way, with remotes and sensors, that's all you need..

I appreciate all the real-world tested experience brought to bear on X10, which always seemed deceptively "simple". I figured that since it never got as popular as "the Clapper", it was probably a lot more complex out of the box than it looked, given its apparent power and American laziness .

What I had in mind was maybe an Insteon controller for a room, to support better hard switches (dimmers) and multiprotocol devices. But for the cheap lamps (and other cheap devices, like $20 radios, fans, etc) to be controlled by X10. So, AFAIK, the X10 traffic operates only within a single room. Which could even operate off some interlinked extension cords, so long as the junctures are X10 controllable instead of just a single X10 (or Insteon) controlling the entire downstream bank of lights. X10 is used to multiply the reach of LMCE (and maybe some Insteon), but only within a room where it seems acceptably reliable and simple.

I'm not sure I see what's wrong with an X10 light sensor to detect whether an X10 command to a light failed, for retry. Are the X10 light sensors failure prone, too, or expensive? If so, an Insteon light sensor, if it's <$50 or so, could serve a room's many lights, so account for only maybe $5-10 per lamp or less. The point is to get the per-lamp cost down to less than the $25 an Insteon costs. Is that doomed to failure?

[1audio]

X10 is an extremely old technology that had zero invested in it for most of its life. It never worked very well but lots were sold. I don't see any efforts towards new products on X10. X10 is one way, very noise sensitive and limited in what it can do. Its cheap but mostly because of its age and simplicity.

ZWave is getting cheaper fast. The next gen chip, 400 series, can make lighting modules in the X10 price range. And the communications for ZWave has been improved. You can get ZWave modules today for $35 from Homepro and Intermatic with some searching. Hopefully soon someone with get a current module working. The Leviton should be easy since its a serial interface. And it will support the full 2-way communications.

The Insteon technology is interesting and its not clear just how they are using it. The switches seem to be powerline only. The RF comes in with the phase coupler and remotes it seems.

UPB is a strong contender in this market with a similar feature set to Insteon without the wireless aspect.

A light sensor for feedback could work but may actually make the system unstable. If the ambient light is high enough it will not tell you if any lights are on. And it won't tell you which lights are on. plus it needs to be connected to the AC line to communicate. This is the strength of the Rf systems.

[ddamron]

I should also point out that there is a BUDGET SENSATIVE version of Insteon...

It's called the ICON series.. and tends to be about $10-20 cheaper than their full featured counterparts, while still supporting MOST of the protocol.  They are slightly different, certain models don't support certain features (like ramp rates)

This might be something to look at...
they're at www.smarthome.com

HTH,

Dan

[Matthew]

I should also point out that there is a BUDGET SENSATIVE version of Insteon...

It's called the ICON series.. and tends to be about $10-20 cheaper than their full featured counterparts, while still supporting MOST of the protocol.  They are slightly different, certain models don't support certain features (like ramp rates)

This might be something to look at...
they're at www.smarthome.com

Well, the cheapest lamp controller is the 2856D2B Icon Lamp Dimmer, which is what I mentioned as "competition" for the $4 X10 module in the post with which I started this topic.

Where does the unreliability of X10 modules executing sent commands come from? Is it inherent in X10, even on a perfect home power circuit? Or is it a function of low-quality power curves (noise, not sinusoidal, 0V/ground bias, etc), or phase changes by traversing circuits, etc, that could be eliminated by either good wiring/power (like when planning a new home)? Or by making a "new X10 network" out of only a few high-quality extension cords that have X10 modules where they join/split at each other, downstream from an Insteon "master" (and maybe a power conditioner)? If I can network a half-dozen X10 lamp controllers in a room for $5 each (plus the extension cords, and maybe a power conditioner), then the same budget can give me 5-6x as much precision in controlling individual lamps (another way consumers look at it is that a "$5-10" controlled lamp costs only $10-15, not $30-35). But if X10 is inherently flaky no matter how it's wired, even more than a light sensor and some smart feedback programming can compensate, then I'll just stop beating this dead horse.

[ddamron]

The unreliability in inherent with the protocol... not anything hardware based..
X10 was designed in the 70's... it was state of the art back then...
and even with a light sensor, it's a band-aid that will cost more...
I'm trying to figure out HOW you would add a light sensor, without adding MORE cost to the idea..
(and still come in cheaper than an ICON module)

You'd need a light sensor for each X10 device.. then an interface for said lighting sensors...

zwave? nah, that would bring you ABOVE the cost of Insteon...

hmm...

[Matthew]

The unreliability in inherent with the protocol... not anything hardware based..
X10 was designed in the 70's... it was state of the art back then...
and even with a light sensor, it's a band-aid that will cost more...
I'm trying to figure out HOW you would add a light sensor, without adding MORE cost to the idea..
(and still come in cheaper than an ICON module)

You'd need a light sensor for each X10 device.. then an interface for said lighting sensors...

If you send a command to each lamp, one at a time, and wait for the light sensor to confirm that the command was executed by comparing the command's expected effect (ie, the room got a little darker, or it got a little lighter, depending on the command) to the sensed effect, a single light sensor could serve several lamps in the entire room. If the sensor doesn't confirm the command, the sensor could be read again a few times to minimize the risk that the sensor, not the controller/command, is the feedback step that's failing. That means a probably <$20 X10 light sensor could give, say, 6 $5 lamp modules in a room at $50 something like the reliability of six Insteon lamp modules at $150. Even if the whole X10 room is also controlled by a single Insteon to improve the room's feedback, that's something like $75 instead of $150-175. For each room.

And the light sensor can be used for other features when it's not processing command feedback, like daylight detection. Or just offer a way to calibrate scenarios to actual light conditions, instead of blindly switching lights on/off, so the scenario can say "make the room X bright, using these lamps A, B, D, E, F in this proportion 1:2:1:1:2" (if dimmers are available), or other complex subjective effects that really control the room (and the mood).

All of which just depends on the logic being included in the automation SW that adds actual intelligence to the automation. If X10's limited reliability is still enough to support the feedback loop, then it could be both cheaper (or more precisely deployed, to more individual devices) and more effective than Insteon.

OTOH, even if it's not, I still like the idea of setting room brightness by actual sensed level, not just the guess of how bright the lights would make the room if several were turned on, which unevenly lights the room to a guessed average brightness. Even if X10 is too crude to make it work, the higher expense of Insteon support of control in those terms would probably still be worth the big bucks. And feedback is the way to control most devices, like say a heated pool (or bathtub) which shouldn't just be switched on, but rather heated until it reaches a sensed temperature (or a filled level). A general facility for automation that really makes it easy to use and a pleasure to live in.

[labrat68]

I have been using X10 devices since the mid 70's with no major issues. The power phase issue is trivial to over come. Some solution cost more than others. I for example used a cheap capacitor connected between the terminals on an electric stove or electric dryer.

Also with respect to other threads, I use a CM11a with multiple house codes - one for each floor. I have 2 CM11a's but to date have only used on I see no reason why 2 or more can not be used. Just don't program events form 2 cm11A to occur at the same time.

Ultimately I have interest in upgrading to insteon or zwave. But that will be awhile.

Hope this helps.

[Matthew]

I have been using X10 devices since the mid 70's with no major issues. The power phase issue is trivial to over come. Some solution cost more than others. I for example used a cheap capacitor connected between the terminals on an electric stove or electric dryer.

Also with respect to other threads, I use a CM11a with multiple house codes - one for each floor. I have 2 CM11a's but to date have only used on I see no reason why 2 or more can not be used. Just don't program events form 2 cm11A to occur at the same time.

So, do you think that my proposal to add "ACK" feedback to X10 light modules with an X10 light sensor would work?