Print

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

[ziflin]

I have a simple macro setup as:
Trigger Conditions B2 ON and Module Status Off - Porch Light and
Flag Status Off - 2
End Trigger Conditions
Set Flags [2]
Turn Porch Light ON
WAIT for 15mins
Turn Porch Light OFF
Clear Flags [2]

So basically run if the light is off and not already running (trying to avoid any retriggering issues).  This is not real useful, but trying to debug another problem.

However, when I run this macro w/ my remote, the light turns on (yay). But if I manually turn off the Porch Light and run B2 again (from my remote) before the 15min delay, it turns the light on again.

Now maybe I'm missing something, but in this case, flag 2 should have been still set, and the "AND" check in the conditional should have failed and not turned the lights on again.

This macro is set to run in interface and I'm not triggering it with the PC, just my remote.  I also don't have any other "B2" macros (no elses, of B2 OFFs).

Can anyone explain to me what might be happening?  And does know exactly what happens when a macro is retriggered while it's running (sitting on a Delay node)?  I actually expect retriggers to interrupt current macros and just restart them, but even this doesn't appear to happen.

Thanks,
-Doug

[Tuicemen]

What is the address for your porch light?
What module address status are you checking?

[ziflin]

Porch Light was on A5. Monitored House code was A as well.

I spent an hour or so playing with this earlier.  What seems to be happening (in the log at least) are several Receives from the remote.  Some are "B2 On" and some are "B2 / B On".  If any of those happened once the macro starts (seems random), it does crazy things.  Like it will cause the light to turn on, and 1 second later turn off (the macro falls thru the delay and continues immediately), followed by 15min later another Off.  I tested this with a single macro and just the 1 flag check (I removed the module status check).  The flag check did nothing to prevent it from running twice and generating the obviously wrong early Off message.

I have no idea why this happens, but it seems like a bug.  To fix it, I setup a "Dummy" switch "D1", a trigger for that dummy, and changed the B2 macro to do nothing but turn D1 on (I removed the conditionals).  As soon as I did that, there was only a single "B2 Receive" in my log per press (where before 2-3 would show up).

On my D1 trigger I setup my conditional and everything worked as expected from then on.  If I change *just* my remote to D1 and press it, it does the 3 Receive thing and messes up again.

This was highly annoying to figure out and I still don't know why it just doesn't *work* like it should.  Adding the dummy switch On command somehow made it filter out the extra incoming messages from the remote.  It seems to introduce a 1 second hidden delay before it executes as well according to the log.

[PrimeGuild]

The Flags are kindda flaky and don't always work as expected. I too have noticed my door bell (sometimes) ring repeatedly 2-3 times alhough I have a Flag in there that shouldn't allow the bell to ring, atleast not before 5 minutes once it rings. I have created a 5 minute delay with a macro.

However, this doesn't happen always. Most of the times the Flags work fine, but there still are some bugs here and there that somehow bypass the Flags.

[Puck]

The Flags are kindda flaky and don't always work as expected.

I have to disagree with that generalized statement based on what I've experienced.

Since AHP Version 3.206 w/OnAlert, the only flag that is unreliable is Flag 16. I have never had any macro execution problems with flags 1 thru 15, and I use them all on 2 different CM15As.

[steven r]

...Since AHP Version 3.206 w/OnAlert, the only flag that is unreliable is Flag 16. I have never had any macro execution problems with flags 1 thru 15, and I use them all on 2 different CM15As.

Isn't/wasn't flag 15 also used for something by AHP?

[Tuicemen]

...Since AHP Version 3.206 w/OnAlert, the only flag that is unreliable is Flag 16. I have never had any macro execution problems with flags 1 thru 15, and I use them all on 2 different CM15As.

Isn't/wasn't flag 15 also used for something by AHP?

Flag 1 & 15 were at one point used as well  in AHP! 15 was dusk dawn I believe with flag 16. One would reset with AHP opening or closing! I still don't use those 3 flags and have never had an issue with macros using flag conditions since!

[Puck]

...Since AHP Version 3.206 w/OnAlert, the only flag that is unreliable is Flag 16. I have never had any macro execution problems with flags 1 thru 15, and I use them all on 2 different CM15As.

Isn't/wasn't flag 15 also used for something by AHP?

I wouldn't be surprised if the date code of the CM15A plays a role in how it internally uses the flags. I use 1 & 15 without any problems. Flag 16 still sometimes changes on it's own; so that is the only one I still don't use.

This is much like the various states of the flags after a reset that we have seen posted here. X10 has a real problem with documenting changes or at least making these changes available to their customers.

[Tuicemen]

The age of the Cm15A could cause issues involving flags as you stated Puck, in my case it was all software as I don't notice 1 or 15 being set or cleared any more.  It is just that X10 fixed the issue with one software update and reintroduced it with the next. So rather then having to redo my macros with each update I decided to stay away from the 3 flags. I assume at some point I may need them but for now I can get by with out them!