Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Charles Sullivan]

If a macro is created with only a sequence of
addresses, e.g., for programming a Smarthome
module, only the first address in the
sequence is transmitted.  This is observed
both in the AHP Activity Monitor and with a
CM11A monitoring the power line on a separate
PC.  If Delays of 00:00:00 are inserted in
the macro between each address, then the
entire sequence of addresses is correctly
transmitted.

Steps to demonstrate:
1. File > New
2. Click on Macros (+) to design a new macro
and set it to B1 ON.
3. From Advance Functions menu, drag in
Addresses A1, A2, and A3.
4. Tools > Activity Monitor
5. On Room panel, click "Run macro" on the
macro B1 On icon.
6. In the Activity Monitor, observe that only
Address A1 is transmitted.
7. Return to the Macro designer panel and
drag in Delays, inserting them between each
Address icon.  Set the delay values to 00:00:
00 or any other value.
8. In the Room panel, again click on "Run
macro".
9. Now observe in the Activity Monitor that
all three addresses are correctly
transmitted.

The above tests were run with AHP 3.201 under
Win XP Pro SP1. Whether the same problem
existed with prior AHP releases has not been
determined.

[X10 Pro]

Good catch. This problem has probably existed
since we made the Address command PC-only.
We'll fix it.

[mikeq]

I have had a similar problem since about 5 updates back. When I setup a macro that triggers on a motion sensor with only one unit on command, it will sometimes send the unit on command and sometimes not. Mostly not. If I put a 1 second delay (never tried an all zeros delay) as the first step in the macro, then it works every time.

Mike

[EricLEdberg]

The issue of the macro not running all the time may be similar to another "bug" I reported.  The response from X10 was that it was expected operation when a macro runs on the PC; I feel it is a "bug" and so do others.

What I was told:

When a macro runs on the PC, it "remembers" the state of a module.  So if a PC-based macro had previously thought it had sent an ON command to the address,  and was triggered to send another ON command, it would ignore it and do nothing.  This was verified by trying to send multiple ON commands to the same address in one macro; only 1 was ever sent (and only when the internal state on the PC had it listed as currently off).

X10's response was that the only way to do this was to download the macro to the controller....  So much for PC-based long-running macros.

My response was that I don't want the PC doing any "smart" state analysis for any reason.  I'm smart and want to program exactly what I want in the order I want it.... But I digress.  Additionally, PC-based macros will be "re-ordered" (parsed) and not sent the way you program them.  Adding the zero-second delay forces correct parsing.  Another bug...

Could be a similar issue?

[Charles Sullivan]

"The issue of the macro not running all the time may be similar to another "bug" I reported.  The response from X10 was that it was expected operation when a macro runs on the PC; I feel it is a "bug" and so do others."

Although the implementation may at times be buggy, the concept of a "smart" macro is not.  However the user really ought to have the option of turning this feature off, so that the macro will run exactly as programmed and exactly the same as a downloaded macro, regardless of the state of the system.

(Unfortunately when there are too many options,  the newbie user often complains that the software is too complicated.)