Occupancy detection

Just a couple of points...

1. There's no reason to think the various motion detectors are saturating the RF environment. They only transmit for a very brief period (5 bursts that last about 65mS each) when triggered by motion so unless someone in the household is now constantly wandering about aimlessly (or purposefully, for that matter), RF activity attributable to the motion sensors should remain more or less the same over time. The decrease in range could be caused by any number of things - weaker batteries, higher humidity, temperature, etc.

1. The IR used >I came across the following article recently and began to wonder about the

I'm glad to see this getting attention, because motion activation of lights is definitely on the top of my list of things i'm not happy w/ about my automation installation. However, reliability doesn't seem to be the issue for me, what is an issue is the latency. Generally I have to carefully position the sensors so that just walking by the room (but not into it) doesn't trigger the light to come on, but this means that you have to take a step or two into the room before you are detected. Add to that the delay of the detector picking you up once you are in range, sending the signal, the tranceiver relaying the signal to the powerline, my PC picking up the signal, and my PC broadcasting a "hey turn on the kitchen lights" signal back down, and it takes at least 1-2 seconds before anything happens. (I relay through the PC so i can do more macro control such as only turning on lights when it's after dark).

Often this means walking into a dark room. I've actually subconsciously trained myself to walk into the room more slowly to ensure the lights have a chance to come on before i get too far and walk into something i can't see. I started on HA to make my house adapt to me, not to adapt myself to my house.

One thing i've considered to help the situation is a product I saw a while ago (sorry no link handy right now) which acts as a whole-house radio reciever and connects to your PC directly. This would eliminate the "sensors->transceiver->PC" leg of the trip and probably cut the response time in half. You still have the latency of being noticed by the sensor and the PLC lag time though. Incidentally this product has a "real" antenna and claims to boost reception ranges significantly. I'm sure Dave Houston knows what i'm talking about and knows whether those claims are valid.

I've considered going the route of individual hardwired motion sensor lightswitches like lutron makes which would no doubt operate faster than my x10 mechanism, but I really like having a central "brain" to my house and having the ability to set rules or be able to remotely control those lights independently if i need/want to.

The BX24-AHT (no longer available) and roZetta (not likely to become available for a few more months and then without internal RF) are based on the principal of centralized RF reception. It's fairly simple to design an efficient antenna (and add a wideband preamp, if needed) to get good RF reception (200' even with lots of metal and wire lath in the environment).

The only commercial device that I'm aware of is being sold in defiance of FCC testing requirements so I neither mention its name nor comment on its quality.

What I will try soon to again make available is a replacement PIC for the MR26 that allows it to report standard X-10, security X-10, CR14A (Ninja, Robocam), Chamberlain garage door sensor, Digimax 210 (European RF thermostat) as well as some protocols of my own for extended dims, preset dims, and ADC sensors. You can add an antenna (with preamp, if needed) and accomplish what you want as far as eliminating the powerline leg of the communications.

I will also try, in the next few weeks, to release a PIC and DIY design for direct RF input (standard & security X10) to the ADI family of controllers (CPU-XA, Ocelot, Leopard) for those who would like to eliminate the PC.

The RF range has decreased over time, and I did not mean to imply it's from the RF detectors "saturating" the environment. There are times in the morning now where the X-10 RF flat out doesn't work unless you put a Palmpad or keychain remote within a few feet of the transceiver. Whether these blackouts are caused by sunspots, military transmissions or whatever, I can't say. Without an RF meter it's just guesswork.

However, one doesn't need to know the cause to see the effects. They are pretty hard to ignore. When it happens, all the wireless thermometer displays either go blank or fail to update. That sort of unreliable environment makes occupancy and motion detection using the X-10 RF frequency unworkable, at least IMHO. The lax enforcement by the FCC tells me things will get worse and not better as more and more wireless gizmos make their way to market.

More importantly, the apparent lack of collision detection of the RF component of the "chain of command" means that if there's more than one person and one detector in the house, problems are bound to occur. I've tried all sorts of combinations of transceivers. The protocol's just not robust enough to support the task, at least in a house where there's fast motion of more than one occupant. When I lived alone, I recall being skeptical about all the problems people reported with multiple occupants and motion detectors. Not anymore!

