XTB - the Future of X10 has arrived!

Good point. I suppose that the exit of all the above (except Ratshack) indicates the patent was stronger than the underlying technology!

-- Bobby G.

Or that the market was too small to sustain their interest.

Well, you'll soon see my XTB review. Jeff shipped my units this morning and I'll have them by the weekend. I ordered one assembled and one kit - I enjoy kit building but not enough to do two. I should point out, regarding the bandwidth/macros comments, that when I was using only X10 my macros executed flawlwessly 99% the time. It was the increasing number of trouble spots where X10 wouldn't penetrate that drove me to add Insteon. Now my macros have delays because the Insteon translator is listening to X10 signals and send ing Insteon signals. In a macro Insteon is sending on top of the TW523's X10 signals which causes problems.

The motion sensor is an rms18. There are actually two. I don't think it's ever possible for both to see me at the same time. The transceiver is an rr501. The computer is connected to a cm11a.

I haven't figured out a good way to accurately time the delay when I walk in the room. Right now, just looking at a watch as I enter the room, I'm seeing about 4 seconds after I pass the first sensor before I see light. In the MH log, I'm seeing the computer recognizing the MS and turning on the light either the same second or the following second. The timer resolution shown in the log is only a second. Not sure if I can get it to show finer resolution than that, but I'm not sure that's necessary anyway. It clearly takes less than a second between the time the computer sees the signal on the power line and responds. Hmm, I just added something else to the log. It was printing to the log that it was turning the light on and then sending the command to the cm11a. So I added a print statement after the ON command in case the delay was in executing that. What I'm generally seeing now is MisterHouse sees the signal from the MS, reports that it's going to turn on the light and then that it has turned on the light all within the same second.

So, the computer/software shouldn't be the delay. Unless there's some oddity in the cm11a driver MH is using. I suppose it's possible that the main MH program hands the command off to a driver that then sits on it. I'm not familiar at all with MH internals, so I don't know how it's handling that. I'll have to post some of this to the MH mailing list if no one here has a good answer for me.

This is correct.

How can I do this without a transceiver? It sounds like your modified MR26A will do this, but I'm confused. (And it sounds like that isn't available at the moment anyway.)

I have an ESM1. I'll have to play with it later and see if I can find any more clues. I've only used it so far to see if signlas were reaching their destinations. I haven't tried watching it along with the laptop to time stuff.

Thanks for the ideas. any more suggestions will be great. I'll play more later.

I agree that was a factor, but I think there had to be more to it than that. So *many* companies, one after the other, got in and got out that it leads me to believe support costs and issues were more than they ever expected. After all, X-10 doesn't tell end users that there are grave potential problems, why should they have behaved differently towards those making OEM deals with them.

As and end-user I profited from nearly every abandonment because stores sold that remaindered gear at less than half price - sometimes far less.

-- Bobby G.

-- Bobby G.

Sure. The basic "problem" is that when I walk into my laundry/utility room with my arms full, I want the lights to turn on via motion sensors. There's about a 4 second delay before the lights come on. It's not a serious problem. I just take a few steps in the dark knowing the lights will kick on. I'm just trying to figure out why it's taking so long. It hasn't bothered me enough to remove the motion sensors, but I find it somewhat irritating. I just want a faster response. I could add another sensor at the top of the stairs so by the time I get down to the basement the light in the other room is already on. But that isn't identifying the source of the delay. That's just working around it, and not efficiently since I might not be going into the utility room. (If I'm not carrying laundry or a lot of tools, I can flip a light switch easily, so I haven't added more motion controlled lights in other areas.)

Here are the details:

The motion sensor is an rms18. There are actually two. I don't think it's ever possible for both to see me at the same time. The transceiver is an rr501. The computer is connected to a cm11a.

I haven't figured out a good way to accurately time the delay when I walk in the room. Right now, just looking at a watch as I enter the room, I'm seeing about 4 seconds after I pass the first sensor before I see light. In the MH log, I'm seeing the computer recognizing the MS and turning on the light either the same second or the following second. The timer resolution shown in the log is only a second. Not sure if I can get it to show finer resolution than that, but I'm not sure that's necessary anyway. It clearly takes less than a second between the time the computer sees the signal on the power line and responds. Hmm, I just added something else to the log. It was printing to the log that it was turning the light on and then sending the command to the cm11a. So I added a print statement after the ON command in case the delay was in executing that. What I'm generally seeing now is MisterHouse sees the signal from the MS, reports that it's going to turn on the light and then that it has turned on the light all within the same second.

