Phantoms OR Flags trip, but not both??? Mr. Puck?

[PajamaGuy]

AHP- all modules, DS7000.
Arming Home with a Security Remote sets flags 2 & 3, and phantoms P2 & P3. ArmedLight macro triggers on P2 and turns on SuperSocket D5.

Disarming from the same remote clears flag 2&3 and P2 & P3.  ArmedLight macro triggers on P2 OFF and turns off the D5.

Sometimes it works  - Sometimes not    This morning, i watched the macros fire as I pressed the buttons on the remote.  They fired when they should have, but either the FLAGS 2&3 were flipped, OR the P2 & P3 phantoms flipped, but not both.  If I moved P2&P3 to the beginning of the macro, they flipped and not the flags; and when I moved the flags to the beginning, they set/cleared, but not the P2&P3??

Yeah, I stuck in a delay (2 sec) and moved it around, but didn't seem to matter.

So I dumped the CM15a, batteries & all, and the last time I tried, it worked.  The macros triggered by the remote are ELSEs (but visually, the correct one(s) fire when they should) and they're all stored and run from the PC. -


x10 is SO MUCH FUN!!!!!

[Puck]

My number 1 reason for using 2 CM15As: Macros calling Macros.

Do you have House Code 'P' set to Transceive? I've experienced the same thing when calling a macro from a macro and found that if I Transceive the called macro's house code, it seemed to improve the firing of those macros. (Zero logic here.)

One other thing to look at is command order of everything the CM15A is trying to do. When you call the P2 & P3 macros, the CM15A will start executing the instructions there at the same time it continues executing the original macro. I'm sure it drops commands when trying to do two things at once, so you may have to strategically place delays in the called macros.

[Boiler]

My number 1 reason for using 2 CM15As: Macros calling Macros.

I'm with you Puck, but I'd like to add a caveat.
My number 1a reason for using 2 CM15a's: Macros calling Macros via RF.  Keep the powerline clean. 

[Puck]

Macros calling Macros via RF.  Keep the powerline clean. 

Nice.... and less chance of getting a corrupted signal to the other CM15A.

[PajamaGuy]

...macro calling a macro via RF.....    Jeez, I'm having a senior moment - How do you call a macro from within a macro via RF? 


And while I'm asking - How would you distinguish between the 2 CM15a's - like when you said you get 32 flags instead of 16 - ahhhhhhhh - the macros in CM15a #1 have their own 16 flags, while he macros in CM15a #2 have their own - I think I just solved that one for myself...

[Boiler]

...macro calling a macro via RF.....    Jeez, I'm having a senior moment - How do you call a macro from within a macro via RF? 

PajamaGuy,

Since the CM15a can receive and send RF, I use a RF transmit from one unit to call Macros on a second CM15a.  If you have Smartmacros, the RF transmit is located under the macro "Advanced Functions" tab. 

The example below is from one of my kitchen sensors.  I use two sensors to monitor activity in the kitchen.  I use it to turn lights in the room off after a period of inactivity (lights must be turned on manually).

1) CM15a #1 receives and "filters" the incoming RF from the motion sensors.  The flags and delays prevent multiple triggers (the motion sensors often send multiple on transmissions).
2) CM15a #1 calls macro D6 via RF on CM15a #2.  Actually I have a macro (B1 and B3) for each motion sensor.  Each performs a RF call to D6.
3) CM15a #2 executes a 10 minute delay (macro D6) and then turns off the lights in the kitchen.
4) Since the D6 macro on CM15a #2 is re-entrant, multiple calls to this macro (additional motion in the room) reset the timer back to 10 minutes.  If motion continues the lights will stay on indefinitely.

Hope this helps,
Boiler

BTW, regarding the "senior moment" - I find that I'm quite a bit happier since I've attained "greybeard status".  When something happens to tick me off on Monday, chances are I will have forgotten all about it be Tuesday.

[PajamaGuy]

 .... Oooooooo, I like it!  And I've been looking for a reason to buy more x10 $tuff.  I think another CM15a and a V572RF32 are in order.

Thanks!

[PajamaGuy]

Boiler,  How about a screenshot of D6, please...  and does D6 have to have a module (phantom), or can the RF call fire the macro?

[Boiler]

PajamaGuy,

There's really not much to the RF receive macro (below).  It simply starts the 7 minute delay and then transmits a X10 off command.  If a RF transmission is received before the 7 minute delay has completed, the timer resets and waits an additional 7 minutes.

