Please login or register.

Login with username, password and session length

Author Topic: Interesting problem SOLVED - collision avoidance  (Read 6356 times)

poursha

  • Sr. Member
  • ****
  • Helpful Post Rating: 1
  • Posts: 77
Interesting problem SOLVED - collision avoidance
« on: December 28, 2005, 08:26:43 PM »

Noticed an interesting problem tonight.
Have a simple macro setup.  Have lights F1
and F2.  Macro F3 is setup to turn ON/OFF
BOTH at the same time.

Some additional information:
CM15A is plugged into same plug as F2.
I have a mini controller plugged into same
as F1.

I've been using RF for the last few days,
and despite the range limitation, the F3
macro has worked great.

In fact, I've been driving the wife crazy
turning ON/OFF, because I think it is
cool...  <grin>  WAF problem...

Today I just happened to try the F3 from
the mini controller.  PROBLEM!!!  It turned
ON/OFF the F2, but NOT the F1.  And it was
consistently failing.  Then, it came to
me:  The outgoing F3 signal was colliding
with the returning F1 signal.  So, I put a
1 sec delay before the F1 ON/OFF in the
macro, and BINGO!!  It works perfect now,
albeit with a slight delay.

Just thought it was an interesting problem
that others could learn from...

RoB Runkle
Logged

Charles Sullivan

  • Hero Member
  • *****
  • Helpful Post Rating: 94
  • Posts: 1565
    • HEYU - X10 Automation for Linux, Unix, and Mac OSX
Re: Interesting problem SOLVED - collision avoidance
« Reply #1 on: December 29, 2005, 09:19:13 PM »

You were presumably holding down the button
on the MiniController long enough for
multiple F3 signals to be sent.  The CM15A is
supposed to wait for a clear power line
before transmitting, but I've encountered an
abnormal startup mode when it doesn't -
usually after it's been unplugged with no
batteries for some extended period of time.

Try unplugging from the AC line, removing the
batteries for a few seconds, replacing the
batteries, and plugging in again.  Then
retest with no delay in your macros and see
if your original problem still exists.
Logged
Yesterday it worked.
Today it doesn't work.
X10 on Windows is like that.

HEYU - X10 Automation for Linux, Unix, and Mac OS X     http://www.heyu.org

poursha

  • Sr. Member
  • ****
  • Helpful Post Rating: 1
  • Posts: 77
Re: Interesting problem SOLVED - collision avoidance
« Reply #2 on: December 29, 2005, 11:47:14 PM »

<bowing>  We're not worthy.  We're not
worthy...  <grin>

First off, what you said WORKED.  NO MORE
DELAY REQUIRED...

Secondly, you saved me a CM15A.  The unit
is only 2 weeks old, but I had a small
battery leak already.  Luckily, I only had
a small bit of crud to clean up, instead of
damaged CM15A.

Funny thing, the battery still shows a full
charge (even now).  Must be faulty from the
factory.  Those Duracell characters...

Thanks MUCH, RoB

Logged

mitch barbato

  • Newbie
  • Helpful Post Rating: 0
  • Posts: 7
Re: Interesting problem SOLVED - collision avoidance
« Reply #3 on: January 02, 2006, 03:10:08 PM »

Excellent!  I had a similar issue, but with
my "Dusk" macro, which is triggered on D2-
ON.  Their are about five steps involved
with dimming presets, and after the second
step, I'd get an "All Lights On".  This was
not recorded in the Activity Monitor, but
it's pretty obvious when about six lamp
modules all turn on at the same time.

This would happen when the Hawkeye would
sense "dark" and issue a D2-ON.  AND, it
happens with a Mini Controller as well,
again, not recorded.

I put a one second delay between dimming
events, and it completely fixes the
problem.  Thanks!

Charles, I'd love to trust that your fix
is "permanent", but I don't have that much
faith in the CM15, so I'll leave my
delays.  :-)
Logged

Charles Sullivan

  • Hero Member
  • *****
  • Helpful Post Rating: 94
  • Posts: 1565
    • HEYU - X10 Automation for Linux, Unix, and Mac OSX
Re: Interesting problem SOLVED - collision avoidance
« Reply #4 on: January 02, 2006, 03:46:39 PM »