So, the computer/software shouldn't be the delay. Unless there's some oddity in the cm11a driver MH is using. I suppose it's possible that the main MH program hands the command off to a driver that then sits on it. I'm not familiar at all with MH internals, so I don't know how it's handling that. I'll have to post some of this to the MH mailing list if no one here has a good answer for me.

Motion sensors sometimes are slow responding to movement. The response time is hard to determine.

IIRC, the RR501 waits until it sees the start of the next RF code before sending to the powerline. This takes about 108mS. If the signal is a little weak, the RR501 will use the first (or subsequent) copy (or copies) to set its threshold. Each copy takes ~108mS.

It takes 94 half cycles of 60Hz for two PLC copies of two X-10 codes. (e.g. A1, AON) The CM11A will wait for both copies plus ????. This takes at least

Mr. House interprets the incoming code and sends the macro it triggers. There's some handshaking with the CM11A before it transmits. It then takes the same number of powerline half cycles to sent two copies of two codes. (e.g. B1, BON)

Watching your ESM1 may give you a picture of when the delays occur.

The simplest way to speed things up is to have the RR501 turn on the light and have Mr. House merely log the activity.

If it's any consolation, the problem of accumulated delays in motion sensing and its application to smart lighting control is not confined to X-10. Your application is simple one, consisting in turning on a single light in response to a single motion detector which requires minimal smarts and so Dave's simple fix may suffice. ( Another fall-back which may be even more dependable may be to use a switch with a built-in sensor and eschew centralized HA altogether. )