I did this to prevent excessive X10 communication on the powerline.  Currently, when you use dummy modules, each macro call gets transceived to the powerline.  The RF macro call to the second CM15a prevents any X10 from being put on the line (as you can probably tell, I'm a nut about this).  Most of the devices in my home are now Insteon based.  The D6 off command is interpreted by a Insteon controller which tests to see if my Kitchen lights are on, and if so, slowly dims them to an off condition.

Hope this helps,
Boiler 

...oops, missed your second question.  On the second CM15a, I have D6 identified as a motion sensor.  The macro D6 is called directly from the first CM15a.

[PajamaGuy]

Thanks - and I think I'm getting there...

...but - 1. I thought repeated calls to a macro only "stacked" them - in other words, calling D6 would start the delay, if 3 minutes later another call happened to D6, ANOTHER instance would run, but the first instance would still send the E1 OFF - 4 minutes after the second call, and the second instance would send another OFF 3 minutes later.  What I'm hearing you say is that the second call causes the first instance to vaporize (which is the way one would like successive calls to a timing macro to work).  Stated another way, if 100 RF-D6=ON commands were sent, with a maximum time interval of 6 minutes between them, only one E1-OFF would happen 7 minutes after the last RF-D6-ON was sent.  Correct?  (Is that what you mean by re-entrant?)

Or is it because it's an RF call?  I love this, because I've done the same thing using flags and phantoms - this is soooo much more simple!!

2. I'm not being picky, but when you said 

The D6 off command

- didn't you mean The E1 off command?

While I'm asking - because it's an RF-command, even though the V572RF32 (with PSC05) received (and re-transmitted) it, it would NOT be converted to a PLC, right?  Would the same hold true when a TM751 receives it?

Finally (for now), does this only work if you have multiple CM15a's?  Would an RF call work if D6 resided on the same CM15a as the calling macro?  Especially if one had an RF repeater?

[jtykal]

I did this to prevent excessive X10 communication on the powerline.  Currently, when you use dummy modules, each macro call gets transceived to the powerline. 

Is this true even if the housecode for the dummy module is not transceived by the CM15a?

...oops, missed your second question.  On the second CM15a, I have D6 identified as a motion sensor.  The macro D6 is called directly from the first CM15a.

Is it the fact that you have D6 identified as a motion sensor which causes the timer to reset instead of the macro calls being "stacked", as PajamaGuy asked? I like using the built-in timer in the motion sensors to turn off a light after a period of inactivity (no AHP macros required!), but I've been looking for an easy way to implement this same scenario (i.e., an occupancy sensor) using multiple motion detectors. (I haven't invested the time/effort to do this with flags and phantoms like PajamaGuy did...)

[Boiler]

Thanks - and I think I'm getting there...

...but - 1. I thought repeated calls to a macro only "stacked" them - in other words, calling D6 would start the delay, if 3 minutes later another call happened to D6, ANOTHER instance would run, but the first instance would still send the E1 OFF - 4 minutes after the second call, and the second instance would send another OFF 3 minutes later.  What I'm hearing you say is that the second call causes the first instance to vaporize (which is the way one would like successive calls to a timing macro to work).  Stated another way, if 100 RF-D6=ON commands were sent, with a maximum time interval of 6 minutes between them, only one E1-OFF would happen 7 minutes after the last RF-D6-ON was sent.  Correct?  (Is that what you mean by re-entrant?)

Ok, I left out a few subtle points.  I rechecked these to make sure I had my facts correct. 

Example macro (B1 ON)
Delay 10
Set D6 ON
Delay 10
Set D6 Off

Here's the catch -

• If I start this macro (B1 ON) and send another B1 ON command within the first 10 second delay, the macro will "re-enter" and restart the 10 second delay.  You could extend the macro indefinitely by executing the B1 on command 9 seconds apart
• If I send a B1 on command after ~12 seconds (after the first delay statement has completed), the macro will execute a copy.  I can again extend the delay within the copy by resending B1 On commands within the first statement window (delay 10) although I'm not sure why you'd want to do this

Actually, the above example is a prime candidate for using flags to "lock out" subsequent calls.  If you want a timed sequence of events to occur after a X10 event, flags should be used to prevent re-triggering the macro.

In my example above (previous post), I'm allowing multiple calls to the D6 macro cause the delay to re-start.

Or is it because it's an RF call?  I love this, because I've done the same thing using flags and phantoms - this is soooo much more simple!!

Nope, nothing to do with the RF.  I've used the same re-entrant macro for both RF and X10 (powerline) transmissions.

2. I'm not being picky, but when you said 

The D6 off command

- didn't you mean The E1 off command?

• The D6 (RF) call is made from CM15a #1.
• The D6 (RF) is received by CM15a #2 and starts the D6 Macro
• After 7 minutes CM15a #2 executes a E1 off command (powerline)

While I'm asking - because it's an RF-command, even though the V572RF32 (with PSC05) received (and re-transmitted) it, it would NOT be converted to a PLC, right?  Would the same hold true when a TM751 receives it?

I'm not very well versed on the VT572.  I'm not sure if it is capable of repeating RF.  I believe that the VT572 can be programmed not the transceive RF onto the powerline (similar to the CM15a).

If your RF transmission is at the TM751 Housecode, it will transcieve to the powerline.  I don't use them for exactly that reason.

Finally (for now), does this only work if you have multiple CM15a's?  Would an RF call work if D6 resided on the same CM15a as the calling macro?  Especially if one had an RF repeater?

Sorry, I've tried exactly the same thing you're thinking.  The CM15a cannot call itself via RF.  I tried using my repeater (not currently installed) and found that it didn't register any RF communication from the CM15a.

Boiler

[Boiler]

Is this true even if the housecode for the dummy module is not transceived by the CM15a?

Yep.  A call to a dummy module puts X10 on the powerline.  The transceived housecode options only stops RF commands from being put on the powerline.

Is it the fact that you have D6 identified as a motion sensor which causes the timer to reset instead of the macro calls being "stacked", as PajamaGuy asked? I like using the built-in timer in the motion sensors to turn off a light after a period of inactivity (no AHP macros required!), but I've been looking for an easy way to implement this same scenario (i.e., an occupancy sensor) using multiple motion detectors. (I haven't invested the time/effort to do this with flags and phantoms like PajamaGuy did...)

No, it's that fact that the macro is being re-triggered while the first statement (the delay) is still being executed.  If you call the macro after the second statement starts, a copy (stacked macro) will be started.

Boiler

[jtykal]

Very helpful stuff, Boiler. Thank you!

[PajamaGuy]

Thanks Boiler!

(you're making my head hurt!)

My biggest problem is getting my DS7000 to receive all my sensors.  I may have to add another SR731.  Everything (DS7000-related) has been working fine until about 2 weeks ago, now even close sensors sometimes don't register.