Print

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

[stephen]

Just an obsevation....

First let me say I am an IT professional and
have been for over 20 years.........

that being said, the smart macros plugin,
which I purchased for about 50 bucks, is
about as cludgy and confusing as they get.

It's not very logical.

Let's say you create a macro triggered by a
motion sensor to turn on a light when it's
nighttime. Works fine.

Let's say you want to add an else
condition,that when it's daytime you trigger
a chime.

ActiveHome/Smartmacros creates ANOTHER
macro. It was very confusing at first
because you're looking for a "else" or
something and it's not there!

Opening the .ahx file and reading the "code"
you see how smart macro works. It uses
condition codes ("condition=13", I think)
for the else condition which triggers the
second macro.

When you open up Active Home it appears like
you have 2 macros and not one macro with
some "IF_THEN_ELSE" logic.

I find this...misleading, confusing.

Any opinions?

Stephen B

[bob linca]

I agree. It is a bit confusing to see
multiple macro icons for each level of the
IF_THEN_ELSE logic. For one lamp module I
use two macros, but on the AHP interface I
have four macro icons! Having said that, I
can test each branch of the statement
individually, so it’s not all bad.

Personally, I would prefer one icon for each
macro.

[drew]

Does it stop evaluating else macros once one
is true?  It seems that the order the macros
are chained together matters.

In a perfect world, how does the unit handle
macros triggered while still
executing?  ...Aside from locking up which
is what it seems to do if you fire of too
many at once....

[julian]

Drew,

If you have a macro with 3 else logic (4
total macros trigerred by the same address),
for instance, the macro engine will evaluate
each one until it finds a match, then it
stops. I don't believe it keeps evaluating
the rest of the conditions if it finds them
true in one of the first blocks.
For your second question - one way to avoid
this is to use flags - then the condition
doesn't match until the first instance of the
macro is done. I can see how you can have two
valid instances of the same macro start if
you don't use flags, and I don't know what
the CM15A does in that case - I would also
like to know. A lot of times you don't really
need to use flags, unless you want to
explicitly avoid collisions.
If I think about it, I think the CM15A
actually treats each macro trigerred the same
way and tries to execute them all, which
could be a problem, especially if you turn
lights off after a certain amount of time.
Consider the following "welcome home macro":
If time between 5 PM and 8 PM,
Turn hallway lights on
Turn kitchen lights on
Delay 5 minutes
Turn lights off

If I come home at 5:15 PM the macro starts
running and it turns the lights on.
Meanwhile, my wife walks in at 5:19 PM, four
minutes after I trigerred the macro. In that
case the macro is executed again, however 1
minute after my wife gets home the lights
turn off instead of 5 minutes later, because
the first instance of the macro is still
running. So, we end up with somethine like this:
5:15 PM Lights ON
5:19 PM Lights ON
5:20 PM Lights OFF
5:24 PM Lights OFF

The last set of OFF commands is redundant
since the lights would be off anyway, but the
macros are just doing their job.
I would hope X10 will change AHP to terminate
a running instance of a macro if that macro
is trigerred again (I think this would be the
preferred solution). The alternative is to
ignore calls to the macro while it is running
(not appealing, since my wife would only get
1 minute of light and I'd be the one taking
the blame!!!). Hope this helps.