Mitch,
Did the "fix" in fact seem to solve your All-
Lights-On problem without having to add the
delays?  This could be a valuable clue for Mr
X10Pro to investigate.

As I mentioned previously, I've generally
experienced the problem when the CM15A has
been unplugged with no batteries for some
extended period of time, which would be the
case for a new out-of-the-box CM15A
installation.
Logged
Yesterday it worked.
Today it doesn't work.
X10 on Windows is like that.

HEYU - X10 Automation for Linux, Unix, and Mac OS X     http://www.heyu.org

poursha

  • Sr. Member
  • ****
  • Helpful Post Rating: 1
  • Posts: 77
Re: Interesting problem SOLVED - collision avoidance
« Reply #5 on: January 02, 2006, 03:51:43 PM »

PS.  This WAS my case.  Out of the box NEW!!

RoB
Logged

mitch barbato

  • Newbie
  • Helpful Post Rating: 0
  • Posts: 7
Re: Interesting problem SOLVED - collision avoidance
« Reply #6 on: January 02, 2006, 03:59:39 PM »

Charles,

I didn't try the battery-remove test, I
merely added the delays as a test fix.

And, yes, like Rob's unit, mine was fresh
out of the box.  I did however, clear the
memory, trying about anything I could.

I do prefer the hard-coded delay, however,
and I've still got 92% Available, so I'm not
too worried about the overhead.
Logged

Charles Sullivan

  • Hero Member
  • *****
  • Helpful Post Rating: 94
  • Posts: 1565
    • HEYU - X10 Automation for Linux, Unix, and Mac OSX
Re: Interesting problem SOLVED - collision avoidance
« Reply #7 on: January 02, 2006, 04:32:56 PM »

Mitch,
I just noticed you mentioned "dimming
presets".  What kind of modules do you have?
Some kinds of 2-way modules can be set to
automatically return their status when
activated and I can envision the possibility
of signal collisions on the power line if
there isn't a delay.
Logged
Yesterday it worked.
Today it doesn't work.
X10 on Windows is like that.

HEYU - X10 Automation for Linux, Unix, and Mac OS X     http://www.heyu.org

mitch barbato

  • Newbie
  • Helpful Post Rating: 0
  • Posts: 7
Re: Interesting problem SOLVED - collision avoidance
« Reply #8 on: January 02, 2006, 04:54:28 PM »

"Presets"- I guess I use the vernacular of
AHP's Timer Designer window.

I'm using the simple LM465's and AM486's.
The collision was happening on the tail end
of dimming an LM465 to 50% and then turning
off an AM486 right behind it.  I'm sure that
one delay right there would fix it, but I
added a delay between each event anyway.
(Four events total.)

This was done as a diagnostic aid, since I
can watch things happen more slowly.  I may
remove some of them in the future once I get
a better feel for the overall behavior of
the CM15A.

BTW, hats off to Rob for catching this!
Logged

Charles Sullivan

  • Hero Member
  • *****
  • Helpful Post Rating: 94
  • Posts: 1565
    • HEYU - X10 Automation for Linux, Unix, and Mac OSX
Re: Interesting problem SOLVED - collision avoidance
« Reply #9 on: January 02, 2006, 05:37:21 PM »

Mitch,
OK.  But if you get the chance, try the
unplug/battery-out "fix" and the macro
without any delays and let us know the
results.
Logged
Yesterday it worked.
Today it doesn't work.
X10 on Windows is like that.

HEYU - X10 Automation for Linux, Unix, and Mac OS X     http://www.heyu.org

roger1818

  • Hero Member
  • *****
  • Helpful Post Rating: 28
  • Posts: 1072
  • Roger H.
Re: Interesting problem SOLVED - collision avoidance
« Reply #10 on: January 04, 2006, 11:09:36 AM »

Charles & Mitch:  I have had the same problem
as Mitch since I received my CM15A about a
year ago.  I have done many resets since then
and have never had the problem go away
completely.  My rule of thumb is to insert a
short (1 second) delay in all macros after a
dim or bright command if another command
follows it.
Logged
 

X10.com | About X10 | X10 Security Systems | Cameras| Package Deals
© Copyright 2014-2016 X10.com All rights reserved.