SteveRF, I don't know the answer to your
question (re: listen before sending RF). In
the use I've made of this feature, it hasn't
been an issue, but the frequency of events
using it in my environment is much less than
what the other RF sources like motion
detectors generate.
My philosophy with regard to using X10 is
to expect the occasional screwups in
execution since they seem to be impossible to
prevent. The only thing I won't tolerate is
going on vacation and having the house dark
at night while I'm gone, so I've gone the
redundancy route to minimize this.
Given a couple of relatively stable CM15a's,
the ability for them to poke each other
periodically on a scheduled basis allows some
interesting options aside from sharing work--
like notification if one of them has silently
died, or if the clocks have drifted beyond a
predetermined interval. I've also had fun
configuring macros that determine if key
lights actually have turned on as expected
and turn on another lamp if needed to recover
(by scheduling an event to expect the trigger
of an interior eagle eye's light sensor-- it
makes a good 'dead bulb' detector, and I
don't have any 2way modules).
I've run into a few 'gotchas' in doing these
things (for example, if you want to sense the
change in state of a light sensor after you
turn on a lamp, don't turn it on by executing
a dim sequence-- you'll sometimes miss the
reception of the 'daylight' RF trigger--
instead do a simple turn on, delay for a few
seconds, then dim). And if the initial
dimness of a flourescent lamp until warmup
gives you a false 'dead bulb' result, just
repeat the sequence after allowing it some
time to warm up. For the most part you can
accomplish enough conditional logic gvien the
smart macros and enough flags to do what you
want.
Speaking of flags, of course there aren't
enough, so I went the route of sacrificing
the 'monitored' house code and defining
devices on it to create 'pseudo'
flags... whereupon I ran into another
puzzling scenario when they sometimes didn't
work as expected. It turns out that I had
defined a macro to use the 'All House lights
on' function, which operates across all the
device codes in use, and it had the side
effect of turning on my 'pseudo' device code
flags as well, even though all the units on
the monitored code were defined as appliances
and not lights. In debugging this stuff,
I've found its very helpful to define RF
triggers that allow reading out the state of
the key flags and pseudo flags (by turning on
a light or chime to indicate the current
state of the flag) while the timer program is
up and running. Unfortunately the RF range
of my CM15A seems to deteriorate when it is
hooked up live to my PC, so having an ability
to readout the state of the flags while
running disconnected is necessary in lieu of
just using the 'report status' page.
Given enough hair pulling, I've gotten most
everything to work the way I want. The
outstanding issue I have is getting a
reliable 'garage door open' indicator made
out of the X10 stuff I have lying around. I'm
using the radio shack version of the
universal module and a couple of magnetic
switches in series on the garage doors, but
often the powerline signal that gets sent
(too bad it doesn't have a repeat function)
seems to be missed while a nearby driveway
motion detector's RF is apparently being
processed. Asynchronous event handling is
always a problem, and there just aren't
enough hooks in the hardware or software to
deal with it.
By the way, I have one of the first series of
the 'MS12' type X10 wireless motion detectors
which I got many years ago. It had some
annoying limitations (one being that you had
to hack it open and modify it by taping over
the light sensor if you wanted to be able to
use the motion sensing feature when it was
not in darkness), but it had one feature
which might be useful in your applicaton- as
I recall it only sent out an RF signal once
upon motion detection, then waited for 6
minutes before it would send another one
(although it could be retriggered during this
dormant interval). This behavior might
reduce the flood of RF at the cost of
occaisionally missing an event (a couple of
sensors in the room might compensate for this).
Author
Topic: NEED a Super Macro to Stop Motion Detector Processing (Read 4264 times)