Topic: Consecutive flag operations in macros don't work (3.172) (Read 22770 times)

Burdy · « **on:** December 06, 2004, 12:48:42 PM »

My macro has a step that sets flag 1
(previously verified by looking at the
status report to be cleared) followed by a
step that clears bit 2 (previously verified
to be set). After it gets triggered, both
flags 1 and 2 are set. I've verfied other
consecutive flag operations in a macro don't
work (the second step doesn't seem to
execute).

If you insert a delay step between the
consecutive flag operations (even a delay
set to zero) that the macro then works.

I seem to remember that on an earlier AHP
release consecutive module on/off operations
didn't work without a similar workaround
(athough they do now). Can this problem
with consecutive flag operations be fixed?

steven r · « **Reply #1 on:** December 06, 2004, 01:43:29 PM »

I have yet to consciously be able to set or
clear a flag from a macro. (Somehow flags 1
& 15 are currently set.)

Every time I click on the icon to execute a
macro that includes steps to set or clear a
flag I get the message "The macro you are
running contains flag commands that will
not be executed. Do you want to run this
macro anyway?"

Even if I do decide to run it anyway, there
is no change in the flag status.

e.g. I built two macros. One to set all the
flags and the other to clear all the flags.
Even adding delays as you suggested or
changing them to only set or clear 1 flag
results in the same results.

I've emailed the bug as well as posted the
problem elsewhere so hopefully I know
something soon.

Burdy · « **Reply #2 on:** December 06, 2004, 01:52:59 PM »

I see that behavior also (flag bits don't
get set if macro is triggered from the AHP
interface rather than an RF trigger). I'm
not sure if it's an undocumented restriction
or just a bug. The 'not being able to use
consecutive flag steps' is a different
problem.

By the way, as of 3.172, I also experienced
unpredictable and unexpected setting of bit
15 in the flags. I also saw bit 2 and bit 14
pop up unexpectedly. I'll post a separate
thread for that problem since I don't think
its an isolated incident if you have also
experienced it.

X10 Pro · « **Reply #3 on:** December 06, 2004, 02:04:33 PM »

Flag commands currently aren't run from the
software, which is why you get the warning
message. If you trigger the macro with a
remote or powerline controller, the flag
operations will work.

mike · « **Reply #4 on:** December 06, 2004, 02:28:12 PM »

Steven R,

Try triggering the Macro with an rf remote
so it runs in the cm15a. As the message
indicates, macros run from the PC don't
affect flags. I'm not sure why they did it
that way and it's a limitation but not a
bug.

Burdy,

I've got a Smart Macro that sets flag 1 and
clears flag 2 in consecutive steps that
appears to be working correctly in 3.172. I
haven't actually checked the flag status
but the macro should be failing if both
operations don't occur correctly.

Are the flag operations, the first steps in
the macro? Mine follow a module dim command
but there is no delay between the set and
clear flag operations.

Mike

Burdy · « **Reply #5 on:** December 06, 2004, 02:31:08 PM »

Thanks, X10 pro, I understand that part.
Can you comment on the behavior of the
second of two consecutive flag operation
steps not executing (when the macro is run
from the hardware)? The scenario I am
reporting does include the macro triggering
with an RF trigger.

The macro executes, but only the first flag
operation step seems to affect the flags. If
there is a flag operation step immediately
following, it seems to be ignored. Adding a
delay step (even if 0) seems to be needed to
allow the 2nd flag operation to be executed.

Burdy · « **Reply #6 on:** December 06, 2004, 02:56:07 PM »

Mike, I stumbled across this because my
macro wasn't working correctly. I then made
a couple of experimental macros to see what
was going on (and checked the flag status to
verify).
In my orignal macro, the flag
manipulations weren't the first steps. But I
don't think it matters-- if you start with a
known flag configuration (so you can tell
what the state should be after your macro
executes), and create a trivial macro that
includes a couple of consecutive flag
operations (that you set up so you can
verify whether the second one actually did
anything), then trigger it (from the
hardware via RF) and look at the flag
status, I think you'll find the second flag
operation will not have executed. If you
add a delay step in between, it will work.

I'd prefer not to have to do that since it
seems like a drain on the CM15A's resources
to have the extra delays added. Also, I'm
assuming that a zero delay is a 'supported'
configuration (and doesn't cause any
unwanted side effects like underflow). I
notice that you can't select a default timer
delay of zero in the Preferences using the
dropdown arrow, although you can manually
type it in the delay field.

X10 Pro · « **Reply #7 on:** December 06, 2004, 03:03:26 PM »

I tested this out here, and it looks like
we're not encoding the second command in the
sequence when we're storing the macro in the
interface. We should be able to fix this
pretty quickly.

Burdy · « **Reply #8 on:** December 06, 2004, 03:14:58 PM »

Thanks! Once these bugs get swatted, AHP
will be an awesome tool. There seems to be
enough flexibility in the functions provided
to easily do (in theory, not quite yet in
practice) exactly what I've been wishing my
standalone CP290 could do for years (I don't
want to tie up a computer to run my lights,
yet I want the bells and whistles). I can
appreciate the difficulty in getting the AHP
software to hide all the complexity from the
user.

steven r · « **Reply #9 on:** December 06, 2004, 05:23:46 PM »

"Flag commands currently aren't run from
the software, which is why you get the
warning message. If you trigger the macro
with a remote or powerline controller, the
flag operations will work."

I'm doing a status report to view my flags.
Triggering them from an RF remote has no
effect on flag status either. The activity
monitor says my macros are being run.

steven r · « **Reply #10 on:** December 06, 2004, 05:28:39 PM »