That's good news. I was worried because I didn't think either the sun, CFL's or plasma TV's modulated a carrier or worked on the Powermid wavelengths but managed to trash IR distribution just the same. Like mercury in CFLs, I hate solving one problem by inducing others! I guess I'll plunk down some bucks and buy a few of the kits:

and see what's what. They're not very expensive. Thanks for the input, Dave.

-- Bobby G.

So just how close to the Naval Observatory are you?

Hi Bobby

How about using ultrasonic sensors such as the Maxbotix sensor.....

You can connect up to 4 of these to Gerrys board which reports each via a serial port......

HTH

Frank

Those are Velleman kits and I found schematics although I did not find any specs. If I remember how to calculate the frequency of an astable multivibrator, the carrier frequency should be in the neighborhood of 5kHz which should be OK with the Powermids but the acid test is to try one in case I misplaced the decimal.

There are newer motion detectors which make this easier and with a better WAF rating. Visonic makes SOY series motion detectors which are very small. The electronics are in a tiny cylinder which slips into a hole in the wall. The "eye" is a small, round head about 3/4" diameter. The detector can be ceiling or wall mounted, just inside the door to a room. If there is only one door to the room it is possible to use two detectors -- one inside and one outside to count occupants. That's a somewhat imprecise science but it can be made to work, especially if there are not a lot of people coming and going at the same time.

There are several models (SPY1, SPY2, SPY3 and SPY4) with different detection patterns. I have DIY customers using them to control lights, HVAC, etc. In one application a "curtain" pattern detects movement through a narrow plane of detection. The detector was turned 90º to make a layer of coverage about 2.5' above the floor. This is high enough to ignore the dogs but will trigger if a person the room.

Most hard-wired detectors can be set to respond in the first 1 or 2 footsteps into the protected area. Also, when automating little used rooms such as a pantry or closet, you can use simple magnetic sensors (called a "contacts" in the security trade) to detect the door being opened. These respond instantaneously.

That will add latency, no matter what kind of detectors you use. Have you considered a PC- connected system with separate, stand-alone alarm / automation controller?

Apparently too close. I also believe I am in a straight line path between two large military installations active in Homeland security work. From what I can see each has several huge towers with all sorts of different antennas pointed my way. Not sure what bands the transmit on or even if they are involved but the blackouts are becoming more and more frequent.

At first, I thought there was something wrong with the wireless thermometers and kept changing batteries only to find they hadn't run down more than half a volt. That's when I noticed the bathroom lights would misfire, despite the close proximity of the TM751 to the Hawkeye. I'd reset all the thermometers so that they had blank displays and when they finally refreshed, the RF "storm" seemed to be over. The bathroom light goes on and off nearly instantaneously when the RF skies are clear and becomes quite erratic when the thermometer displays "lock up." I can only assume it's a stronger signal drowning out the flea-powered devices like the Hawkeyes and the thermometer transponders.

For me, the really bothersome part of the problem is that in many, many cases, the darn things work just fine. You can hardly get more bang for your buck, especially if, like me, you got the X-10 gear with the vouchers they used to hand out like candy. To get to the next quantum level of reliability means you have to basically leave the X-10/RF world and go multiple sensor and hard wire or an use RF protocol that's two way with collision detection. Even so, my front tooth, my costochondral separation and my patella are working hard to convince me that near the Nation's Capital I might be wise to cut RF completely out of the loop if I want to maximize reliability.

I have *so* many Hawkeyes that I'd be willing to try hacking a few to disable the RF transmission feature and use their output to close contacts or otherwise act as sensors in a hard-wired system. Or I might decide that the X-10 RF component can act as a secondary or tertiary sensor in a multiple sensor setup, with the primary motion detector being the hardwired broken IR beam sensors. I like the beam because it's immune to all but leaping pets, flying bats and couples crossing the barrier "in flagrante delicto."

The problem becomes how to integrate the critical lights into the X-10 system while maintaining isolation from some of the typical X-10 problems of collisions, inadvertent activations and lost commands. I'd like to still be able to turn all the houselights out with a single button press but that feature makes the stairway lights vulnerable to someone pressing the ALL LIGHTS OFF switch while someone else is descending the stairs. The stairways lights should only respond to X-10 commands if no one is using the stairs.

-- Bobby G.

"Frank Mc Alinden" Hi Bobby