Cyberhouse software (and ABIK, Crestron, AMX, Lutron, I think now Homeseer and doubtless others. See eg

To my dismay 6-7 years ago when I first tried to implement this, Napco's popular (among the DIY HA crowd) hard-wired security system was not 'fast enough' owing to limitations in the speed at which sensed events are reported over the RS-232 connection (and/or replicated on external relays). The long-contemplated solution is to use a dedicated hard-wired controller such as ELK M1 or homebrew PC/PIC/Atmel. In any case, X10 lighting is useful only under very limited circumstances because of bandwidth limitations intrinsic to the protocol - a limitation that is separate from signal strength and reliability issues that get most of the attention.

... Marc Marc_F_Hult

I agree. I suspect that Larry's put all his motion detectors on an unused housecode. Lots of people do it that way but it induces delays in getting from detected motion to turned on light.

I've found that the only way that X-10's MDs are acceptable is to have them directly control the load.

Is there any difference in which unit gets a command on the line more quickly? Or do the TM751 and the RR501 activate the light directly at pretty much the same instant?

If you mix RR501's and TM751's together, will the RR501's always fire last because of the collision avoidance feature? That seems to be the case when I operate both side by side on a power strip and if that's true, I can use that behavior to figure out whether there's a TM or an RR type transceiver buried in the Robodog without having to open it up and risk killing it. Is there anything a DIY'er can do with some eunuch TM751's that didn't survive their antenna enhancement experiments?

I'm about to switch over my X-10 topology from a collection of TM751's to your BX-AHT with a centrally located antenna and an XTB turbobooster. It wasn't practical for me to use the BX-AHT before this because of all the PLC issues in my house. The signal just wouldn't reach everywhere from the TW523.

Are there any X-10 motion detectors that put detected motion directly on the powerline other than the floodlight module? Naturally they'd be powered by line voltage. I'm tired of chasing batteries.

-- Bobby G.

Why is the CM11A in the loop? Are you using any logic to determine what to do *before* executing the ON LIGHT command? As Dave suggests, the best way to do this is with a TM751 or RR501 as close to the target area and lamp (and on the same circuit, if practical) directly driving the load. Keep the MD to transceiver distance short, keep the load and the transceiver distance short. That will maximize the chance the light will turn on right away. Are you logging this activity to a printer or disk? Try turning that off and seeing whether the delay disappears.

-- Bobby G.

There's nothing that a solder-averse individual can do with the mangled TM751. For someone who can solder, it's possible to put a small 1:1 SMT isolation transformer in the antenna circuit and use an efficient external antenna. But, this isn't really worth the effort as the TM751 is not all that good even with a better antenna.

When you have the BX24-AHT working, you can probably get rid of all of your other transceivers. If using a CM11A with the BX24-AHT, it will stop sending as soon as it detects a collision so, if you do retain other transceivers, it will not add to the chaos.

You can program the BX24-AHT to respond (or ignore) the RF from the motion detectors. With a CM11A, it's about the same speed as MS -> RR501 -> PLC. You can also tell it to ignore some RF to avoid clogging the powerline with superfluous traffic.

If you want better motion detection, use the X-10 security motion detector. I've found it to be several orders of magnitude more reliable that the EagleEye or HawkEye. I've had one for 4-5 years and am still on the initial battery. The BX24-AHT will also report RF from the door/window switches.

One of theses days I will adapt the PIC I programmed as a generic ADC RF input node to use the transmitter in the door/window switch. Jeff Volp suggested doing something similar with an EagleEye or Hawkeye but I think the door/window switches are better for this. They're about $10 each in a

BTW, my plans to port the AHT code to the ZX-24 are >> and have Mr. House merely log the activity.

That's an interesting point and certainly a pathway a number of people have taken. I find it makes me uncomfortable to have such a situation because almost always you want to be able to control the light in a context other than detected motion. The X-10 stuff is quick enough if you position the sensor and transceiver close to each other and close to the load.

Before I did that, the RF or PLC commands might not always get through and that means either waiting until the PIR circuitry "looks" again (several seconds) or reaching for the manual switch. The time that it takes to react, reach for the manual switch and hit it coincidentally is nearly equal the time it takes for the second PIR scan to occur. Often, the user ends up hitting the switch a millisecond or two after the 2nd PIR scan has turned the lamp on and, you guessed it, the user actually turns the lamp out.

That's an area where X-10 breaks down. With multiple occupants in motion, there are bound to be collisions. Such a situation requires a higher bandwidth to avoid such problems. That's probably where I would switch to hardwiring. Since I currently use TM751's spread throughout the house with one near every controlled load and almost all a room away from each other, it's worked out nicely.

What I need now is a "PIB" (Person(s) in Bed) detector that can reliably tell me when either one, none or both of us is in bed. A sleeping/awake detector would be nice, too! I want to automate phone muting, security arming and a bunch of other things predicated on whether we've gone to bed for the night. As a corollary I'd need a travel detector that could also tell me whether a single person in bed or no persons in bed was a normal condition for that day. My wife often works the swing shift, so there's no really fixed bedtimes around here.

As you noted in an earlier message, home automation really has a long way to go in terms of knowing detailed information about the home environment and putting that information towards high level decision making.

As you noted, so many of these have interlink issues that come about from RS232 or other comm delays. If there's one area in HA where speed is of the essence, it's in the automation of lights. My wife really enjoys the hands-free aspects of PIR switched lights for the laundry room and bathroom, but ONLY when they work without delay or "futzing."

Yeah, that!

Oddly enough, there are two areas where X-10 is able to overcome bandwidth limitations that still make it very, very useful. Those are the "ALL LIGHTS ON" and "ALL UNITS OFF" commands. You can command 16 units simultaneously with one keypress. You can also stack commands which, at least on the maxi controller and that allows all the commanded lights, even with different unit codes, to go on and off simultaneously.

I would have preferred they had chosen "ALL LIGHTS OFF" on the Maxi controllers - it never made much sense to have two not quite parallel commands next to the very parallel "ON/OFF" and "BRIGHT/DIM" keys. But I agree, overall, that bandwidth is the only monster left in my X-10 setup with the XTB in place, boosting the signal. I've avoided long macros as a result, but that's been more limiting than I like.

-- Bobby G.

No need to be so defensive ...

I've order one of Jeff's nifty X-10 amplifiers (sensu stricto) because it will neatly allow me to keep a couple of X-10 switches in service where running a neutral wire for INSTEON or low-voltage for hard-wired lighting is not worth the effort at this time. But I rather doubt that this is gonna solve the "fundamentals of how [I] live and work" as you wrote in your first post of the thread.

To continue the alternative automotive power analogy used elsewhere in this thread, when I bought our family's shiny, brannew 1980 Dasher diesel wagon in 1980, it was wunnerful in part because it got 50 mpg. But when in 1993 I bought a second, used one, identical except for color, for spare parts to help keep the first one alive, I didn't gush that others would/should follow the same path. Because just as X-10 switches -- amplifier or not -- are still tactile mush, slow to respond relative to newer devices, more easily confused by multiple commands, add noise to the powerline, have poor hash suppression, etc etc, my then 13-year-old Dasher model was way long in the tooth and superseded by better cars for less money.

Similarly, I still ride my 1972 Motobecane 10-speed bicycle most days. The light, purty new front wheel I recently treated it to cost bout as much as the whole bike did when new, but I don't recommend 1972 Motobecanes because [ add list of good reasons here]. If someone asked, me, I'd tell them to buy a new bike.

Thanks for your (many, many! ;-) words and bon mots in this newsgroup.

... Marc Marc_F_Hult

The X-10 stuff is quick enough if you position the

In my experience, X-10 is almost never quick enough if the system needs to dim instead of toggle ON-OFF. And if you get up at 3AM , who wants the lights to go on suddenly at 100% bright?

Or worse, the infamous X-10 Flash! followed by the slow excruciating, erratic dim that may or may not follow. Bleach out the eye's rhodopsin with the first Flash! and then dim so that you couldn't see even if you

Methinks you want this to work so badly that you don't see how badly it usually works ...

... Marc Marc_F_Hult

I would liken the XTB as to what the military used to (and may still) call a SLEP, or "Service Life Enhancement Program." The pilots flying B-52s are (a lot) younger than their aircraft but SLEPs have kept them flying for many years beyond their planned retirement (the B-52s - not the pilots!). The 52 year old B-52's may not be as technologically sophisticated as newer stealth bombers but they do serve their purpose.

I view the the XTB as a SLEP that may enable one to squeeze a few more years out of their existing X10 installations. It is particularly timely in that we are in the midst of a shakeout period of competing technologies where delaying commitment to one or another may be beneficial to those who have a working X10 system and can wait a bit longer.

As I've said in earlier posts, the $1000+ I've spent converting to Insteon has yet to yield any real benefit over X10, although I think that will change when I have a RoZetta in the mix. In the meantime, Insteon allows me to hedge my bet by acting as X10 devices too - I don't have to reinstall the old stuff. If the XTB works as well for me as reported by others I'll have the best of both worlds: X10 commands sent from my "legacy" controller will reach everywhere they need to for reliable scheduled control AND, I'll have reliable manual control from Insteon controllers, keypads and switches using the Insteon linking technology.

Excellent characterization.

Yes, but it is also useful IMO to consider the relationship of existing technologies/oncepts/strategies with emerging ones as complementary rather than primarily competitive. It is also helpful to the all technologies to candidly assess SWOT's (Strengths, Weaknesses, Opportunities and Threats). IMO, this is one of the recurring issues with some conversations in c.h.a .

-- namely the need for partisan identification and endorsement 'winners' at the expense of accuracy and completeness and refraining from hyperbole.

What did you convert from? Folks migrating from a couple of dozen x10 WS467 wall switches to a like number of $19.99 INSTEON wall switches will both find it hard to spend anything like $2000 and will enjoy immediate payback in terms of tactile response, visual aesthetics, possibly better hash filtering ( still working to quantify this), probably longevity of the hardware (my WS 467's fail with appalling regularity) freedom from interdevice interference, lack of start -up flash when dimming, more accurate dim levels, ability to logically gang switches and so on. I have at least of each of the available INSTEON switches and dimmers and am hard-pressed to find a reason to buy the $40 switches and dimmers instead of the $20 ones.

My turn to fix a finger-fault before the dreaded ruler comes down on said fingers: Should be "bons mots".

... Marc Marc_F_Hult www.ECOntrol.ora

You wouldn't want to be either one of them when they got angry.

technologies where delaying commitment to one or another may be

I suppose I was a bit effusive in my praise but the XTB came at a time when my family's facing some pretty serious price increases all across the board, from gas to electricity to food to insurance and even property taxes. Having something like the XTB allows me to spend $200 instead of $2K to solve the majority of my X-10 problems. That translates into a very nice weekend getaway and that's got a lot of SAF. Learning all new ways of doing the same old things has very low SAF. I know how much my wife dislikes changing PC's, SW, cars, home theater equipment, light switches and TV/VCRs. And car tires. :-)

So the XTB allows me to extend the current interface for a few more years, at least. And to avoid what I lovingly refer to as the "stinkeye" when something's gone so amuck that damage has occured. That's got a lot of "blue sky" value for me. X-10 is the devil you know . . .

Insteon allows me to hedge my bet by acting as X10 devices too - I don't

That's a pretty useful feature, as it turns out for you.

If the XTB works as well for me as

May the Force be with you!

-- Bobby G.

Check 8 doors, once every second sample room temmperatures of 15 rooms, once every 5 minutes control 5 dampers, also at 5 minutes.

I dunno, I'm just making stuff up. However, when you've got a 2 ghz processor instead of a 50 line/second BASIC interpreter, you're going to come up with more stuff.