Please login or register.

Login with username, password and session length

Author Topic: Dropped Commands Theory  (Read 6480 times)

TomG

  • Jr. Member
  • **
  • Helpful Post Rating: 10
  • Posts: 21
Dropped Commands Theory
« on: February 28, 2005, 05:10:38 AM »

Based on the issues I had to workaround in
my macros I can't find any other
explanation: basically it seems that if
multiple timers or macros end up having to
run around the same time commands that
would have had to be sent will be dropped.
I saw this a lot with motion sensors (I
have 3 outside around the house) at times
commands or macros will be skipped.

Does anybody know how exactly the interface
handles this: let's assume 10 different
timers want to send an ON at exactly same
time (e.g. dawn) and 3 motion sensor ON-s
come in and their macros want also to send
more ON-s or OFF-s. Does the interface
makes a queue and sends all the ON-s and
OFF=s over 3-4 seconds as needed?

Anybody else seen this? Or is there a
better solution?

Thanks,

Gigi
Logged

TomG

  • Jr. Member
  • **
  • Helpful Post Rating: 10
  • Posts: 21
Re: Dropped Commands Theory
« Reply #1 on: February 28, 2005, 05:11:58 AM »

In my macros I ended up repeating all the
ON or OFF commands 2 times, but at 1-2
seconds delay apart and I saw a big
improvement in reliability.
I also used heavily the "macro in a
macro" "undocumented" feature by using a
fake appliance code, but even the macro in
a macro calls ended up not happening until
I repeated at least twice all calls with
delays in between.

It seems to be that x10 commands need at
least 1/4 second or such to complete such
lots of commands will end up in a queue
that will be 5-10 seconds long and I just
do not see that in the logs.

If this theory is correct that would help a
lot to have it documented in some sort
of "best practices": basically commands
will end up being dropped if there is
traffic on the line and if one anticipates
that being the case should repeat the
commands after some delay (and what should
that delay be).

Or better have this handled automatically
by the interface thru a queue. Or maybe
there is some queue but it does not work in
all cases?
Logged

andyd

  • Sr. Member
  • ****
  • Helpful Post Rating: 1
  • Posts: 82
Re: Dropped Commands Theory
« Reply #2 on: February 28, 2005, 02:38:58 PM »

In my ahx built with 3.173 I have 2 events
that happen at 7am each weekday.  One is a
timer controlled macro that starts at 7am
(turn off VCR, delay 1 second, turn on
VCR).  The other is the last step of a macro
that started at 5:30am. (turn off sunrise
lamp). I have never seen a conflict.  Both
events happen at 7am.

I did have a problem trying to get to rf
triggered macros with a delay sequence to
operate on the same button push on my key
chain remote. I wanted porch lights on for
15 minutes and garage door power on for 15
minutes.  I need to go back and make that
work.


Andy D

Logged

andyd

  • Sr. Member
  • ****
  • Helpful Post Rating: 1
  • Posts: 82
Re: Dropped Commands Theory
« Reply #3 on: February 28, 2005, 02:41:10 PM »

that should have read "two rf triggered
macro"
Logged

TomG

  • Jr. Member
  • **
  • Helpful Post Rating: 10
  • Posts: 21
Re: Dropped Commands Theory
« Reply #4 on: February 28, 2005, 04:42:13 PM »

Two commands at the same time will probably
work.

The exact situation is as follows: 3 motion
sensors for the front yard and each will
trigger a macro that in turn will send 4 ON
commands (in part because I implemented
a "macro in a macro" method by using a fake
device).
Now if you walk across those 3 motion
sensors each typically sends out 2 (or 3)
times the ON command and you should end up
with 3x2x4 = 24 or more commands to be
sent.
In my experience some of those commands end
up being randomly dropped and that makes
for a hard to predict result of the set of
macros that end up being executed -
particularly if they are intertwined thru
flags.

The answer I'm looking for: will the
commands be dropped if they pile up or what
is the exact logic behind such I can
account for it in the macro?

The exact case:
- The motion sensors are O3, O5 and O7
- The O3 ON, O5 ON and O7 ON macros all
send a L3 ON
- The L3 ON sets a L4 ON then sets a flag
and sets another L4 ON (the flag ensures
the 2nd L4 ON goes thru an “else”
condition).

Now if you walk across O3, O5 and O7 you
end up with O3 ON, O5 ON, O7 ON, O3 ON, O5
ON, O7 ON etc since each sends twice then
followed by a couple of L3 ON but it never
gets to L4 ON (based on the log).
Logged

X10 Pro

  • Hero Member
  • *****
  • Helpful Post Rating: 23
  • Posts: 1416
Re: Dropped Commands Theory
« Reply #5 on: March 01, 2005, 01:20:50 PM »

There shouldn't be any problem with multiple
timed events stored in the interface
occurring at the same time -- they're just
queued up and run in order.

External triggered events can be more
difficult, since you're dealing with the
timing of RF commands, the transceiver
(either CM15A or other), and the powerline
events that result. However, I don't see what
the situation you describe wouldn't run the
macro completely. If you just trigger on of
the motion sensors does it go to completion?
Logged

TomG

  • Jr. Member
  • **
  • Helpful Post Rating: 10
  • Posts: 21
Re: Dropped Commands Theory
« Reply #6 on: March 01, 2005, 02:00:37 PM »

This is how is "coded":
O3->L1
O5->L1
O7->L1
L1->L2->delay 3 min ->L2

Now if you click "run macro" on all 3 of
them at the same time:  O3, O5, O7 most of
the time you will not see a "Sending L2 ON"
in the log. You will see L1-s.

I'll try to get a simpler "repro" now since
you mentioned they should be queue-ed up. I
was not sure what I should expect.
Logged

X10 Pro

  • Hero Member
  • *****
  • Helpful Post Rating: 23
  • Posts: 1416
Re: Dropped Commands Theory
« Reply #7 on: March 01, 2005, 02:04:53 PM »

Gigi: Clicking "Run Macro" from the PC
behaves a little differently from triggering
a macro (with an external command) that's
stored in the interface, so that may account
for some difference. I know we had some
problems with software timers and macros
recently, so that could be part of the
problem, at least in this case.
Logged
 

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