They look interesting. The problem for me, as I outlined in the note to Dave, is that going to the next level - seamlessly integrating non-X10 equipment into the existing setup is going to require a lot of work. I don't want anyone to be able to press ALL LIGHTS OFF in one part of the house while a person is descending the stairs in another.

Thanks for the URL!

-- Bobby G.

You need to learn how to program your CPU-XA/Ocelot for use with hardwired sensors.

If only it were that simple. This a primarily a reliability issue, at least for me, so there are a number of reasons not to use ADI gear. I don't want to knock ADI too hard because lots of people seem to use their equipment quite successfully. However, in this specific case, putting a novice ladder logic programmer (me!) who really dislikes unstructured languages like CMAX in as a "keyman" is NOT likely to enhance the system reliability index. (-: The few times I've worked with CMAX have been less than optimal and, in fact, very disappointing. I wanted to use the CPU-XA as an IR translator but the latency was completely unacceptable. To get good reads required changing operator behavior. In reading through their forum it turned out that reliable reads meant the user had to press buttons on the remote for at least 1 second. That had zero SAF.

If I were to struggle with CMAX and "drip down" ladder logic, all that would likely happen would be the reliability "demon" will simply move from the X-10 gear into my CMAX code. If I were to add a PC to the mix so that I could use a more structured language like HomeSeer, that would merely move the reliability demon to a Windows-based PC. But there are other reasons for me to find another solution. I just checked the ADI forum again and it's pretty clear the Ocelot line is on life support. Under new products there's only the one message and it's just a code update, not a new product:

New ADI Products --- As new products are released, we will spotlight them here. Posts=1 Threads=1

Release C-Max 2.00e3 / Executive 3.18 #189683 - 02/09/07 08:36 AM Changes: Daylight Savings Time Schedules changed for 2007 ASCII Bobcat RX Compare added (must use Version 8 or greater Bobcat) Fixed "Need to Load New Exec" message Fixed Manual TX Ascii Message for C-Max window bug

It's the same old crap but at least they are still patching the code! But they're also still listing meetings for 2005. When Dan Boone left, ADI's interests obviously went elsewhere. I had to embarrass the heck out of them to even get them to update their BBS, which was years out of date. I recall at the time being assured that new products were in the wings. That was two years ago. Still nothing.

Even though I own more than enough ADI gear to solve the problem, I'm unwilling to invest the considerable time in learning how to program a "throwback" language on a dying product line. I'd have to feel I had mastered CMAX to be assured the problem was solved. I'm guessing that it will take at least the same amount of time it took to learn FORTRAN or COBOL or Pascal or BASIC. I *had* to learn those to get my degree; there's no such motivation with CMAX.

I'll have to throw out most of what I learned about structured coding and embrace a programming language that's based on now-obsolete "ladders" of mechanical relays. Worse, still, it's a language that flies in the face of what I was taught were good coding techniques, which inevitably means "hard to maintain" even for the original coder. It's just too much effort to expend in order to solve a light switch problem that could, in all truth, be solved by either manually operating the switch or using a dedicated motion sensing light switch that can't be interfered with by X-10 demons.

But before I even begin to think about choosing a HW platform, good coding technique dictate I do a requirements analysis that fully describes what I want the system to do. The stairway problem breaks down fairly simply: Reliably sense entries and exits and occupancy via multiple sensors as well as motion and light output (so that I know if the light's burned out or really ON or OFF). Then I need to put the entries in a state table with some simple rules and act accordingly. It probably doesn't even need a microprocessor as the logic would be simple enough to implement with some TTL devices on a perf board once the proper inputs and outputs had been established.

I hope other CHA'ers can add their insight as to what that logic should look like. Ben P. and Frank have already given me some things to think about. By writing this message, I've come up with some of my own, including a provision for ALL LIGHTS OFF to be ignored in a occupied room if the command was fired remotely. That means no more shouts of "who turned off the lights!!!???" from my wife whom I have occasionally plunged into sudden darkness via an ALL OFF. The programming is beginning to show similarities to game code. Create a data structure of all the rooms in the house and increment and decrement counters as people move around. Too bad I can't program a "god mode" to turn clipping off that allows me to walk through walls like I can in Doom!

In any event, even if I were to go the microprocessor route to solve the problem, I'd probably opt for something newer and more powerful than the CPU-XA or Ocelot. Most critically, I would choose something that could be programmed in a higher-level language than CMAX without requiring a PC running 24/7. The Basic Stamp series looks interesting, as do a number of other controllers. The Maxbotic site

described some of the platforms people are using for their sensors (BasicX, BX24p, Basic Micro, Atom, Wright Hobbies DevBoard-M32, AVR using Bascom, Parallax, Basic Stamp BS2). Not one was an ADI platform. Learning how to program a newer, more powerful microprocessor would probably have payoffs in other areas of automation that will need microprocessor control. Ladder logic and leisure suits both had their day, but that day is gone, at least for me.

-- Bobby G.

Ahh! I didn't realize that your new residence was going to be a cave. ;) It will help with energy costs.

Ladder logic is used throughout industry worldwide. Its use probably outnumbers higher level languages by several orders of magnitude. Its day is far from done.

Comparing microcontrollers like those you've listed to ADI's system is comparing apples and orange groves. ADI uses an RS485 network with a protocol (published) of their own design. Expecting robotics hobbyists to use an Ocelot is rather ridiculous - it wasn't intended for that.

If you're going to try rolling your own, look at...

ZBasic - much more advanced than any of the stamp progeny you've listed BasCOM AVR - good mikroBasic - available for PICs, AVR. and other microcontrollers available in C, Pascal, Basic, ??? (still evolving)

There's even a stamp-like module that uses ladder logic...

I doubt that Jeff Volp will agree with your anti-ADI screed.

By "HW platform" I think that BobbyG is referring to a central processor or microcontroller and not the platform of sensor hardware (eg motion detectors).

An important step in system and sensor design is the decision of whether to create the Event of "Occupied = YES/NO" at the sensor itself or in a higher level processor. Or both.

An actual example of hardwire-based decision-making are dual technology motion/occupancy detectors that use both Passive Infrared (PIR) and microwave and only report an Event when both sensors are triggered.

Along the same lines, the outputs of two motion detectors in a room can be logically OR'd together or logically AND'd. The OR'd arrangement increases the risk of a false positive but decreases the risk of a missed occupancy. And vice-versa for the AND'd configuration. Sending the uninterpreted ON-OFF Event data from _both_ sensors to a processor for decision-making provides for better risk and error management.

Event 1 Detector_1 Only Event 2 Detector_2 only Event 3 Detectors 1 and 2 Both raw Another example is/was the use of what Savoy dubbed "Motion Vectors" in the CyberHouse software released ca 1998 which used the time relationship between "ON" events reported by two motion detectors monitoring two different contiguous locations to create Motion Vector Events (eg: 'Motion to north in Hallway"; "Motion to south in Hallway"). The latency problems of X-10 made useful implementation difficult/impossible even with hard-wired motion detectors.

The hardwired THOL (Temperature, Humidity, Occupancy, Lightlevel) system I designed and am installing can be used with multiple motion detectors at a single measurement site so as to be able to create a Motion Vector Event in hardware in real time as well as pass on the raw, uninterpreted sensor data.

The data and the events are combined into a single 0-10vdc analog level which in turn can be treated downstream as a single event by defining the event threshold analog voltage or as a series of readings of the different sensor or both. More than one downstream processor can receive, interpret, store and(or) act on the data, so different processors can have different responsibilities.

Continuing with my THOL example of Occupancy, a single commercial PIR detector simply toggles the output between two voltages (typically 0 and

10vdc but they could be any two values between 0 and 10vdc) when the contact of its internal relay closes.

Contact closure of each motion detector in an array of n detectors can short out a different resistor in a conventional R-2R resistance ladder and so create a unique 0-10vdc value for each of the possible 2^n outcomes.

Adding a simple PIC or AVR can add interpreted outcomes (= Events) based on timing, IOW, Motion Vectors. The practical number of different states that can be reported by an analog signal depends on ADC resolution and precision and system noise among other factors. Reporting independently the five different Y/N states requires 2^5 = 32 different values. This is easily handled by a 10-bit ADC (1024 possible values) in a system with sufficiently low noise and stability.

Bit 5 Motion South Bit 4 Motion North Bit 3 Motion Detector_1 Bit 2 Motion Detector_2 Bit 1 Motion Detector_3

Note that Bits 1-3 are raw sensor data. Bits 4-5 are interpreted data.

So by logging the analog voltage one is logging both all the raw data and the Motion Vector events interpreted by the on-site hardware.

These discrete events could be usefully lumped together to create fewer combinations of possibilities that impose less stringent demands on the analog hardware and communication. For example by reporting exclusively only _one_ of these six Events

Event 1 = Motion South Three Detectors = 8.volts Event 2 = Motion North Three Detectors = 7 volts Event 3 = Motion North Two Detectors = 6 volts Event 4 = Motion South Two Detectors = 5 volts Event 5 = Any Two Detectors = 4 volt Event 6 = Only One Detector = 2 volts No Event= No motion < 1 volt

at the receiving (downstream) end one can more easily use analog comparators or TTL/CMOS PICs or AVRs or a simple LM3914 Dot Display driver to physically create a discrete electrical signal in the form of a contact closure or TTL signal for the event.

2 volts would imply low certainty with no perceived motion. 4-6 volts moderate certainty A voltage > 7 volts would imply high certainty, etc.

With flawless event definition, "simple rules" might work well most of the time for many actions.

This is a classic GIGO situation. A CPU or MCU processor can help to filter the data in a way that "simple" rules" can't and to create infrequently enacted rules that might be very important but might not find their way into a system based entirely on discrete logic ICs.

A fully hardwired TTL approach also mostly forces definition of the event of "occupied" beforehand and essentially eliminates any stochastic evaluation or risk analysis and their use in determining actions. Stupid machines make stupid mistakes.

Also, IIRC, in previous posts wrt temperature and HVAC BobbyG expressed an interest in data storage. How does one do this efficiently with TTL's alone? A hardwired TTL circuit might have a place in the system if (especially) there are other devices that also translate, use and act on the data.

(FWIW, making one-off PCBs has become relatively easy, fast and inexpensive. And for non-RF prototypes, solderless breadboards work fine. Perf-boards for TTL are fragile and error-prone IME.)

... Marc Marc_F_Hult

I checked Dave's web site and all the documentation needed binary and other files to make PCBs and program the BX24-AHT are still here at

.

The pcb's are still listed as in stock and available here:

I have a couple unused pcb's that I can add to my Home Automation and Electronics porch sale at

Perhaps what Dave means is that he has effectively withdrawn permission. Many of the files are marked " Copyright. No part may be reproduced except by [italic] written [/italic] permission. This restriction extends to reproduction in all media." Makes them purty hard to use ...

Dave refers to the WGL designs W800RF32 family of RF receivers

competed with his device when parts for his were being sold by Dave's family and fully assembled by Laser. WGL is supported by at least 17 different home automation programs. Dave pulled the plug on the BX24-AHT ca

2004 after his family shut down the supply web site without warning and Dave lost control of the Yahoo groups BX24-AHT forum.

There are, as Dave doubtless knows, other centralized RF reception systems out there.

Check out, for example, RFXCOM

available from in the US who also distribute CheaperRFID.

RFXCOM supports X10, Oregon Scientific, Visonic, KlikOn-KlikOff, ELRO, NEXA, Domia Lite, ATI Remote Wonder. The RFXMeteis a modular utility metering device with RFXPwr for power usage metering. RFXSensors reportedly include RF transmitters for 1-Wire® temperature, humidity and barometric pressure sensors. Also reported available are external sensors for temperature, humidity, barometric pressure and A/D input 0-10V DC.

Then there's the new HomeSeer HSM100 Z-Wave multi-sensor

that opens new possibilities for lag-free response of automated lighting to motion sensors. (I previously posted about this in this newsgroup.)

Quoting the HomeSeer web site:

"The new device is designed to sense motion, temperature and light and home owners can use the HSM100 to control up to 4 other Z-Wave devices directly. Those with HomeSeer-equipped homes can also use the HSM100 to trigger more complex automation events for whole house control of Z-Wave and non Z-Wave automation products."

... Marc Marc_F_Hult

It's definitely at the top of my list after I ended up at the bottom of my stairs!

My fall was caused by precisely by the latency problem. I came home and heard the sounds of a dog yelping piteously in the basement. The stair light latency was fast enough for normal speed but not for full military thrust. I recall as I hit mid-stairs (about where the light from the kitchen peters out) thinking "Hmm - the light wasn't coming on and that I couldn't see where I was going and that I was going there very quickly!"

I missed the last step and sailed into a shelving unit that brought an old PC crashing down on me. I cracked a rib and a front tooth. Turns out the dog had gotten her jaw stuck in the crate wire wall trying to reach a Nylabone that had fallen out. I've known people who died in stairway falls, so when I finally came to a rest *without* a broken neck I considered myself one lucky dude, even with all the injuries and damage. A little bending of the crate "bars" unhooked her lower jaw and I went off the ER. That's when I decided to return to manual switching for the basement stairs until I could do something better.

I mount mine about two feet inboard of the doorway pointed across the door opening. They're blind to pass-by traffic but react quickly when someone passes through the doorway.

To me that's just too long. It's barely acceptable in non-emergency situations but not if you're really moving. Since I know now that's a possibility, I've got to either implement a faster and more reliable system (no PC involved, I'm afraid) or go back to manual switches. A system that's capable of making a crisis situation worse won't do it for me, not after the fall.

Sounds very familiar. The X-10 Hawkeyes were a fine start in selling me on the idea of automating lights based on motion detection. But now the time has come for more than simple "on/off based on motion" control. Large stores have triple-redundant opening and closing mechanisms because they've been sued so many times they need the additional reliability. If that's where the "state of the art" is, then using just PIR via RF via PC via PLC is way far behind. The light control, at least for dangerous areas like stairwells, needs to be as close to instantaneous as possible. I believe that presents just too great a hurdle for X-10 to reliably pass, even with the tremendous boost in reliability that Jeff's XTBs have given my system.

The problem, as I see it, is that I still want that light under X-10 control. The reality might just be that in order to do what I want, the emergency lighting might well have to be "off the grid" as far as X-10 is concerned. Since a broadcast storm can knock out critical X-10 lightning, I'm thinking more and more stairway and other critical lights have to have an independent control mechanism that's completely immune to any known X-10 problems.

I didn't think about it until you mentioned it, but I, too, had conditioned myself to walk more slowly when I knew I was in the view of the PIR sensor. That's an OK solution until there's a problem and you're rushing to respond quickly. Ironic, isn't it, that we've both adapted to the limitations of the hardware instead of the other way around! I think that's because the first step has been made very easy by X-10. It takes only 10 minutes to set up a fairly sophisticated motion/light control system. It's the next step - improving latency and reliability - that will take a lot of customized work.

I think that's the WGL "whole house" transceiver, and indeed I acquired two products very much like it, but both were unsuccessful. I live in a wire and lathe plaster wall house with lots of steel shelving and other impediments to RF. There was no single place to locate an all-housecode transceiver that could "hear" all the transmitters. That situation bred a whole load of other problems. Collisions from competing transceivers was the biggest problem. Sometimes the light wouldn't trigger, other times the wrong light would. The worst instance caused a light to flash on and then off when you entered a controlled room.

While it may be working well for you, the bottom line for my situation is that PIR via RF just isn't reliable or fast enough. That's why I was looking at "beam break" units. I can't imagine going through a doorway so fast that a detector wouldn't "see" the break in the light beam transmission. For that reason alone, IR beams seem to me the most reliable of the detection options within a hobbyist's price range.

I agree. What I want is a system that senses motion and occupancy, processes that information quickly and reliably, stores the information for future analysis, and exercises some "common sense" when turning lights on or off. Turning a light OFF when the system "knows" that there's still a person on the stairs lit by that light should be close to impossible. That's why I've become interested in floor mat sensors, IR "beam break" sensors, PIR's, microwave, ultrasonic and anything else that can help solve the problems associated with X-10 PIR controlled lighting. As I see it, the system should be heavily biased toward NOT turning out stairway lights until there's a preponderance of evidence indicating that there's no one on or even near the stairs.

X-10 and the Hawkeyes were a good start, and I learned an awful lot about the "real world" problems of occupancy and motion detection for very little money. But the time has come for a better, more reliable, faster and smarter solution. Or a return to manual light switches!

-- Bobby G.

But just how likely is that to happen? That and any motion sensor would trip again on seeing motion and turn the like back on. What's going to happen faster? Controlling 'All Off' but keeping exceptions for currently detected motion cannot be accomplished at the device level. It would require a computer (dedicated PC or whatever) and intercepting the 'All Off' functions entirely. This may be a bigger problem as the 'All off' function is usually directly sent from controls to devices and can't be easily disregarded. If keypads that had 'All off' functionality had the ability to reprogram the housecode for just that key then it might work. But none offer this, they only allow one housecode for all buttons, not individually. You'd have to change the housecode and use a PC to intercept and retransmit all keypresses, not just the 'All off'. This adds an unacceptable delay as the commands have to get sent twice. They're already 'slow enough' from the keypads directly to the devices. Adding a PC into the loop will definitely be a WAF problem.

I'd consider adding logic on a PC that tracked motion sensor status and IF an 'All off' was detected that signals be sent to immediately bring those lights back on. But with a timer that monitored for any additional motion detection. As in, the stairs sensed motion, an 'all off' was detected, turn the stairs back on and wait X period of time to see if any other motion was detected, if not, turn the stairs back off again.

I'm guessing it'd be far too much work trying to come up with a "fix" to a relatively unlikely or infrequent scenario.

-Bill Kearney

The cost of X-10 wrt oft-needed trouble shooting is well documented. Your accident was apparently yet another cost.

I recently installed INSTEON RF and have experienced what INST[antly]ON means. I can perceive no lag whatever between the time that I press the button on the hand-held RF remote and the light or scene-full of lights are on at full brightness.

Yup ;-)

One of the virtues of the 'retro' 0-10vdc analog control system I've adopted is that the control signal can be used to dim low-voltage (nominal 12vdc) lighting powered from the same central bank of batteries that provides DC power to the PC's, distribution audio and HA hardware. So in the case of a power outage, there is no switch over to a UPS -- things, including the low-voltage track lighting, just keep on running. And because it is hardwired, it enjoys the intrinsic dependability of that communication mode.

The kitchen and music room ceilings have been wired and the low-voltage track light installed in the kitchen. Under normal conditions they will serve as task lighting, ambience/highlighting including artwork. They are powered by

24vdc IN --> variable 0-12vdc OUT power supplies that are controlled by either DMX512 or a 0-10vdc signal. These are inexpensively purchased, surplus, commercial DMX dimmers that in their previous life controlled lights on a floating animated barge in Disney World.

Many of us have found that the amusement and benefits we got from X-10 sometimes verged on the masochistic. I don't play hockey or indulge in X-10 any more but have scars from both ...

With INSTEON RF, you can put an RF receiver in each room and they communicate over the power lines. No setup is required. Jist plug em in and the inter-room communication problems go away because transmission through walls is not required. And no "single place" for a transmitter is needed.

And there are other RF systems that use multiple receivers whose output is combined by a central PC. Homeseer supports at least one such system that supports multiple brands of X-10-capable transceivers. See my previous post.

Some folks are conditioned to what BobbyG writes in the sentence above because their previous experiences were with X-10 especially MS12a's /Hawkeyes and their successors that use a single LHi954 or LHi958 PIR detector that was designed ~15 years ago!.

Things have progressed in the detector arena. And RF *is* intrinsically fast enough (although relayed X-10 RF demonstrably isn't) with actual HA RF systems for sale that are reliable 'enough' for many folks. Lutron RA, Z-Wave and Zigbee come to mind. And Real Soon Now -- we can hope -- INSTEON.

The motion detector that most often falses in our house is a commercially installed beam break. Not a panacea at least in our case.

INSTEON dimmers, whether or not they are being used by an automated system, look and feel and act just like manual dimmer switches. So they could simply be "abandoned in place" if one wanted to "return to manual light switches". This that cannot be said for low-cost X-10. And at

The problem stems from a work-around for the low bandwidth of X-10 and the original lack of scenes downloaded to dimmers and other devices. What was a nifty feature when first introduced is now a liability.

For X-10, one 'solution' is abandon the All ON/OFF command by moving all devices off the affected house code. Whether one can mitigate the resulting increased lag and decreased relibility when one wants to turn on all Lights ON or OFF at once depends in part on how many switches one is willing to replace with expensive X-10 switches that support scenes.

ABIK, neither the table-top or wall-mounted wired keypads or RF INSTEON control pads have a _global_ ALL ON/OFF although one could program a key as a global ALL instruction without having to use a PC to execute it. The ALL commands that are on the RF pad sends instructions only to the six _sets_ of devices programmed in the pad but those could be all the devices in the house if one chose.

... Marc _F_Hult